Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T02:41:27Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

The project was divided into 4 categories:
# Database migrations
# Refactor ''submitted_hyperlink'' related methods
# Refactor ''directory_num'' related methods
# Testing
 

We followed the steps listed below in the process of refactoring the submitted content controller:

* Writing database migrations to move the ''submitted_hyperlinks'' and ''directory_num'' attributes from the Participants table to the Teams table.
* Rewriting ''submitted_hyperlinks'' related methods in the Participants model to read from and write to the Teams table.
* Modifying the corresponding views to read ''hyperlinks_array'' instead of ''hyperlinks''. ''hyperlinks_array'' stores the the submissions of all the team members of a team.
* Removing ''directory_num'' related methods from the participant model.
* Rewriting ''directory_num'' related methods in the team model.
* Rewriting the corresponding views to read ''directory_num'' from the teams table instead of the participants table.
* For testing, we first created fixtures for all required tables.
* We tested our changes by writing functional tests to test the SubmittedContentController.
* Our test suite included the following tests:
** Testing submission of a hyperlink by one student - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of two hyperlinks by two students in a team - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of the same hyperlink by two students in a team - Check that the duplicate hyperlinks does not get stored.
** Testing deletion of a hyperlink - Check the count of submmited hyperlinks and the updated list is displayed correctly from the UI.
** Testing submission of one file by one student - Check the submission of a file and check the updated count of submitted files.
** Testing deletion of one file by one student - Check the deletion of a submitted file and check the updated count of submitted files.
** Testing submission of multiple files by multiple students - Check the submission of multiple files and check the updated count of submitted files.
** Testing deletion of multiple files by multiple students - Check the deletion of multiple submitted files and check the updated count of submitted files.

 
We can conclusively say that, after refactoring the submitted content controller, the query time for retrieving submissions will improve significantly as they are stored together on a team-basis rather than for each participant.

Video demo of our work can be found at https://www.youtube.com/watch?v=VHVWF_UKgOc&feature=youtu.be 
GitHub repository containing the refactoring changes can be found at https://github.com/nitinnagaraja/expertiza/ 
Link to the pull request to Expertiza is https://github.com/expertiza/expertiza/pull/629

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T02:41:05Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

The project was divided into 4 categories:
# Database migrations
# Refactor ''submitted_hyperlink'' related methods
# Refactor ''directory_num'' related methods
# Testing
 

We followed the steps listed below in the process of refactoring the submitted content controller:

* Writing database migrations to move the ''submitted_hyperlinks'' and ''directory_num'' attributes from the Participants table to the Teams table.
* Rewriting ''submitted_hyperlinks'' related methods in the Participants model to read from and write to the Teams table.
* Modifying the corresponding views to read ''hyperlinks_array'' instead of ''hyperlinks''. ''hyperlinks_array'' stores the the submissions of all the team members of a team.
* Removing ''directory_num'' related methods from the participant model.
* Rewriting ''directory_num'' related methods in the team model.
* Rewriting the corresponding views to read ''directory_num'' from the teams table instead of the participants table.
* For testing, we first created fixtures for all required tables.
* We tested our changes by writing functional tests to test the SubmittedContentController.
* Our test suite included the following tests:
** Testing submission of a hyperlink by one student - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of two hyperlinks by two students in a team - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of the same hyperlink by two students in a team - Check that the duplicate hyperlinks does not get stored.
** Testing deletion of a hyperlink - Check the count of submmited hyperlinks and the updated list is displayed correctly from the UI.
** Testing submission of one file by one student - Check the submission of a file and check the updated count of submitted files.
** Testing deletion of one file by one student - Check the deletion of a submitted file and check the updated count of submitted files.
** Testing submission of multiple files by multiple students - Check the submission of multiple files and check the updated count of submitted files.
** Testing deletion of multiple files by multiple students - Check the deletion of multiple submitted files and check the updated count of submitted files.

 
We can conclusively say that, after refactoring the submitted content controller, the query time for retrieving submissions will improve significantly as they are stored together on a team-basis rather than for each participant.

Video demo of our work can be found at https://www.youtube.com/watch?v=VHVWF_UKgOc&feature=youtu.be 
GitHub repository containing the refactoring changes can be found at https://github.com/nitinnagaraja/expertiza/ 
Link to the pull request to Expertiza is https://github.com/expertiza/expertiza/pull/629
 

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T02:38:10Z

Nnagara2:

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T02:37:16Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

The project was divided into 4 categories:
# Database migrations
# Refactor ''submitted_hyperlink'' related methods
# Refactor ''directory_num'' related methods
# Testing
 

We followed the steps listed below in the process of refactoring the submitted content controller:

* Writing database migrations to move the ''submitted_hyperlinks'' and ''directory_num'' attributes from the Participants table to the Teams table.
 
* Rewriting ''submitted_hyperlinks'' related methods in the Participants model to read from and write to the Teams table.
* Modifying the corresponding views to read ''hyperlinks_array'' instead of ''hyperlinks''. ''hyperlinks_array'' stores the the submissions of all the team members of a team.
 
* Removing ''directory_num'' related methods from the participant model.
* Rewriting ''directory_num'' related methods in the team model.
* Rewriting the corresponding views to read ''directory_num'' from the teams table instead of the participants table.
 
* For testing, we first created fixtures for all required tables.
* We tested our changes by writing functional tests to test the SubmittedContentController.
* Our test suite included the following tests:
** Testing submission of a hyperlink by one student - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of two hyperlinks by two students in a team - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of the same hyperlink by two students in a team - Check that the duplicate hyperlinks does not get stored.
** Testing deletion of a hyperlink - Check the count of submmited hyperlinks and the updated list is displayed correctly from the UI.
** Testing submission of one file by one student - Check the submission of a file and check the updated count of submitted files.
** Testing deletion of one file by one student - Check the deletion of a submitted file and check the updated count of submitted files.
** Testing submission of multiple files by multiple students - Check the submission of multiple files and check the updated count of submitted files.
** Testing deletion of multiple files by multiple students - Check the deletion of multiple submitted files and check the updated count of submitted files.

 
We can conclusively say that, after refactoring the submitted content controller, the query time for retrieving submissions will improve significantly as they are stored together on a team-basis rather than for each participant.

Video demo of our work can be found at https://www.youtube.com/watch?v=VHVWF_UKgOc&feature=youtu.be 
GitHub repository containing the refactoring changes can be found at https://github.com/nitinnagaraja/expertiza/ 
Link to the pull request to Expertiza is https://github.com/expertiza/expertiza/pull/629

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T02:20:31Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

The project was divided into 4 categories:
# Database migrations
# Refactor ''submitted_hyperlink'' related methods
# Refactor ''directory_num'' related methods
# Testing
 

We followed the steps listed below in the process of refactoring the submitted content controller:

* Writing database migrations to move the ''submitted_hyperlinks'' and ''directory_num'' attributes from the Participants table to the Teams table.
 
* Rewriting ''submitted_hyperlinks'' related methods in the Participants model to read from and write to the Teams table.
* Modifying the corresponding views to read ''hyperlinks_array'' instead of ''hyperlinks''. ''hyperlinks_array'' stores the the submissions of all the team members of a team.
 
* Removing ''directory_num'' related methods from the participant model.
* Rewriting ''directory_num'' related methods in the team model.
* Rewriting the corresponding views to read ''directory_num'' from the teams table instead of the participants table.
 
* For testing, we first created fixtures for all required tables.
* We tested our changes by writing functional tests to test the SubmittedContentController.
* Our test suite included the following tests:
** Testing submission of a hyperlink by one student - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of two hyperlinks by two students in a team - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of the same hyperlink by two students in a team - Check that the duplicate hyperlinks does not get stored.
** Testing deletion of a hyperlink - Check the count of submmited hyperlinks and the updated list is displayed correctly from the UI.
** Testing submission of one file by one student - Check the submission of a file and check the updated count of submitted files.
** Testing deletion of one file by one student - Check the deletion of a submitted file and check the updated count of submitted files.
** Testing submission of multiple files by multiple students - Check the submission of multiple files and check the updated count of submitted files.
** Testing deletion of multiple files by multiple students - Check the deletion of multiple submitted files and check the updated count of submitted files.

 
We can conclusively say that, after refactoring the submitted content controller, the query time for retrieving submissions will improve significantly as they are stored together on a team-basis rather than for each participant.

