https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&feedformat=atom&user=NpandeyExpertiza_Wiki - User contributions [en]2026-06-30T00:50:45ZUser contributionsMediaWiki 1.41.0https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=82457CSC/ECE 517 Fall 2013/oss ans2013-11-14T05:34:24Z<p>Npandey: /* Steps to test the application */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics.<br />
Responses are typically reviews, metareviews or feedback depending upon the stage of the current project. <br />
Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
if !@map.contributor.nil?<br />
if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
@topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else<br />
@topic_id = Participant.find(@map.contributor).topic_id<br />
end<br />
end<br />
if !@topic_id.nil?<br />
@signedUpTopic = SignUpTopic.find(@topic_id).topic_name<br />
end<br />
</pre><br />
<br />
Because , similar code existed in the response view<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<br />
</pre><br />
* We created a new method in order to find the latest response thereby by eliminating the need to reuse the following code multiple times.<br />
<pre><br />
def latestResponseVersion<br />
#get all previous versions of responses for the response map.<br />
array_not_empty=0<br />
@review_scores=Array.new<br />
@prev=Response.find_by_map_id(@map.id)<br />
for element in @prev<br />
array_not_empty=1<br />
@review_scores << element<br />
end<br />
</pre><br />
<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Integration tests for capybara were created for the scenarios describing admin login, creation of an assignment by admin and user login.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called. This method would be much more efficient than the current way the functionality is being handled also it would be more O-O like.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller, further improvements can be done to the code: <br />
<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
=== Steps to test the application ===<br />
<br />
* An admin needs to create a minimum of two users who will participate in the same assignment - In our case - '''newassign'''.<br />
* The login credentials for admin are:<br />
'''Username: admin<br />
Password: password'''<br />
* Then the admin needs to create one assignment ("assignnew" in our case) and add details such as due dates, review strategy etc... <br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, impersonate user ("sallie") through the admin account. Then sign up for one topic from the list of available topics.<br />
* Do the same for Bart.<br />
* Submit the assignment link from Bart's login.<br />
* Now impersonate "sallie" again and then go to other's work in the list and then select the topic that Bart submitted.<br />
* Click on begin to begin review.<br />
<br />
(Please take care that the stage deadline of the assignment is in "Review" phase)<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes to the routes.rb file.<br />
* Assignment submission status was not being changed in spite of changing the deadline due-dates in the edit assignment section for the admin.<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=82456CSC/ECE 517 Fall 2013/oss ans2013-11-14T05:30:55Z<p>Npandey: /* Setup Process */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics.<br />
Responses are typically reviews, metareviews or feedback depending upon the stage of the current project. <br />
Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
if !@map.contributor.nil?<br />
if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
@topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else<br />
@topic_id = Participant.find(@map.contributor).topic_id<br />
end<br />
end<br />
if !@topic_id.nil?<br />
@signedUpTopic = SignUpTopic.find(@topic_id).topic_name<br />
end<br />
</pre><br />
<br />
Because , similar code existed in the response view<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<br />
</pre><br />
* We created a new method in order to find the latest response thereby by eliminating the need to reuse the following code multiple times.<br />
<pre><br />
def latestResponseVersion<br />
#get all previous versions of responses for the response map.<br />
array_not_empty=0<br />
@review_scores=Array.new<br />
@prev=Response.find_by_map_id(@map.id)<br />
for element in @prev<br />
array_not_empty=1<br />
@review_scores << element<br />
end<br />
</pre><br />
<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Integration tests for capybara were created for the scenarios describing admin login, creation of an assignment by admin and user login.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called. This method would be much more efficient than the current way the functionality is being handled also it would be more O-O like.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller, further improvements can be done to the code: <br />
<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
=== Steps to test the application ===<br />
<br />
* An admin needs to create a minimum of two users who will participate in the same assignment - In our case - newassign.<br />
* The login credentials for admin are:<br />
Username: admin<br />
Password: password<br />
* Then the admin needs to create one assignment ("assignnew" in our case) and add details such as due dates, review strategy etc... <br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, impersonate user ("sallie") through the admin account. Then sign up for one topic from the list of available topics.<br />
* Do the same for Bart.<br />
* Submit the assignment link from Bart's login.<br />
* Now impersonate "sallie" again and then go to other's work in the list and then select the topic that Bart submitted.<br />
* Click on begin to begin review.<br />
<br />
(Please take care that the stage deadline of the assignment is in "Review" phase)<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes to the routes.rb file.<br />
* Assignment submission status was not being changed in spite of changing the deadline due-dates in the edit assignment section for the admin.<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81251CSC/ECE 517 Fall 2013/oss ans2013-10-30T20:07:09Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
if !@map.contributor.nil?<br />
if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
@topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else<br />
@topic_id = Participant.find(@map.contributor).topic_id<br />
end<br />
end<br />
if !@topic_id.nil?<br />
@signedUpTopic = SignUpTopic.find(@topic_id).topic_name<br />
end<br />
</pre><br />
<br />
Because , similar code existed in the response view<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<br />
</pre><br />
* We created a new method in order to find the latest response thereby by eliminating the need to reuse the following code multiple times.<br />
<pre><br />
def latestResponseVersion<br />
#get all previous versions of responses for the response map.<br />
array_not_empty=0<br />
@review_scores=Array.new<br />
@prev=Response.find_by_map_id(@map.id)<br />
for element in @prev<br />
array_not_empty=1<br />
@review_scores << element<br />
end<br />
</pre><br />
<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called. This method would be much more efficient than the current way the functionality is being handled also it would be more O-O like.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81229CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:54:49Z<p>Npandey: /* Future Work */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
if !@map.contributor.nil?<br />
if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
@topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else<br />
@topic_id = Participant.find(@map.contributor).topic_id<br />
end<br />
end<br />
if !@topic_id.nil?<br />
@signedUpTopic = SignUpTopic.find(@topic_id).topic_name<br />
end<br />
</pre><br />
<br />
Because , similar code existed in the response view<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called. This method would be much more efficient than the current way the functionality is being handled also it would be more O-O like.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81149CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:16:53Z<p>Npandey: /* Future Work */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
if !@map.contributor.nil?<br />
if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
@topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else<br />
@topic_id = Participant.find(@map.contributor).topic_id<br />
end<br />
end<br />
if !@topic_id.nil?<br />
@signedUpTopic = SignUpTopic.find(@topic_id).topic_name<br />
end<br />
</pre><br />
<br />
Because , similar code existed in the response view<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called. This method would be much more efficient than the current way the functionality is being handled also it would be more O-O like.<br />
<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81147CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:16:14Z<p>Npandey: /* Future Work */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
if !@map.contributor.nil?<br />
if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
@topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else<br />
@topic_id = Participant.find(@map.contributor).topic_id<br />
end<br />
end<br />
if !@topic_id.nil?<br />
@signedUpTopic = SignUpTopic.find(@topic_id).topic_name<br />
end<br />
</pre><br />
<br />
Because , similar code existed in the response view<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called. This method would be much more efficient than the current way the functionality is being handled also it would be more O-O like.<br />
* The project still contains a lot of legacy code for past assignments which should be removed in order to have a cleaner code.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81145CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:13:32Z<p>Npandey: /* Refactoring carried out */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
if !@map.contributor.nil?<br />
if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
@topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else<br />
@topic_id = Participant.find(@map.contributor).topic_id<br />
end<br />
end<br />
if !@topic_id.nil?<br />
@signedUpTopic = SignUpTopic.find(@topic_id).topic_name<br />
end<br />
</pre><br />
<br />
Because , similar code existed in the response view<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
* The project still contains a lot of legacy code for past assignments which should be removed in order to have a cleaner code.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81139CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:09:43Z<p>Npandey: /* Refactoring carried out */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
if !@map.contributor.nil?<br />
if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
@topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else<br />
@topic_id = Participant.find(@map.contributor).topic_id<br />
end<br />
end<br />
if !@topic_id.nil?<br />
@signedUpTopic = SignUpTopic.find(@topic_id).topic_name<br />
end<br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
* The project still contains a lot of legacy code for past assignments which should be removed in order to have a cleaner code.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81137CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:09:19Z<p>Npandey: /* Refactoring carried out */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
if !@map.contributor.nil?<br />
if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
@topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else<br />
@topic_id = Participant.find(@map.contributor).topic_id<br />
end<br />
end<br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
* The project still contains a lot of legacy code for past assignments which should be removed in order to have a cleaner code.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81134CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:08:55Z<p>Npandey: /* Refactoring carried out */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
* The project still contains a lot of legacy code for past assignments which should be removed in order to have a cleaner code.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81129CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:07:24Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<%= render :partial => 'submitted_content/main', :locals => {:participant => @map.contributor, :stage => @assignment.get_current_stage()} %><br />
<hr/><br />
<% end %><br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
* The project still contains a lot of legacy code for past assignments which should be removed in order to have a cleaner code.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81118CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:04:43Z<p>Npandey: /* Appendix */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<%= render :partial => 'submitted_content/main', :locals => {:participant => @map.contributor, :stage => @assignment.get_current_stage()} %><br />
<hr/><br />
<% end %><br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81117CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:04:19Z<p>Npandey: /* Refactoring carried out */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view. The following code snippet was removed from the response controller.<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<%= render :partial => 'submitted_content/main', :locals => {:participant => @map.contributor, :stage => @assignment.get_current_stage()} %><br />
<hr/><br />
<% end %><br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81112CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:01:29Z<p>Npandey: /* Future Work */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<%= render :partial => 'submitted_content/main', :locals => {:participant => @map.contributor, :stage => @assignment.get_current_stage()} %><br />
<hr/><br />
<% end %><br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
* The rubric model has been created but has not been used anywhere in the code.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81106CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:00:31Z<p>Npandey: /* Future Work */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<%= render :partial => 'submitted_content/main', :locals => {:participant => @map.contributor, :stage => @assignment.get_current_stage()} %><br />
<hr/><br />
<% end %><br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81105CSC/ECE 517 Fall 2013/oss ans2013-10-30T19:00:14Z<p>Npandey: /* Future Work */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<%= render :partial => 'submitted_content/main', :locals => {:participant => @map.contributor, :stage => @assignment.get_current_stage()} %><br />
<hr/><br />
<% end %><br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
=== Design Changes ===<br />
* * An even better way to handle the rubrics would be to do subclassing of the questionnaire model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
<br />
=== Further Refactoring ===<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81093CSC/ECE 517 Fall 2013/oss ans2013-10-30T18:57:22Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
<pre><br />
<% if !@map.contributor.nil?%><br />
<%if @map.assignment.team_assignment?<br />
team_member = TeamsUser.find_by_team_id(@map.contributor).user_id<br />
topic_id = Participant.find_by_parent_id_and_user_id(@map.assignment.id,team_member).topic_id<br />
else%><br />
<% topic_id = Participant.find(@map.contributor).topic_id%><br />
<%end%> <br />
<%if !topic_id.nil?%><br />
<h2>You are reviewing <%=SignUpTopic.find(topic_id).topic_name%></h2><br />
<%end%><br />
<%= render :partial => 'submitted_content/main', :locals => {:participant => @map.contributor, :stage => @assignment.get_current_stage()} %><br />
<hr/><br />
<% end %><br />
</pre><br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
* An even better way to handle the rubrics would be to do subclassing of the rubric model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81089CSC/ECE 517 Fall 2013/oss ans2013-10-30T18:55:44Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
* An even better way to handle the rubrics would be to do subclassing of the rubric model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
* After that, response view would be rendered to the reviewer.<br />
* The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
* If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81087CSC/ECE 517 Fall 2013/oss ans2013-10-30T18:55:08Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
* An even better way to handle the rubrics would be to do subclassing of the rubric model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* The admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc.<br />
* Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. <br />
* Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
* Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
After that, response view would be rendered to the reviewer. The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=81083CSC/ECE 517 Fall 2013/oss ans2013-10-30T18:54:07Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
* An even better way to handle the rubrics would be to do subclassing of the rubric model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application.<br />
* Next we created our own users and a new assignment to understand the working of the response controller.<br />
* First of all, an admin needs to create a minimum of two users who will participate in the same assignment. <br />
* Then the admin needs to create one assignment and add participants to the assignment. Further details of the assignment need to be added as necessary such as due dates, review strategy etc. Review strategy can be auto selected or student selected. If the TA or instructor is manually assigning the assignments for review, it has to be “instructor selected”. Check the "Due dates" tab and check if the review is allowed at the current date. Update due dates so that the review date starts after the submission date is passed. Save dependencies.<br />
Add a signup sheet to the assignment. This sheet will display topics which the users can select to review.<br />
* Now, login through user1 account and select an assignment. Then sign up for one topic from the list of available topics.<br />
* After that, user1 needs to submit a hyperlink.<br />
* Now, login through user2 credentials. User2 must select the assignment(of which it was made a participant by the admin).<br />
* User2 must go to the student_task page and select the link "other's work" which will be enabled only if a particular topic of an assignment has review_allowed to be true, that means the deadline should be properly configured by the admin. <br />
<br />
After that, response view would be rendered to the reviewer. The reviewer would review the assignment submitted by user1. Once the review has been saved, user1 will have an option to provide feedback on the review.<br />
If meta reviews have been enabled by the admin, then the other participants will be able to see the reviews of other users.<br />
<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80517CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:31:51Z<p>Npandey: /* Future Work */</p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
* An even better way to handle the rubrics would be to do subclassing of the rubric model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
* The purpose of saving method is not quite clear. It predominantly has the code for an assignment '562' which has been hard coded and can be removed.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80516CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:22:48Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
* An even better way to handle the rubrics would be to do subclassing of the rubric model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80515CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:22:37Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
* An even better way to handle the rubrics would be to do subclassing of the rubric model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80514CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:21:53Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Introduction ==<br />
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc)<br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
* An even better way to handle the rubrics would be to do subclassing of the rubric model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application<br />
<br />
=== Issues Encountered ===<br />
<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80513CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:21:31Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Introduction ==<br />
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc)<br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
* An even better way to handle the rubrics would be to do subclassing of the rubric model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
<br />
=== Issues Encountered ===<br />
<br />
<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80512CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:21:17Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Introduction ==<br />
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc)<br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
* An even better way to handle the rubrics would be to do subclassing of the rubric model in order to create two sub classes the rating rubric and the multipart rubric. As per the rubric being rendered the appropriate class would be called.<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
**<br />
<br />
=== Issues Encountered ===<br />
<br />
<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80511CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:18:34Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
== Introduction ==<br />
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc)<br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
*<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
**<br />
<br />
=== Issues Encountered ===<br />
<br />
<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80510CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:18:12Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
Expertiza is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc)<br />
<br />
<br />
== Project Description == <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
*<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
**<br />
<br />
=== Issues Encountered ===<br />
<br />
<br />
<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80509CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:16:54Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
*<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
**<br />
<br />
=== Issues Encountered ===<br />
<br />
<br />
<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80507CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:15:35Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
*<br />
<br />
== Appendix ==<br />
=== Setup Process ===<br />
* We cloned the repo from https://github.com/expertiza/expertiza into our local directory.<br />
* After installing MySQL server we loaded the test-db.sql sample database into the application<br />
* In order to get the application working properly we added several routes in the routes.rb file.<br />
<br />
=== Issues Encountered ===<br />
<br />
<br />
<br />
<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80506CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:14:06Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
*<br />
<br />
== Appendix ==<br />
<br />
== External Links ==<br />
<br />
:1. [http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza]<br />
<br />
:2. [http://152.7.99.43:3000/ VCL Link]<br />
<br />
:3. [https://github.com/nixtish/expertiza Git repository]<br />
<br />
:4. [https://docs.google.com/a/ncsu.edu/document/d/1Z0xjFZu-Zy-xm73YyUVUgFCtfWgRwhN1rZuThoyF-U0/edit Steps to setup Expertiza]</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80501CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:08:45Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller.<br />
* Remove duplicated code.<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
*<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80499CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:07:54Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller<br />
* Remove duplicated code<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
Given the current state of the response controller there is still a lot of work that can be done in order to further improve the code. Based on our findings the following things can be done :<br />
* The controller still has some code that is only there for some specific assignments. This is bad design and this code needs to be removed.<br />
*<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80496CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:05:59Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller<br />
* Remove duplicated code<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
Capybara tests were created for the response controller in order to carry out integration testing.<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80494CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:05:02Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller<br />
* Remove duplicated code<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Refactoring carried out ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
== Testing Done ==<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80493CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:04:09Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller<br />
* Remove duplicated code<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Design Choices ==<br />
As per the project requirements the following work was carried out :<br />
<br />
* The duplicated code has been refactored and put in a separate method which is called wherever required. This prevents redundancy.<br />
* The variables set up in controller become automatically available to the views. Hence the repeated code from controller and view for finding the topic id signed up by a user/team has been deleted from controller and incorporated only in the response view.<br />
* The custom create and custom update methods have been removed. Their functionality has been merged with create and update methods as was mentioned in the requirement specification. Depending on the type of rubric rendered, the create and update method does the necessary updations.<br />
<br />
<br />
=== Refactoring carried out ===<br />
<br />
=== Testing Done ===<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80492CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:02:21Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller<br />
* Remove duplicated code<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Design Choices ==<br />
<br />
<br />
=== Refactoring carried out ===<br />
<br />
=== Testing Done ===<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80491CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:00:59Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller<br />
* Remove duplicated code<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods.<br />
<br />
== Design Choices ==<br />
<br />
=== Refactoring carried out ===<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80490CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:00:24Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller<br />
* Remove duplicated code<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80489CSC/ECE 517 Fall 2013/oss ans2013-10-30T03:00:07Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller<br />
* Remove duplicated code<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. These methods were only there to handle the multi part rubrics. We already had create and update methods that were handling the normal rubrics. Our job was to use polymorphism in order to eliminate the custom methods<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80488CSC/ECE 517 Fall 2013/oss ans2013-10-30T02:58:34Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics. Our project requirement entailed the following things to be done.<br />
<br />
* Reduce the method complexity in the response controller<br />
* Remove duplicated code<br />
* There were “custom_create” and “custom_update” methods for “custom” (multipart) rubrics. This is a very bad way of achieving this functionality, because frequent tests are required as to what kind of a rubric is in use. <br />
== Design Choices ==<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80485CSC/ECE 517 Fall 2013/oss ans2013-10-30T02:56:49Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics.<br />
<br />
== Design Choices ==<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80484CSC/ECE 517 Fall 2013/oss ans2013-10-30T02:56:09Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics.<br />
<br />
<br />
== Introduction ==<br />
<br />
== Design Choices ==<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80483CSC/ECE 517 Fall 2013/oss ans2013-10-30T02:55:48Z<p>Npandey: </p>
<hr />
<div>''' E807 : Refactoring and testing response_controller.rb''' <br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics.<br />
<br />
<br />
== Introduction ==<br />
<br />
== Design Choices ==<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssv&diff=80482CSC/ECE 517 Fall 2013/oss ssv2013-10-30T02:55:43Z<p>Npandey: </p>
<hr />
<div>= E813. Refactoring and testing — degree_of_relevance.rb =<br />
<br />
== Introduction ==<br />
<br />
== Existing Design ==<br />
<br />
== Implementation ==<br />
=== New Design and Refactoring ===<br />
=== How to run the code ===<br />
<br />
== Testing == <br />
== Conclusion ==<br />
== References ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssv&diff=80481CSC/ECE 517 Fall 2013/oss ssv2013-10-30T02:55:10Z<p>Npandey: </p>
<hr />
<div>''' E813. Refactoring and testing — degree_of_relevance.rb''' <br />
<br />
== Introduction ==<br />
<br />
== Existing Design ==<br />
<br />
== Implementation ==<br />
=== New Design and Refactoring ===<br />
=== How to run the code ===<br />
<br />
== Testing == <br />
== Conclusion ==<br />
== References ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80480CSC/ECE 517 Fall 2013/oss ans2013-10-30T02:54:54Z<p>Npandey: </p>
<hr />
<div>= E807 : Refactoring and testing response_controller.rb =<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics.<br />
<br />
<br />
== Introduction ==<br />
<br />
== Design Choices ==<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80478CSC/ECE 517 Fall 2013/oss ans2013-10-30T02:54:38Z<p>Npandey: </p>
<hr />
<div>= E807 : Refactoring and testing response_controller.rb =<br />
<br />
<br />
== Introduction ==<br />
The response controller creates, edits, and displays responses, that is, rubrics to be filled out, or filled-out rubrics.<br />
<br />
== Design Choices ==<br />
<br />
==Future Work ==<br />
<br />
== Appendix ==</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ans&diff=80463CSC/ECE 517 Fall 2013/oss ans2013-10-29T23:12:09Z<p>Npandey: Created page with "OSS E807"</p>
<hr />
<div>OSS E807</div>Npandeyhttps://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013&diff=80461CSC/ECE 517 Fall 20132013-10-29T23:11:52Z<p>Npandey: </p>
<hr />
<div>* [[ CSC/ECE 517 Fall 2012/ch1 1w23 ph ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w30 nn]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w21 w]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w01 aj]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w24 nv]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w29 rkld]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w25 aras]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w30 ps]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w19 rj]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w18 bs]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w17 pk]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w22 ss]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w12 vn]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w14 st]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w08 cc]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w10 ga ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w26 as ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w27 ma ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w13 aa ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w11 sv ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w07 d ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w20 gq ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w03 ss ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w28 nm ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w02 pp ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w6 zs ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w04 y ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w05 st ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w09 hs ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w32 av ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w48 x ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w43 av]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w46 ka]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w33 aa]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w35 sa ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w39 as ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w31 vm ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w43 sm ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w44 s ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w47 ka ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w34 fs ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch1 1w40 ao ]]<br />
* [[ CSC/ECE 517 Fall 2013/oss fmv ]]<br />
* [[ CSC/ECE 517 Fall 2013/oss vna ]]<br />
* [[ CSC/ECE 517 Fall 2013/oss paa ]]<br />
* [[ CSC/ECE 517 Fall 2013/oss mapFeeds ]]<br />
* [[ CSC/ECE 517 Fall 2013/oss ssp ]]<br />
* [[ CSC/ECE 517 Fall 2013/ch2 0e808 nsv ]]<br />
* [[ CSC/ECE 517 Fall 2013/oss aoa ]]<br />
* [[ CSC/ECE 517 Fall 2013/oss cmh ]]<br />
* [[ CSC/ECE 517 Fall 2013/oss ans ]]</div>Npandey