Video demo of our work can be found at https://www.youtube.com/watch?v=VHVWF_UKgOc&feature=youtu.be 
GitHub repository containing the refactoring changes can be found at https://github.com/nitinnagaraja/expertiza/ 
Link to the pull request to Expertiza is https://github.com/expertiza/expertiza/pull/629

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T02:19:53Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

The project was divided into 4 categories:
# Database migrations
# Refactor ''submitted_hyperlink'' related methods
# Refactor ''directory_num'' related methods
# Testing
 

We followed the steps listed below in the process of refactoring the submitted content controller:

* Writing database migrations to move the ''submitted_hyperlinks'' and ''directory_num'' attributes from the Participants table to the Teams table.
 
* Rewriting ''submitted_hyperlinks'' related methods in the Participants model to read from and write to the Teams table.
* Modifying the corresponding views to read ''hyperlinks_array'' instead of ''hyperlinks''. ''hyperlinks_array'' stores the the submissions of all the team members of a team.
 
* Removing ''directory_num'' related methods from the participant model.
* Rewriting ''directory_num'' related methods in the team model.
* Rewriting the corresponding views to read ''directory_num'' from the teams table instead of the participants table.
 
* For testing, we first created fixtures for all required tables.
* We tested our changes by writing functional tests to test the SubmittedContentController.
* Our test suite included the following tests:
** Testing submission of a hyperlink by one student - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of two hyperlinks by two students in a team - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of the same hyperlink by two students in a team - Check that the duplicate hyperlinks does not get stored.
** Testing deletion of a hyperlink - Check the count of submmited hyperlinks and the updated list is displayed correctly from the UI.
** Testing submission of one file by one student - Check the submission of a file and check the updated count of submitted files.
** Testing deletion of one file by one student - Check the deletion of a submitted file and check the updated count of submitted files.
** Testing submission of multiple files by multiple students - Check the submission of multiple files and check the updated count of submitted files.
** Testing deletion of multiple files by multiple students - Check the deletion of multiple submitted files and check the updated count of submitted files.

We can conclusively say that, after refactoring the submitted content controller, the query time for retrieving submissions will improve significantly as they are stored together on a team-basis rather than for each participant.

Video demo of our work can be found at https://www.youtube.com/watch?v=VHVWF_UKgOc&feature=youtu.be 
GitHub repository containing the refactoring changes can be found at https://github.com/nitinnagaraja/expertiza/ 
Link to the pull request to Expertiza is https://github.com/expertiza/expertiza/pull/629

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T02:18:39Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

The project was divided into 4 categories:
# Database migrations
# Refactor ''submitted_hyperlink'' related methods
# Refactor ''directory_num'' related methods
# Testing

We followed the steps listed below in the process of refactoring the submitted content controller:

* Writing database migrations to move the ''submitted_hyperlinks'' and ''directory_num'' attributes from the Participants table to the Teams table.

* Rewriting ''submitted_hyperlinks'' related methods in the Participants model to read from and write to the Teams table.
* Modifying the corresponding views to read ''hyperlinks_array'' instead of ''hyperlinks''. ''hyperlinks_array'' stores the the submissions of all the team members of a team.

* Removing ''directory_num'' related methods from the participant model.
* Rewriting ''directory_num'' related methods in the team model.
* Rewriting the corresponding views to read ''directory_num'' from the teams table instead of the participants table.
* For testing, we first created fixtures for all required tables.
* We tested our changes by writing functional tests to test the SubmittedContentController.

* Our test suite included the following tests:
** Testing submission of a hyperlink by one student - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of two hyperlinks by two students in a team - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of the same hyperlink by two students in a team - Check that the duplicate hyperlinks does not get stored.
** Testing deletion of a hyperlink - Check the count of submmited hyperlinks and the updated list is displayed correctly from the UI.
** Testing submission of one file by one student - Check the submission of a file and check the updated count of submitted files.
** Testing deletion of one file by one student - Check the deletion of a submitted file and check the updated count of submitted files.
** Testing submission of multiple files by multiple students - Check the submission of multiple files and check the updated count of submitted files.
** Testing deletion of multiple files by multiple students - Check the deletion of multiple submitted files and check the updated count of submitted files.

We can conclusively say that, after refactoring the submitted content controller, the query time for retrieving submissions will improve significantly as they are stored together on a team-basis rather than for each participant.

Video demo of our work can be found at https://www.youtube.com/watch?v=VHVWF_UKgOc&feature=youtu.be
GitHub repository containing the refactoring changes can be found at https://github.com/nitinnagaraja/expertiza/
Link to the pull request to Expertiza is https://github.com/expertiza/expertiza/pull/629

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T02:16:15Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

We followed the following steps in the process of refactoring the submitted content controller:

* Writing database migrations to move the ''submitted_hyperlinks'' and ''directory_num'' attributes from the Participants table to the Teams table.
* Rewriting ''submitted_hyperlinks'' related methods in the Participants model to read from and write to the Teams table.
* Modifying the corresponding views to read ''hyperlinks_array'' instead of ''hyperlinks''. ''hyperlinks_array'' stores the the submissions of all the team members of a team.
* Removing ''directory_num'' related methods from the participant model.
* Rewriting ''directory_num'' related methods in the team model.
* Rewriting the corresponding views to read ''directory_num'' from the teams table instead of the participants table.
* For testing, we first created fixtures for all required tables.
* We tested our changes by writing functional tests to test the SubmittedContentController.
* Our test suite included the following tests:
** Testing submission of a hyperlink by one student - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of two hyperlinks by two students in a team - Check the count of submmited hyperlinks, verify that the hyperlink is stored properly in the database and displayed correctly from the UI.
** Testing submission of the same hyperlink by two students in a team - Check that the duplicate hyperlinks does not get stored.
** Testing deletion of a hyperlink - Check the count of submmited hyperlinks and the updated list is displayed correctly from the UI.
** Testing submission of one file by one student - Check the submission of a file and check the updated count of submitted files.
** Testing deletion of one file by one student - Check the deletion of a submitted file and check the updated count of submitted files.
** Testing submission of multiple files by multiple students - Check the submission of multiple files and check the updated count of submitted files.
** Testing deletion of multiple files by multiple students - Check the deletion of multiple submitted files and check the updated count of submitted files.

We can conclusively say that, after refactoring the submitted content controller, the query time for retrieving submissions will improve significantly as they are stored together on a team-basis rather than for each participant.

Video demo of our work can be found at https://www.youtube.com/watch?v=VHVWF_UKgOc&feature=youtu.be
GitHub repository containing the refactoring changes can be found at https://github.com/nitinnagaraja/expertiza/
Link to the pull request to Expertiza is https://github.com/expertiza/expertiza/pull/629

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T01:02:11Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

We followed the following steps in the process of refactoring the submitted content controller:

# Writing database migrations to move the ''submitted_hyperlinks'' and ''directory_num'' attributes from the Participants table to the Teams table.
# Rewriting ''submitted_hyperlinks'' related methods in the Participants model to read from and write to the Teams table.
# Modifying the corresponding views to read ''hyperlinks_array'' instead of ''hyperlinks''. ''hyperlinks_array'' stores the the submissions of all the team members of a team.
# Removing ''directory_num'' related methods from the participant model.
# Rewriting ''directory_num'' related methods in the team model.
# Rewriting the corresponding views to read ''directory_num'' from the teams table instead of the participants table.
# For testing, we first created fixtures for all required tables.
# We tested our changes by writing functional tests to test the SubmittedContentController.
* Our test suite included the following tests:
** a

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T00:15:40Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

We made the following changes in the process of refactoring the submitted content controller.

<source lang ="diff">
def participant_params
- params.require(:participant).permit(:can_submit,:can_review,:user_id,:parent_id,:directory_num,:submitted_at,:permission_granted,:penalty_accumulated,:submitted_hypelinks,:grade,:type,:handle,:time_stamp,:digital_signature,:duty,:can_take_quiz)
+ params.require(:participant).permit(:can_submit,:can_review,:user_id,:parent_id,:submitted_at,:permission_granted,:penalty_accumulated,:grade,:type,:handle,:time_stamp,:digital_signature,:duty,:can_take_quiz)
end
</source>

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T00:13:04Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

We made the following changes in the process of refactoring the submitted content controller.

<source lang ="diff">
def participant_params
- params.require(:participant).permit(:can_submit,:can_review,:user_id,:parent_id,:directory_num,:submitted_at,:permission_granted,:penalty_accumulated,:submitted_hypelinks,:grade,:type,:handle,:time_stamp,:digital_signature,:duty,:can_take_quiz) 

+ params.require(:participant).permit(:can_submit,:can_review,:user_id,:parent_id,:submitted_at,:permission_granted,:penalty_accumulated,:grade,:type,:handle,:time_stamp,:digital_signature,:duty,:can_take_quiz)
end
</source>

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T00:12:11Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

We made the following changes in the process of refactoring the submitted content controller.

<source lang = diff>
def participant_params
- params.require(:participant).permit(:can_submit,:can_review,:user_id,:parent_id,:directory_num,:submitted_at,:permission_granted,:penalty_accumulated,:submitted_hypelinks,:grade,:type,:handle,:time_stamp,:digital_signature,:duty,:can_take_quiz) 

+ params.require(:participant).permit(:can_submit,:can_review,:user_id,:parent_id,:submitted_at,:permission_granted,:penalty_accumulated,:grade,:type,:handle,:time_stamp,:digital_signature,:duty,:can_take_quiz)
end
</source>

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T00:08:41Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

We made the following changes in the process of refactoring the submitted content controller.

<pre>
def participant_params
- params.require(:participant).permit(:can_submit,:can_review,:user_id,:parent_id,:directory_num,:submitted_at,:permission_granted,:penalty_accumulated,:submitted_hypelinks,:grade,:type,:handle,:time_stamp,:digital_signature,:duty,:can_take_quiz) 

+ params.require(:participant).permit(:can_submit,:can_review,:user_id,:parent_id,:submitted_at,:permission_granted,:penalty_accumulated,:grade,:type,:handle,:time_stamp,:digital_signature,:duty,:can_take_quiz)
end 
</pre>

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T00:06:22Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

We made the following changes in the process of refactoring the submitted content controller.

<pre>
def participant_params
- params.require(:participant).permit(:can_submit,:can_review,:user_id,:parent_id,:directory_num,:submitted_at,:permission_granted,:penalty_accumulated,:submitted_hypelinks,:grade,:type,:handle,:time_stamp,:digital_signature,:duty,:can_take_quiz)
+ params.require(:participant).permit(:can_submit,:can_review,:user_id,:parent_id,:submitted_at,:permission_granted,:penalty_accumulated,:grade,:type,:handle,:time_stamp,:digital_signature,:duty,:can_take_quiz)
end
</pre>

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-05T00:05:13Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

We made the following changes in the process of refactoring the submitted content controller.

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-12-04T22:39:44Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Accomplishments =

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-11-09T06:34:14Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= Future Work =
A proposal for further improvement would be to possibly create a new '''submitted_content''' table in the database. This table could include attributes like '''user_id''', '''team_id''', '''can_submit''', '''hyperlink''', '''directory_num''', '''uploaded_at''', '''updated_at'''. This approach would resolve the existing hyperlinks issue and more importantly, aid in recording a history of the submitted hyperlinks. There could be a “Show previous submissions” view for a team. So, if ever there’s a scenario where a student or an instructor needs to revert or go back and check a previous submission, he/she can easily access it from this table.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-11-09T06:25:07Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an [https://en.wikipedia.org/wiki/Open_source open source] application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= References =
<references/>

CSC/ECE 517 Fall 2015 E1576 Refactoring submitted content (hyperlinks and files)

2015-11-09T06:24:29Z

Nnagara2:

= Introduction to Expertiza =
Expertiza<ref>https://github.com/expertiza/expertiza</ref> is a project developed using Ruby on Rails<ref>http://guides.rubyonrails.org/getting_started.html</ref>. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on remote server and Wiki submissions. It is an open source application and the code can be cloned from [https://github.com/expertiza/expertiza GitHub]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

= Problem Statement =

== Files involved ==
*'''assignment_participant.rb'''
*'''assignment_team.rb''' and
*views related to submitted hyperlinks and files ('''submitted_content/_hyperlink.html.erb''', '''submitted_content/_submitted_files.html.erb''')

== What it does ==
It handles the display, submission, deletion of hyperlinks and files by the teams.

== What is wrong with it ==
The submitted hyperlinks and files are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments).
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. Similar overhead happens when a team member wants to delete a submitted hyperlink. Also, the '''directory_num''' field needs to be moved from the '''participants''' table to the '''teams''' table. It signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''.

== What needs to be done ==
*Create a new column '''hyperlinks''' in the '''teams''' table.
*Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. Duplicate hyperlinks need to be removed.
*Write db migration, remove the '''hyperlinks''' field from '''participants''' table.
*Rewrite the hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' to make sure the new code works with the new db design.
*Make sure when doing the peer-review, the reviewer can see the submitted content from the reviewees.
*Make sure when instructor see the peer-review records, they can see the submitted content from the reviewees.
*Write db migration, move the '''directory_num''' field (also the content, of course) to the '''teams''' table.
*Move the '''set_student_directory_num''' method from '''participants_controller''' to '''teams_controller''', then refactor this method into smaller methods.
**This method no longer needs to test all the participants.
**Check if any of them have '''directory_num'''. If so, instead, it should just check the '''directory_num''' from '''teams''' table.
*Make change to the submitted-file-related code to make it work with the new design.
*Write test cases to test student-submitted hyperlinks and files.

= Problem Description =
The main purpose of this project is to improve how submitted hyperlinks are recorded in Expertiza in the current scheme. As of now, the submitted hyperlinks are stored in '''participants''' table, which means they are associated with individuals instead of team. This is not a good design because in Expertiza, students are always grouped in teams, even when there is only one person in each team (individual assignments). This results in a lot of redundant data.
Currently, when a team member wants to see all the submitted hyperlinks of his team, Expertiza needs to load all the submitted hyperlinks from each participant in this team and merge them all before display. When a team member wants to remove one hyperlink, Expertiza needs to loop over all the participants, which makes the code complicated and results in unnecessary computations.
Another aspect of this project requires moving the field '''directory_num''' from the '''participants''' table to the '''teams''' table. The '''directory_num''' field signifies the sub-directory which stores all the files submitted by this team. Intuitively it is clear that each team should ideally have only one common copy of '''directory_num'''. In the current design, since this field is in the '''participants''' table, we are forced to guarantee that all the team members have the same '''directory_num''', which results in redundant code.

= Scope =
This project can be divided into four major work items:
#Moving the '''hyperlinks''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''directory_num''' field from the '''participants''' table to the '''teams''' table. After this change, relevant changes are needed in the code to support this database change.
#Moving the '''set_student_directory_num''' method from the '''participants_controller''' to the '''teams_controller'''. It just needs to check '''directory_num''' from the '''team''' table.
#Write test cases to verify student-submitted hyperlinks and files.

= Implementation =
Expertiza files that will be modified for each work item along with the description:
{| class="wikitable"
! scope="col" style="width: 50px;" | Work Item #
! scope="col" style="width: 225px;" | Files to be modified
! scope="col" style="width: 500px;" | Description
|-
| 1 || assignment_participant.rb assignment_team.rb db:participants table db:teams table || - Create a new column '''hyperlinks''' in '''teams''' table - Write db migration, move all the participants’ submitted hyperlinks from '''participants''' table into '''teams''' table. All duplicated hyperlinks have to be removed. - Write db migration, remove the '''hyperlinks''' field from '''participants''' table. - hyperlink-related methods in both '''assignment_participant.rb''' and '''assignment_team.rb''' have to be rewritten to make sure the new code works with the new db design.
|-
| 2 || participants_controller.rb teams_controller.rb db:participants table db:teams table || - Write db migration, move the '''directory_num''' field (also the content) to '''teams''' table. - Move the '''set_student_directory_num''' from '''participant_controller''' to '''team_controller''', then refactor this method into smaller methods. - This method no longer needs to test all the participants and see if any of them have '''directory_num''', instead, it just check the '''directory_num''' from '''teams''' table. - Make change to the submitted-file-related code to make sure it works with the new design.
|-
| 3 || New files to be added || - Write test cases to test student-submitted hyperlinks and files.
|}

= Design =
Consider a simple use case where we need to retrieve the submitted hyperlinks and files corresponding to '''team_id''', say, '''23841'''. Since there is no existing correlation between teams and submitted content, we will first need to look up the '''participants''' in the team using the '''teams_users''' table. And then, using those user_id values one at a time, we need to look up the '''participants''' table.

[[File:db.jpg]]

Finally, we need to merge the results before displaying it.

<pre>
def hyperlinks
links = Array.new
self.participants.each { |team_member|
links.concat(team_member.hyperlinks_array) if team_member.hyperlinks_array}
links
end
</pre>

So, it becomes a tedious 3-step process. It is evident from this example that the current design is inefficient.

Instead, if the hyperlinks data were available in '''teams''' table, we could directly access all the submitted content for a team in one shot, making it much more streamlined.

As a part of this change, we’ll have to move the following routines in '''assignment_participants.rb''', which deal hyperlink handling to '''assignment_team.rb'''.

<pre>
# Appends the hyperlink to a list that is stored in YAML format in the DB
# @exception If is hyperlink was already there
# If it is an invalid URL
def submit_hyperlink(hyperlink)
hyperlink.strip!
raise "The hyperlink cannot be empty" if hyperlink.empty?
url = URI.parse(hyperlink)
# If not a valid URL, it will throw an exception
Net::HTTP.start(url.host, url.port)
hyperlinks = self.hyperlinks_array
hyperlinks << hyperlink
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

# Note: This method is not used yet. It is here in the case it will be
needed.
# @exception If the index does not exist in the array
def remove_hyperlink(hyperlink_to_delete)
hyperlinks = self.hyperlinks_array
hyperlinks.delete(hyperlink_to_delete)
self.submitted_hyperlinks = YAML::dump(hyperlinks)
self.save
end

def hyperlinks
team.try(:hyperlinks) || []
end

def hyperlinks_array
self.submitted_hyperlinks.blank? ? [] :YAML::load(self.submitted_hyperlinks)
end
</pre>

Similar refactoring work needs to be done for the '''directory_num''' field as well.
Finally, the refactoring needs to be thoroughly tested by writing test cases for student-submitted hyperlinks and files by making sure that:
*the submitted hyperlinks and files are correctly displayed on the submitted content page.
*the reviewer can see the submitted content from the reviewees.
*the instructor can see the submitted content from the reviewees.

== Use Cases ==
'''Use Case 1:''' Submit hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the hyperlink.

'''Postconditions:''' The submitted hyperlink should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted hyperlink is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted hyperlink.
#A reviewer should be able to see the submitted hyperlink.
#An instructor should be able to see the submitted hyperlink.

'''Use Case 2:''' Submit file for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to submit a file on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to submit the file.

'''Postconditions:''' The directory_num field which stores the directory number of the directory storing all the submitted files for a team should be stored in the teams table of the database.

'''Success Scenario:'''
#The submitted file is visible every time the student views the “Your work” section for the Assignment.
#All other team members should be able to view the submitted file.
#A reviewer should be able to see the submitted file.
#An instructor should be able to see the submitted file.

'''Use Case 3:''' Delete hyperlink for an assignment by student.

'''Description:''' A student who is an assignment participant should be able to delete submitted hyperlink on the “Your work” section of an assignment.

'''Preconditions:''' Student should be a participant for the assignment he is trying to delete the hyperlink.

'''Postconditions:''' The deleted hyperlink should be removed from the teams table in DB.

'''Success Scenario:'''
#The deleted hyperlink should not be visible the next time the student clicks on “Your work” section.
#All other team members should not see the deleted hyperlink.
#A reviewer should not be able to see the deleted hyperlink.
#An instructor should not be able to see the deleted hyperlink.

= References =
<references/>

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-11-08T02:55:58Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza-based OSS project, which aimed at refactoring the ''ReviewMappingController''.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=

Ensure that MySQL is already setup on your system. If you are using an Ubuntu system, the following commands can be used to install MySQL:
sudo apt-get install mysql-server
sudo apt-get install mysql-client

===Clone the reopsitory===
In your local directory, clone the updated GitHub repository.

git clone https://github.com/rrpod/expertiza.git

Visit https://help.github.com for getting more information on setting up git.

===Installing Gems===

Go to the local expertiza directory:

bundle install

===Running the test cases===

From the expertiza directory, run the following command:

rspec spec/controllers/review_mapping_spec_controller_spec.rb

=Problem statement=
The ''ReviewMappingController'' file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the ''ReviewMappingController'':

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping_strategy'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =
In the process of refactoring, we have actively followed the Ruby coding guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>. We have also followed some design pattern rules like Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>, which state that every class should have responsibility over a single part of functionality provided by software and that responsibility should be entirely encapsulated by the class. All the services and operations within the class should be aligned with that responsibility.

== Refactoring ==

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other function is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping_strategy ===
This function was originally too long. Hence, we modularised it by moving the part of the code that loops over all teams and creates the ReviewResponseMap into a new function.

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===
This method is responsible for returning the team given an assignment submission. It did not have any direct correlation with the reviewer/reviewee. Hence, it was moved to the AssignmentTeam model (assignment_team.rb) file as suggested.

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

==About rspec==
[http://rspec.info/ Rspec] is a Behavior-driven development for Ruby programming language widely used for Test Driven Development. It has its own mocking framework based upon JMock. <ref>https://en.wikipedia.org/wiki/RSpec</ref>

== Testing ==

=== Test Case Development using RSpec ===

====Test Case 1: Check if on getting release mapping it redirects to student review controller====
it "should use release_mapping to redirect to student_review controller" do
get :release_mapping, id: @assignment.id
expect(response).should redirect_to(:controller => 'student_review', :action => 'list', :id=> '828')
end

====Test Case 2: Check if on delete outstanding reviewers it redirects to list mapping====
it "should delete outstanding reviewers to redirect to list_mappings" do
get :delete_outstanding_reviewers, id: @assignment.id, contributor_id: 200
expect(response).should redirect_to(:action => 'list_mappings', :id => 200)
end

====Test Case 3: Check if rendered report matches the required template====
it "should render appropritate response report" do
get :response_report, id: 723
response.should render_template(:response_report)
end

====Test Case 4: Check if rendered report matches the required template for a specific user====
it "should render appropriate response report for the specific user" do
get :response_report, id: 723, :user => {:fullname=> '523, student'}
response.should render_template(:response_report)
end

====Test Case 5: Check if rendered report matches the required template for a specific user with type FeedbackResponseMap====
it "should render appropriate response report for the specific user with type FeedbackResponseMap" do
get :response_report, id: 723, :report => {:type=> 'FeedbackResponseMap'}
response.should render_template(:response_report)
end

=== Testing from the UI ===

'''View Response Report'''
[[File:View_assignment_response_report.png]]

'''View Response Report by name''' 
Search for Reviewer's name "523, student"
[[File:Copy_view_response_report_by_name_-_Copy.png]]

'''View Feedback Response Map'''
[[File:Copy_view_feedback_response_map_report_-_Copy.png]]

= Conclusion =
By refactoring ''ReviewMappingController'', extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository used for development]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-11-01T04:59:54Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza-based OSS project, which aimed at refactoring the ''ReviewMappingController''.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=

Ensure that MySQL is already setup on your system. If you are using an Ubuntu system, the following commands can be used to install MySQL:
sudo apt-get install mysql-server
sudo apt-get install mysql-client

===Clone the reopsitory===
In your local directory, clone the Github repository.

git clone https://github.com/rrpod/expertiza.git

Visit https://help.github.com for getting more information on setting up git.

===Installing Gems===

Go to the local expertiza directory:

bundle install

===Running the test cases===

From the expertiza directory, run the following command:

rspec spec/controllers/review_mapping_spec_controller_spec.rb

=Problem statement=
The ''ReviewMappingController'' file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the ''ReviewMappingController'':

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping_strategy'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =
In the process of refactoring, we have actively followed the Ruby coding guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>. We have also followed some design pattern rules like Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>, which state that every class should have responsibility over a single part of functionality provided by software and that responsibility should be entirely encapsulated by the class. All the services and operations within the class should be aligned with that responsibility.

== Refactoring ==

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other function is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping_strategy ===
This function was originally too long. Hence, we modularised it by moving the part of the code that loops over all teams and creates the ReviewResponseMap into a new function.

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===
This method is responsible for returning the team given an assignment submission. It did not have any direct correlation with the reviewer/reviewee. Hence, it was moved to the AssignmentTeam model (assignment_team.rb) file as suggested.

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

==About rspec==
[http://rspec.info/ Rspec] is a Behavior-driven development for Ruby programming language widely used for Test Driven Development. It has its own mocking framework based upon JMock. <ref>https://en.wikipedia.org/wiki/RSpec</ref>

== Testing ==

=== Test Case Development using RSpec ===

====Test Case 1: Check if on getting release mapping it redirects to student review controller====
it "should use release_mapping to redirect to student_review controller" do
get :release_mapping, id: @assignment.id
expect(response).should redirect_to(:controller => 'student_review', :action => 'list', :id=> '828')
end

====Test Case 2: Check if on delete outstanding reviewers it redirects to list mapping====
it "should delete outstanding reviewers to redirect to list_mappings" do
get :delete_outstanding_reviewers, id: @assignment.id, contributor_id: 200
expect(response).should redirect_to(:action => 'list_mappings', :id => 200)
end

====Test Case 3: Check if rendered report matches the required template====
it "should render appropritate response report" do
get :response_report, id: 723
response.should render_template(:response_report)
end

====Test Case 4: Check if rendered report matches the required template for a specific user====
it "should render appropriate response report for the specific user" do
get :response_report, id: 723, :user => {:fullname=> '523, student'}
response.should render_template(:response_report)
end

====Test Case 5: Check if rendered report matches the required template for a specific user with type FeedbackResponseMap====
it "should render appropriate response report for the specific user with type FeedbackResponseMap" do
get :response_report, id: 723, :report => {:type=> 'FeedbackResponseMap'}
response.should render_template(:response_report)
end

=== Testing from the UI ===

'''View Response Report'''
[[File:View_assignment_response_report.png]]

'''View Response Report by name''' 
Search for Reviewer's name "523, student"
[[File:Copy_view_response_report_by_name_-_Copy.png]]

'''View Feedback Response Map'''
[[File:Copy_view_feedback_response_map_report_-_Copy.png]]

= Conclusion =
By refactoring ''ReviewMappingController'', extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository used for development]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-11-01T04:57:54Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza-based OSS project, which aimed at refactoring the ''ReviewMappingController''.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=

Ensure that MySQL is already setup on your system. If you are using an Ubuntu system, the following commands can be used to install MySQL:
sudo apt-get install mysql-server
sudo apt-get install mysql-client

===Clone the reopsitory===
In your local directory, clone the Github repository.

git clone https://github.com/rrpod/expertiza.git

Visit https://help.github.com for getting more information on setting up git.

===Installing Gems===

Go to the local expertiza directory:

bundle install

===Running the test cases===

From the expertiza directory, run the following command:

rspec spec/controllers/review_mapping_spec_controller_spec.rb

=Problem statement=
The ''ReviewMappingController'' file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the ''ReviewMappingController'':

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping_strategy'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =
In the process of refactoring, we have actively followed the Ruby coding guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>. We have also followed some design pattern rules like Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>, which state that every class should have responsibility over a single part of functionality provided by software and that responsibility should be entirely encapsulated by the class. All the services and operations within the class should be aligned with that responsibility.

== Refactoring ==

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other function is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping_strategy ===
This function was originally too long. Hence, we modularised it by moving the part of the code that loops over all teams and creates the ReviewResponseMap into a new function.

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===
This method is responsible for returning the team given an assignment submission. It did not have any direct correlation with the reviewer/reviewee. Hence, it was moved to the AssignmentTeam model (assignment_team.rb) file as suggested.

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

==About rspec==
[http://rspec.info/ Rspec] is a Behavior-driven development for Ruby programming language widely used for Test Driven Development. It has its own mocking framework based upon JMock. <ref>https://en.wikipedia.org/wiki/RSpec</ref>

== Testing ==

=== Test Case Development using RSpec ===

====Test Case 1: Check if on getting release mapping it redirects to student review controller====
it "should use release_mapping to redirect to student_review controller" do
get :release_mapping, id: @assignment.id
expect(response).should redirect_to(:controller => 'student_review', :action => 'list', :id=> '828')
end

====Test Case 2: Check if on delete outstanding reviewers it redirects to list mapping====
it "should delete outstanding reviewers to redirect to list_mappings" do
get :delete_outstanding_reviewers, id: @assignment.id, contributor_id: 200
expect(response).should redirect_to(:action => 'list_mappings', :id => 200)
end

====Test Case 3: Check if rendered report matches the required template====
it "should render appropritate response report" do
get :response_report, id: 723
response.should render_template(:response_report)
end

====Test Case 4: Check if rendered report matches the required template for a specific user====
it "should render appropriate response report for the specific user" do
get :response_report, id: 723, :user => {:fullname=> '523, student'}
response.should render_template(:response_report)
end

====Test Case 5: Check if rendered report matches the required template for a specific user with type FeedbackResponseMap====
it "should render appropriate response report for the specific user with type FeedbackResponseMap" do
get :response_report, id: 723, :report => {:type=> 'FeedbackResponseMap'}
response.should render_template(:response_report)
end

=== Testing from the UI ===

'''View Response Report'''
[[File:View_assignment_response_report.png]]

'''View Response Report by name'''
Search for Reviewer's name "523, student"
[[File:Copy_view_response_report_by_name_-_Copy.png]]

'''View Feedback Response Map'''
[[File:Copy_view_feedback_response_map_report_-_Copy.png]]

= Conclusion =
By refactoring ''ReviewMappingController'', extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository used for development]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-11-01T04:47:24Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza-based OSS project, which aimed at refactoring the ''ReviewMappingController''.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=

Ensure that MySQL is already setup on your system. If you are using an Ubuntu system, the following commands can be used to install MySQL:
sudo apt-get install mysql-server
sudo apt-get install mysql-client

===Clone the reopsitory===
In your local directory, clone the Github repository.

git clone https://github.com/rrpod/expertiza.git

Visit https://help.github.com for getting more information on setting up git.

===Installing Gems===

Go to the local expertiza directory:

bundle install

===Running the test cases===

From the expertiza directory, run the following command:

rspec spec/controllers/review_mapping_spec_controller_spec.rb

=Problem statement=
The ''ReviewMappingController'' file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the ''ReviewMappingController'':

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping_strategy'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =
In the process of refactoring, we have actively followed the Ruby coding guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>. We have also followed some design pattern rules like Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>, which state that every class should have responsibility over a single part of functionality provided by software and that responsibility should be entirely encapsulated by the class. All the services and operations within the class should be aligned with that responsibility.

== Refactoring ==

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other function is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping_strategy ===
This function was originally too long. Hence, we modularised it by moving the part of the code that loops over all teams and creates the ReviewResponseMap into a new function.

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===
This method is responsible for returning the team given an assignment submission. It did not have any direct correlation with the reviewer/reviewee. Hence, it was moved to the AssignmentTeam model (assignment_team.rb) file as suggested.

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

==About rspec==
[http://rspec.info/ Rspec] is a Behavior-driven development for Ruby programming language widely used for Test Driven Development. It has its own mocking framework based upon JMock. <ref>https://en.wikipedia.org/wiki/RSpec</ref>

== Testing ==

=== Test Case Development using RSpec ===

====Test Case 1: Check if on getting release mapping it redirects to student review controller====
it "should use release_mapping to redirect to student_review controller" do
get :release_mapping, id: @assignment.id
expect(response).should redirect_to(:controller => 'student_review', :action => 'list', :id=> '828')
end

====Test Case 2: Check if on delete outstanding reviewers it redirects to list mapping====
it "should delete outstanding reviewers to redirect to list_mappings" do
get :delete_outstanding_reviewers, id: @assignment.id, contributor_id: 200
expect(response).should redirect_to(:action => 'list_mappings', :id => 200)
end

====Test Case 3: Check if rendered report matches the required template====
it "should render appropritate response report" do
get :response_report, id: 723
response.should render_template(:response_report)
end

====Test Case 4: Check if rendered report matches the required template for a specific user====
it "should render appropriate response report for the specific user" do
get :response_report, id: 723, :user => {:fullname=> '523, student'}
response.should render_template(:response_report)
end

====Test Case 5: Check if rendered report matches the required template for a specific user with type FeedbackResponseMap====
it "should render appropriate response report for the specific user with type FeedbackResponseMap" do
get :response_report, id: 723, :report => {:type=> 'FeedbackResponseMap'}
response.should render_template(:response_report)
end

=== Testing from the UI ===

View Response Report
[[File:View_assignment_response_report.png]]

View Response Report by name
[[File:Copy_view_response_report_by_name_-_Copy.png]]

View Feedback Response Map
[[File:Copy_view_feedback_response_map_report_-_Copy.png]]

= Conclusion =
By refactoring ''ReviewMappingController'', extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository used for development]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-11-01T04:46:48Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza-based OSS project, which aimed at refactoring the ''ReviewMappingController''.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=

Ensure that MySQL is already setup on your system. If you are using an Ubuntu system, the following commands can be used to install MySQL:
sudo apt-get install mysql-server
sudo apt-get install mysql-client

===Clone the reopsitory===
In your local directory, clone the Github repository.

git clone https://github.com/rrpod/expertiza.git

Visit https://help.github.com for getting more information on setting up git.

===Installing Gems===

Go to the local expertiza directory:

bundle install

===Running the test cases===

From the expertiza directory, run the following command:

rspec spec/controllers/review_mapping_spec_controller_spec.rb

=Problem statement=
The ''ReviewMappingController'' file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the ''ReviewMappingController'':

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping_strategy'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =

== Refactoring ==
In the process of refactoring, we have actively followed the Ruby coding guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>. We have also followed some design pattern rules like Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>, which state that every class should have responsibility over a single part of functionality provided by software and that responsibility should be entirely encapsulated by the class. All the services and operations within the class should be aligned with that responsibility.

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other function is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping_strategy ===
This function was originally too long. Hence, we modularised it by moving the part of the code that loops over all teams and creates the ReviewResponseMap into a new function.

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===
This method is responsible for returning the team given an assignment submission. It did not have any direct correlation with the reviewer/reviewee. Hence, it was moved to the AssignmentTeam model (assignment_team.rb) file as suggested.

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

==About rspec==
[http://rspec.info/ Rspec] is a Behavior-driven development for Ruby programming language widely used for Test Driven Development. It has its own mocking framework based upon JMock. <ref>https://en.wikipedia.org/wiki/RSpec</ref>

== Testing ==

=== Test Case Development using RSpec ===

====Test Case 1: Check if on getting release mapping it redirects to student review controller====
it "should use release_mapping to redirect to student_review controller" do
get :release_mapping, id: @assignment.id
expect(response).should redirect_to(:controller => 'student_review', :action => 'list', :id=> '828')
end

====Test Case 2: Check if on delete outstanding reviewers it redirects to list mapping====
it "should delete outstanding reviewers to redirect to list_mappings" do
get :delete_outstanding_reviewers, id: @assignment.id, contributor_id: 200
expect(response).should redirect_to(:action => 'list_mappings', :id => 200)
end

====Test Case 3: Check if rendered report matches the required template====
it "should render appropritate response report" do
get :response_report, id: 723
response.should render_template(:response_report)
end

====Test Case 4: Check if rendered report matches the required template for a specific user====
it "should render appropriate response report for the specific user" do
get :response_report, id: 723, :user => {:fullname=> '523, student'}
response.should render_template(:response_report)
end

====Test Case 5: Check if rendered report matches the required template for a specific user with type FeedbackResponseMap====
it "should render appropriate response report for the specific user with type FeedbackResponseMap" do
get :response_report, id: 723, :report => {:type=> 'FeedbackResponseMap'}
response.should render_template(:response_report)
end

=== Testing from the UI ===

View Response Report
[[File:View_assignment_response_report.png]]

View Response Report by name
[[File:Copy_view_response_report_by_name_-_Copy.png]]

View Feedback Response Map
[[File:Copy_view_feedback_response_map_report_-_Copy.png]]

= Conclusion =
By refactoring ''ReviewMappingController'', extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository used for development]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-11-01T04:44:40Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza-based OSS project, which aimed at refactoring the ''ReviewMappingController''.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=

Ensure that MySQL is already setup on your system. If you are using an Ubuntu system, the following commands can be used to install MySQL:
sudo apt-get install mysql-server
sudo apt-get install mysql-client

===Clone the reopsitory===
In your local directory, clone the Github repository.

git clone https://github.com/rrpod/expertiza.git

Visit https://help.github.com for getting more information on setting up git.

===Installing Gems===

Go to the local expertiza directory:

bundle install

===Running the test cases===

From the expertiza directory, run the following command:

rspec spec/controllers/review_mapping_spec_controller_spec.rb

=Problem statement=
The ''ReviewMappingController'' file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the ''ReviewMappingController'':

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping_strategy'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =

== Refactoring ==
guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>
Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other function is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping_strategy ===
This function was originally too long. Hence, we modularised it by moving the part of the code that loops over all teams and creates the ReviewResponseMap into a new function.

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===
This method is responsible for returning the team given an assignment submission. It did not have any direct correlation with the reviewer/reviewee. Hence, it was moved to the AssignmentTeam model (assignment_team.rb) file as suggested.

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

==About rspec==
[http://rspec.info/ Rspec] is a Behavior-driven development for Ruby programming language widely used for Test Driven Development. It has its own mocking framework based upon JMock. <ref>https://en.wikipedia.org/wiki/RSpec</ref>

== Testing ==

=== Test Case Development using RSpec ===

====Test Case 1: Check if on getting release mapping it redirects to student review controller====
it "should use release_mapping to redirect to student_review controller" do
get :release_mapping, id: @assignment.id
expect(response).should redirect_to(:controller => 'student_review', :action => 'list', :id=> '828')
end

====Test Case 2: Check if on delete outstanding reviewers it redirects to list mapping====
it "should delete outstanding reviewers to redirect to list_mappings" do
get :delete_outstanding_reviewers, id: @assignment.id, contributor_id: 200
expect(response).should redirect_to(:action => 'list_mappings', :id => 200)
end

====Test Case 3: Check if rendered report matches the required template====
it "should render appropritate response report" do
get :response_report, id: 723
response.should render_template(:response_report)
end

====Test Case 4: Check if rendered report matches the required template for a specific user====
it "should render appropriate response report for the specific user" do
get :response_report, id: 723, :user => {:fullname=> '523, student'}
response.should render_template(:response_report)
end

====Test Case 5: Check if rendered report matches the required template for a specific user with type FeedbackResponseMap====
it "should render appropriate response report for the specific user with type FeedbackResponseMap" do
get :response_report, id: 723, :report => {:type=> 'FeedbackResponseMap'}
response.should render_template(:response_report)
end

=== Testing from the UI ===

View Response Report
[[File:View_assignment_response_report.png]]

View Response Report by name
[[File:Copy_view_response_report_by_name_-_Copy.png]]

View Feedback Response Map
[[File:Copy_view_feedback_response_map_report_-_Copy.png]]

= Conclusion =
By refactoring ''ReviewMappingController'', extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository used for development]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

File:Copy view feedback response map report - Copy.png

2015-11-01T04:44:27Z

Nnagara2:

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-11-01T04:37:59Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza-based OSS project, which aimed at refactoring the ''ReviewMappingController''.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=

Ensure that MySQL is already setup on your system. If you are using an Ubuntu system, the following commands can be used to install MySQL:
sudo apt-get install mysql-server
sudo apt-get install mysql-client

===Clone the reopsitory===
In your local directory, clone the Github repository.

git clone https://github.com/rrpod/expertiza.git

Visit https://help.github.com for getting more information on setting up git.

===Installing Gems===

Go to the local expertiza directory:

bundle install

===Running the test cases===

From the expertiza directory, run the following command:

rspec spec/controllers/review_mapping_spec_controller_spec.rb

=Problem statement=
The ''ReviewMappingController'' file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the ''ReviewMappingController'':

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping_strategy'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =

== Refactoring ==
guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>
Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other function is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping_strategy ===
This function was originally too long. Hence, we modularised it by moving the part of the code that loops over all teams and creates the ReviewResponseMap into a new function.

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===
This method is responsible for returning the team given an assignment submission. It did not have any direct correlation with the reviewer/reviewee. Hence, it was moved to the AssignmentTeam model (assignment_team.rb) file as suggested.

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

==About rspec==
[http://rspec.info/ Rspec] is a Behavior-driven development for Ruby programming language widely used for Test Driven Development. It has its own mocking framework based upon JMock. <ref>https://en.wikipedia.org/wiki/RSpec</ref>

== Testing ==

=== Test Case Development using RSpec ===

====Test Case 1: Check if on getting release mapping it redirects to student review controller====
it "should use release_mapping to redirect to student_review controller" do
get :release_mapping, id: @assignment.id
expect(response).should redirect_to(:controller => 'student_review', :action => 'list', :id=> '828')
end

====Test Case 2: Check if on delete outstanding reviewers it redirects to list mapping====
it "should delete outstanding reviewers to redirect to list_mappings" do
get :delete_outstanding_reviewers, id: @assignment.id, contributor_id: 200
expect(response).should redirect_to(:action => 'list_mappings', :id => 200)
end

====Test Case 3: Check if rendered report matches the required template====
it "should render appropritate response report" do
get :response_report, id: 723
response.should render_template(:response_report)
end

====Test Case 4: Check if rendered report matches the required template for a specific user====
it "should render appropriate response report for the specific user" do
get :response_report, id: 723, :user => {:fullname=> '523, student'}
response.should render_template(:response_report)
end

====Test Case 5: Check if rendered report matches the required template for a specific user with type FeedbackResponseMap====
it "should render appropriate response report for the specific user with type FeedbackResponseMap" do
get :response_report, id: 723, :report => {:type=> 'FeedbackResponseMap'}
response.should render_template(:response_report)
end

=== Testing from the UI ===

View Response Report
[[File:View_assignment_response_report.png]]

View Response Report by name
[[File:Copy_view_response_report_by_name_-_Copy.png]]

View Feedback Response Map
[[File:Feeback_response_map.png|800px]]

= Conclusion =
By refactoring ''ReviewMappingController'', extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository used for development]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

File:Copy view response report by name - Copy.png

2015-11-01T04:37:35Z

Nnagara2:

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-11-01T04:37:04Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza-based OSS project, which aimed at refactoring the ''ReviewMappingController''.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=

Ensure that MySQL is already setup on your system. If you are using an Ubuntu system, the following commands can be used to install MySQL:
sudo apt-get install mysql-server
sudo apt-get install mysql-client

===Clone the reopsitory===
In your local directory, clone the Github repository.

git clone https://github.com/rrpod/expertiza.git

Visit https://help.github.com for getting more information on setting up git.

===Installing Gems===

Go to the local expertiza directory:

bundle install

===Running the test cases===

From the expertiza directory, run the following command:

rspec spec/controllers/review_mapping_spec_controller_spec.rb

=Problem statement=
The ''ReviewMappingController'' file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the ''ReviewMappingController'':

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping_strategy'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =

== Refactoring ==
guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>
Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other function is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not being used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping_strategy ===
This function was originally too long. Hence, we modularised it by moving the part of the code that loops over all teams and creates the ReviewResponseMap into a new function.

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===
This method is responsible for returning the team given an assignment submission. It did not have any direct correlation with the reviewer/reviewee. Hence, it was moved to the AssignmentTeam model (assignment_team.rb) file as suggested.

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

==About rspec==
[http://rspec.info/ Rspec] is a Behavior-driven development for Ruby programming language widely used for Test Driven Development. It has its own mocking framework based upon JMock. <ref>https://en.wikipedia.org/wiki/RSpec</ref>

== Testing ==

=== Test Case Development using RSpec ===

====Test Case 1: Check if on getting release mapping it redirects to student review controller====
it "should use release_mapping to redirect to student_review controller" do
get :release_mapping, id: @assignment.id
expect(response).should redirect_to(:controller => 'student_review', :action => 'list', :id=> '828')
end

====Test Case 2: Check if on delete outstanding reviewers it redirects to list mapping====
it "should delete outstanding reviewers to redirect to list_mappings" do
get :delete_outstanding_reviewers, id: @assignment.id, contributor_id: 200
expect(response).should redirect_to(:action => 'list_mappings', :id => 200)
end

====Test Case 3: Check if rendered report matches the required template====
it "should render appropritate response report" do
get :response_report, id: 723
response.should render_template(:response_report)
end

====Test Case 4: Check if rendered report matches the required template for a specific user====
it "should render appropriate response report for the specific user" do
get :response_report, id: 723, :user => {:fullname=> '523, student'}
response.should render_template(:response_report)
end

====Test Case 5: Check if rendered report matches the required template for a specific user with type FeedbackResponseMap====
it "should render appropriate response report for the specific user with type FeedbackResponseMap" do
get :response_report, id: 723, :report => {:type=> 'FeedbackResponseMap'}
response.should render_template(:response_report)
end

=== Testing from the UI ===

View Response Report
[[File:View_assignment_response_report.png]]

View Response Report by name
[[File:Response_report_by_name.png|800px]]

View Feedback Response Map
[[File:Feeback_response_map.png|800px]]

= Conclusion =
By refactoring ''ReviewMappingController'', extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository used for development]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

File:View assignment response report.png

2015-11-01T04:36:08Z

Nnagara2:

File:View Response Report.png

2015-11-01T04:27:09Z

Nnagara2:

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T16:00:56Z

Nnagara2:

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T06:20:55Z

Nnagara2:

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T06:18:04Z

Nnagara2:

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T06:17:42Z

Nnagara2:

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T06:17:12Z

Nnagara2:

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T06:15:50Z

Nnagara2:

File:Feeback response map.png

2015-10-31T06:15:19Z

Nnagara2:

File:Response report by name.png

2015-10-31T06:15:01Z

Nnagara2:

File:Response report.png

2015-10-31T06:14:21Z

Nnagara2: uploaded a new version of "File:Response report.png"

File:Response report.png

2015-10-31T06:13:53Z

Nnagara2:

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T06:11:08Z

Nnagara2:

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T06:09:04Z

Nnagara2:

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T06:04:08Z

Nnagara2:

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T06:02:59Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza based OSS project, which aimed at refactoring the ReviewMappingController.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=
<ref>http://wiki.expertiza.ncsu.edu/index.php/Main_Page</ref>

=Problem statement=
The ReviewMappingController file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the ReviewMappingController:

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping_strategy'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =

== Refactoring ==
guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>
Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other functional is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping_strategy ===
This function was originally too long. Hence, we modularised it by moving the part of the code that loops over all teams and creates the ReviewResponseMap into a new function.

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===
This method is responsible for returning the team given an assignment submission. It did not have any direct correlation with the reviewer/reviewee. Hence, it was moved to the AssignmentTeam model (assignment_team.rb) file as suggested.

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

== Test Case Development ==

= Conclusion =
By refactoring ReviewMappingController, extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository used for development]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T06:02:24Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza based OSS project, which aimed at refactoring the ReviewMappingController.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=
<ref>http://wiki.expertiza.ncsu.edu/index.php/Main_Page</ref>

=Problem statement=
The ReviewMappingController file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the review_mapping_controller:

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping_strategy'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =

== Refactoring ==
guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>
Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other functional is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping_strategy ===
This function was originally too long. Hence, we modularised it by moving the part of the code that loops over all teams and creates the ReviewResponseMap into a new function.

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===
This method is responsible for returning the team given an assignment submission. It did not have any direct correlation with the reviewer/reviewee. Hence, it was moved to the AssignmentTeam model (assignment_team.rb) file as suggested.

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

== Test Case Development ==

= Conclusion =
By refactoring review_mapping_controller, extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository used for development]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T06:01:25Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza based OSS project, which aimed at refactoring the ReviewMappingController.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=
<ref>http://wiki.expertiza.ncsu.edu/index.php/Main_Page</ref>

=Problem statement=
The ReviewMappingController file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the review_mapping_controller:

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping_strategy'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =

== Refactoring ==
guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>
Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other functional is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping_strategy ===
This function was originally too long. Hence, we modularised it by moving the part of the code that loops over all teams and creates the ReviewResponseMap into a new function.

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===
This method is responsible for returning the team given an assignment submission. It did not have any direct correlation with the reviewer/reviewee. Hence, it was moved to the AssignmentTeam model (assignment_team.rb) file as suggested.

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

== Test Case Development ==

= Conclusion =
By refactoring review_mapping_controller, extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T05:53:46Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza based OSS project, which aimed at refactoring the ReviewMappingController.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=
<ref>http://wiki.expertiza.ncsu.edu/index.php/Main_Page</ref>

=Problem statement=
The ReviewMappingController file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the review_mapping_controller:

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =

== Refactoring ==
guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>
Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other functional is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping ===

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

== Test Case Development ==

= Conclusion =
By refactoring review_mapping_controller, extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T05:53:33Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza based OSS project, which aimed at refactoring the ReviewMappingController.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=
<ref>http://wiki.expertiza.ncsu.edu/index.php/Main_Page</ref>

=Problem statement=
The ReviewMappingController file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the review_mapping_controller:

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =

== Refactoring ==
guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>
Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other functional is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping ===

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

== Test Case Development ==

== Conclusion ==
By refactoring review_mapping_controller, extraneous and unused code was removed, readability was increased, and tests confirm that its functionality remained intact. Users will experience incrementally better performance, and developers will have an easier time getting up to speed on the software, resulting in heightened developer efficiency and faster turnaround times for new features.

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>

CSC/ECE 517 Fall 2015/oss E1569 JNR

2015-10-31T05:50:14Z

Nnagara2:

E1569: Refactoring ReviewMappingController 
This page provides a description of our Expertiza based OSS project, which aimed at refactoring the ReviewMappingController.

=Introduction=
[http://expertiza.ncsu.edu/ Expertiza] is an [http://en.wikipedia.org/wiki/Open-source_software Open Source] software tool developed at NC State University. It is used to facilitate assignment and course management. It is primarily intended to facilitate assignments being peer reviewed. It is written as a [https://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] application, thus functioning natively in a web environment. It can be cloned from [https://github.com/expertiza/expertiza/ GitHub].

=Refactoring=
[https://en.wikipedia.org/wiki/Code_refactoring Refactoring] is a process designed to change code without modifying the functionality. Refactoring can improve the readability and the logical design of the software, making sure everything is in the right place and has the right name. This allows code to be understood more quickly by a developer, which shortens the time it takes to develop new features.

=Development environment setup=
<ref>http://wiki.expertiza.ncsu.edu/index.php/Main_Page</ref>

=Problem statement=
The ReviewMappingController file in this application (review_mapping_controller.rb) is responsible for setting up mappings between reviewers and reviewees. It essentially connects a reviewer to an assignment. However, it is a fairly bloated file since it has to handle functionality for five different kinds of maps (review response, author feedback, teammate review, meta-review, and quiz response). It is a prime choice for refactoring because the refactoring can clarify the intent of the different methods in the file.

According to the problem statement<ref>https://docs.google.com/document/d/1uWs3zyrupTmrOFuv5IbVWCF4NRvCXqJmg8dZ0wCqgus/edit</ref>, there were 11 tasks involved in refactoring the review_mapping_controller:

* Method ''delete_rofreviewer'' should do the same thing as delete_metareviewer
* Method ''delete_participant'' is not used
* Method ''list_sortable'' is not used
* Method ''automatic_review_mapping'' is too long
* Method ''review_report'' has SQL-like code
* Method ''add_user_to_assignment'' should not be in this controller
* Method ''get_team_from_submission'' should not be in this controller
* Method ''delete_all_reviewers'' doesn’t actually delete all the reviewers, but just the outstanding review response maps. We want to keep this functionality
* Method ''delete_participant'' should not be in this controller
* Method ''name release_reservation'' doesn’t describe the functionality well
* Method ''delete_review'' is not used

= Design Approach =

== Refactoring ==
guidelines <ref>https://docs.google.com/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit#</ref>
Single Responsibility Principle <ref>https://en.wikipedia.org/wiki/Single_responsibility_principle</ref>

=== delete_rofreviewer ===
This function has duplicate functionality to another function, delete_metareviewer, and the other functional is named much better. The method delete_rofreviewer was removed.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== list_sortable ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== automatic_review_mapping ===

=== response_report ===
To make this code easier to read for a pure Ruby developer, the SQL-like code was rewritten with ActiveRecord.

=== add_user_to_assignment ===
This method does not belong in this controller, and it is only ever called by participants_helper. Therefore, the method should go into participants_controller, which is where it was moved.

=== get_team_from_submission ===

=== delete_all_reviewers ===
Since the only problem with this method is that the name does not describe the actual or intended functionality, we replaced all instances of “delete_all_reviewers” with “delete_outstanding_reviewers”.

=== delete_participant ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

=== release_reservation ===
Since the method name does not accurately describe the functionality within, all instances of “release_reservation” were replaced with “release_mapping”.

=== delete_review ===
This function was confirmed to not be used, since there is no other function in the application that calls it. Therefore, it was removed.

== Test Case Development ==

= Project Links =

* [http://152.46.19.84:3000/ Run Expertiza hosted on VCL]
* [https://github.com/rrpod/expertiza GitHub repository]
* [https://github.com/expertiza/expertiza/pull/591 GitHub pull request to merge to expertiza/master]

= References=
<references/>