Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-11T21:20:22Z

Bkasliw: /* Design */

=Introduction=
==Purpose==
'''Scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

'''Assignment Creation:'''

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

'''Group Formation:'''

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

[[File:UML-1.png]]

'''Non Anonymous Reviews'''

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

*This is the view of the review strategy tab where the checkbox for anonymity has to be added

[[File:viewToBeChanged1.png]]

*This is the view where names would be visible to ensure non anonymity of reviews

[[File:New1234.png]]

===Experimental Use===

This project is part of an experiment to test whether anonymity makes a difference in reviews of students, thus to implement it one assignment would be made as anonymous and another as anonymous and the quality and the review scores would be tested to say if there is a change in quality and values of control and test

= UI Testing =
The project can be tested by doing the following:

Log in as Instructor using instructor6
use password as password
click on manage assignments
Go to any assignment and edit
click on the review strategy tab
uncheck anonymity to disable anonymous reviews

On the student side
log in as student
click on assignments
select your scores
select view reviews

when you check your scores for each review when you log in as a student
you should see the name of the reviewer
appended to review 1

=Files to be Considered=
*controller/reveiw_mapping_controller.rb

*controller/teams_controller.rb

*model/team.rb

*views/assignments/edit/_review_strategy.html.erb

*views/grades/_reviews.html.erb

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

File:UML-1.png

2016-11-11T21:17:57Z

Bkasliw:

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T23:16:20Z

Bkasliw:

=Introduction=
==Purpose==
'''Scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

'''Assignment Creation:'''

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

'''Group Formation:'''

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

'''Non Anonymous Reviews'''

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

=Files to be Considered=
*reveiw_mapping_controller.rb

*teams_controller.rb

*team.rb

*views/assignments/edit/_review_strategy.html.erb

*views/grades/_reviews.html.erb

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T22:23:20Z

Bkasliw: /* E1698: Instructor/student control of anonymity + group-based reviewing */

=Introduction=
==Purpose==
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

'''Assignment Creation:'''

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

'''Group Formation:'''

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

'''Non Anonymous Reviews'''

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

=Files to be Considered=
*reveiw_mapping_controller.rb

*teams_controller.rb

*team.rb

*views/assignments/edit/_review_strategy.html.erb

*views/grades/_reviews.html.erb

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T22:22:45Z

Bkasliw: /* Files to be Considered */

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T22:22:24Z

Bkasliw: /* Key People */

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T22:14:30Z

Bkasliw: /* Design */

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T22:13:48Z

Bkasliw: /* Design */

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T22:13:24Z

Bkasliw: /* Purpose */

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T22:12:20Z

Bkasliw: /* Design */

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T22:12:01Z

Bkasliw: /* Problem Statement */

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T22:11:39Z

Bkasliw: /* Introduction to Expertiza */

= '''E1698: Instructor/student control of anonymity + group-based reviewing''' =

=Introduction=
==Purpose==
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

'''Assignment Creation:'''

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

'''Group Formation:'''

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

'''Non Anonymous Reviews'''

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

=Problem Statement=
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

=Design=

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T22:11:22Z

Bkasliw: /* Design */

= '''E1698: Instructor/student control of anonymity + group-based reviewing''' =

=Introduction=
==Purpose==
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

'''Assignment Creation:'''

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

'''Group Formation:'''

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

'''Non Anonymous Reviews'''

In the case of non-anonymous reviews, students will be able to see the names of all the group members who have graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Problem Statement=
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

=Design=

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T22:09:07Z

Bkasliw: /* Design */

= '''E1698: Instructor/student control of anonymity + group-based reviewing''' =

=Introduction=
==Purpose==
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

Assignment Creation:

Providing a checkbox in "review strategy tab" to mark an assignment to have anonymous or non-anonymous reviews. By default, every assignment will be having anonymous reviews but an instructor can change it by unchecking the checkbox.

Group Formation:

The instructor has the authority to create and assign groups randomly. In this case, students can not drop the group they have been assigned and only an instructor can change their group if needed.
In case, a group has not been assigned by an instructor, students will have the functionality to invite other students to join their group. This functionality is analogous to the invite members to join their team.
Students in the same group can review work of their group members only.

For this, we will be creating a separate model for groups and will store all the group information into the corresponding database table. In order to follow the DRY principle, we will try to integrate the group code with the code written for teams.

In the case of non-anonymous reviews, students will be able to see the names of all the group members who has graded their individual work. In addition, students can also see whose work they are going to grade so that the non-anonymity is maintained from both sides.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Problem Statement=
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

=Design=

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-09T21:57:11Z

Bkasliw:

= '''E1698: Instructor/student control of anonymity + group-based reviewing''' =

=Introduction=
==Purpose==
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

==Scope==
The project provides instructor a functionality to make assignment reviews to be anonymous or non-anonymous. In addition, instructors have authority to create and assign review groups (students assigned same review group will review each others work) randomly.This scenario will be valid for individual assignments only. Also, anonymity is taken care from the perspective of reviewer as well as the reviewee. In case of non-anonymous groups, students may have the option to invite other students to join their group provided group size is not exceeding the maximum limit.

==Background==
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Design=

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Problem Statement=
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

=Design=

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-07T22:58:58Z

Bkasliw:

= '''E1698: Instructor/student control of anonymity + group-based reviewing''' =

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Problem Statement=
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

I don’t know if it would be needed for next semester, but we’d also like to allow the instructor to assign each of the assignment participants to a particular group. Decide what would be a good way to specify that.

Another feature that would be useful is to allow students to toggle their anonymity by setting a field in their profile. So if someone wanted to be anonymous in an assignment that was not otherwise anonymous, they could set that field.

=Design=

=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-07T22:08:38Z

Bkasliw:

= '''E1698: Instructor/student control of anonymity + group-based reviewing''' =

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Problem Statement=
'''The scenario:''' An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,

Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)

'''What needs to be done''': The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.

The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.

The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.

I don’t know if it would be needed for next semester, but we’d also like to allow the instructor to assign each of the assignment participants to a particular group. Decide what would be a good way to specify that.

Another feature that would be useful is to allow students to toggle their anonymity by setting a field in their profile. So if someone wanted to be anonymous in an assignment that was not otherwise anonymous, they could set that field.

=Design=

=Introduction to Expertiza=
==Introduction to Expertiza==
===Introduction to Expertiza===
=Introduction to Expertiza=
=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-07T22:07:06Z

Bkasliw:

= '''E1698: Instructor/student control of anonymity + group-based reviewing''' =

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is a peer review system which provides incremental learning from the class. This project has been developed together by faculty and students using [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create, edit and delete assignments, create new assignment topics, assign them to a particular class or selected students, have students work on teams and then review each other's assignments at the end. For the students, they can signup for topics, form teams, and submit their projects and assignments.
Students then review the work done by other students and give suggestions to improve. Teams after reviews are allotted scores and they can refer to the peer comments to further improve their work. It also supports submission of different file types as well as URLs for assignments.

=Problem Statement=
The scenario: An instructor using Expertiza wants to do an experiment comparing anonymous review with identified (non-anonymous) review. And in general, there is quite a bit of research interest in the implications of anonymity in student interactions. In this experiment,
Approx ½ the class will conduct two rounds of formative reviews in small groups (4-5 students/group). The groups will stay the same for both rounds. The students in the groups should be able to see who they are reviewing and who is reviewing them.
For the non-anonymous groups, I'd like the students to be able to request group members, so I would want to be able to have some control, perhaps with an option to use random assignment to groups if they had no preference for group members.
Approx ½ the class will conduct two rounds of formative reviews anonymously (using the normal method we used this fall)
What needs to be done: The Review Strategy tab of assignment creation needs have a new checkbox for anonymous reviews, which would be checked by default. If it is checked, student views would be the same as at present. If it is not checked, students would see their reviewers and grades in the same way as the instructor now sees them; thus, instead of seeing “Reviewer 1”, “Reviewer 2”, the student might see, “Anthony Adams”, “Bessie Brown”, etc.
The code for displaying names obviously already exists, because it is used in the instructor views. Implement the changes in an elegant way; for example, instead of checking multiple times in the view to determine whether the reviewer’s (or author’s) real name is to be displayed, try to send a message to a model class that will “do the right thing.” This may involve creating separate model classes for anonymous and identified review, so that messages could be sent polymorphically. It’s hard for me to know, without studying the code, whether this would simplify the code or clutter it, but please give some thought to what is the clearest and most robust way to code both anonymous & identified reviews, from the student’s and the instructor’s perspective.
The other piece of the project is to enable review within groups, which means that every student in a group will review every other student in the group (but no students outside the group). This can be configured on the Review Strategy tab when the review strategy is set to “Instructor-Selected”. Under the “Set number of reviews done by each student” box, there could be another one, “Review done in groups of [ ] students”, where “[ ]” is a small text box. There should also be an information button describing how group-based review works.
I don’t know if it would be needed for next semester, but we’d also like to allow the instructor to assign each of the assignment participants to a particular group. Decide what would be a good way to specify that.
Another feature that would be useful is to allow students to toggle their anonymity by setting a field in their profile. So if someone wanted to be anonymous in an assignment that was not otherwise anonymous, they could set that field.
=Introduction to Expertiza=

=Introduction to Expertiza=
==Introduction to Expertiza==
===Introduction to Expertiza===
=Introduction to Expertiza=
=Key People=
===Developers===
*Bhavesh Kasliwal
*Bhavya Bansal
*Chinmoy Baruah
*Rishabh Sinha

===Mentor===
*Ed Gehringer

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-07T22:03:46Z

Bkasliw:

CSC/ECE 517 Fall 2016/E1698. Instructor/student control of anonymity + group-based reviewing

2016-11-07T22:02:40Z

Bkasliw: Created page with "= '''E1698: Instructor/student control of anonymity + group-based reviewing''' = =Introduction to Expertiza= [http://expertiza.ncsu.edu/ Expertiza] is a peer review system whic..."

File:FGrade.png

2016-10-29T03:53:47Z

Bkasliw: uploaded a new version of "File:FGrade.png"

File:AGrade.png

2016-10-29T03:53:32Z

Bkasliw: uploaded a new version of "File:AGrade.png"

CSC/ECE 517 Fall 2016/E1645. Refactoring Tree Display Controller

2016-10-29T03:53:16Z

Bkasliw:

= '''E1645: Refactoring TreeDisplayController''' =

__TOC__

=Project Links=
[https://github.com/shubham2892/expertiza Github Repo] 
[https://github.com/expertiza/expertiza/pull/744 Expertize Pull Request] 
[https://travis-ci.org/expertiza/expertiza/builds/171173212 Travis CI Test Cases Passed] 

=Setup - How To View Our Expertiza Fork Running on AWS=
NOTE: The scope of our project was only to refactor select code. There are no feature additions or changes, so it should work just like production Expertiza.

1) Go to [http://ec2-54-186-80-176.us-west-2.compute.amazonaws.com:3000/ our Expertiza project running on AWS]

2) Login as Admin 
'''User:''' user2 
'''Password:''' password

3) Click on "Manage..." if you are not automatically directed to the tree display.

=Project Description=

For this project, our team refactored the TreeDisplayController class in the [http://expertiza.ncsu.edu/ Expertiza] OSS project. This class provides access to questionnaires, review rubrics, author feedback, courses, assignments, and course evaluations. The tree display lists all of these categories with the ability for the user to "drill down" into the subcategories or just expand/collapse as needed. The main objective of the project was to refactor the controller to follow good Ruby practices and improve the grade given Code Climate.

=Refactoring TreeDisplayController Issues=

As part of the refactoring task, we had to resolve the issues detected by Code Climate for enhancing code readability and maintainability. Some of the issues detected were:

#Similar code found in other locations.
#Cyclomatic and Perceived complexity for get_children_node_ng is too high.
#Useless assignment to variable - `childNodes`.
#Use snake_case for variable names.
#Prefer `each` over `for`.
#The use of `eval` is a serious security risk.
#Avoid the use of the case equality operator `===`.
#Line is too long.
#`end` at 334, 2 is not aligned with `class` at 1, 0.

==1) Similar code found in other locations==

In order to make the code DRY, similar code was moved to a new function, and that was called from the remaining part of the code.

<pre>
def goto_questionnaires
node_object = TreeFolder.find_by_name('Questionnaires')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to review rubrics
def goto_review_rubrics
node_object = TreeFolder.find_by_name('Review')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to metareview rubrics
def goto_metareview_rubrics
node_object = TreeFolder.find_by_name('Metareview')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to teammate review rubrics
def goto_teammatereview_rubrics
node_object = TreeFolder.find_by_name('Teammate Review')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to author feedbacks
def goto_author_feedbacks
node_object = TreeFolder.find_by_name('Author Feedback')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end
</pre>

Changed to ⇒

<pre>
def goto_controller(name_parameter)
node_object = TreeFolder.find_by(name: name_parameter)
session[:root] = FolderNode.find_by(node_object_id: node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to questionnaires
def goto_questionnaires
goto_controller('Questionnaires')
end

# direct access to review rubrics
def goto_review_rubrics
goto_controller('Review')
end

# direct access to metareview rubrics
def goto_metareview_rubrics
goto_controller('Metareview')
end

# direct access to teammate review rubrics
def goto_teammatereview_rubrics
goto_controller('Teammate Review')
end
</pre>

==2) Cyclomatic and Perceived complexity for get_children_node_ng is too high==
By creating two separate functions child_nodes_from_params and initialize_fnode_update_children, the complexity for this function was reduced. The initialize_fnode_update_children function was in-turn sub-functioned into update_fnode_children which updated the children nodes.
The new function looks like this:

<pre>
def children_node_ng
child_nodes = child_nodes_from_params(params[:reactParams][:child_nodes])
tmp_res = {}
child_nodes.each do |node|
initialize_fnode_update_children(params, node, tmp_res)
end
# res = res_node_for_child(tmp_res)
res = res_node_for_child(tmp_res)
respond_to do |format|
format.html { render json: res }
end
end
</pre>

==3) Useless assignment to variable - `childNodes`.==
Following were removed from the two places:
<pre>
135 - childNodes = {}
</pre>

<pre>
222 - childNodes = {}
</pre>

==4) Use snake_case for variable names.==
Variable names using camelCase were renamed to use snake_case as according to ruby coding guidelines.

Before:
<pre>
- childNodes = {}
- tmpRes = {}
- nodeType = child.type
</pre>

After:
<pre>
+ child_nodes = child_nodes_from_params(params[:reactParams][:child_nodes])
+ tmp_res = {}
+ node_type = child.type
</pre>

==5) Prefer `each` over `for`==
The following for loops were replaced by each, as follows:
Before:
<pre>
- 143 for node in childNodes
- 146 for a in node
- 159 for nodeType in tmpRes.keys
- 162 for node in tmpRes[nodeType]
- 238 for child in tmpRes
</pre>

After:
<pre>
+ child_nodes.each do |node|
+ node.each do |a|
+ tmp_res.keys.each do |node_type|
+ tmp_res[node_type].each do |node|
+ tmp_res.each do |child|
</pre>

==6)The use of `eval` is a serious security risk.==
eval() executes a string of characters as code. eval() is used in situations where the string contents are not known beforehand or even when the string is generated dynamically. Basically, when eval() is called , it starts a compiler to translate the string. This is detrimental especially when eval() is called on a string submitted by or modifiable by the user. Imagine if the string contains an OS call like rm -rf. But , it is perfectly safe to use eval() on strings , if they are known to be constrained. This problem is analogous to SQL injection.

Before:
<pre>
- for node in childNodes
- fnode = eval(params[:reactParams][:nodeType]).new
</pre>

After:
<pre>
+ def initialize_fnode_update_children(params, node, tmp_res)
+ fnode = (params[:reactParams][:nodeType]).constantize.new
</pre>

==7) Avoid the use of the case equality operator `===`.==
`===` has been replaced by `==` in the following manner:
<pre>
- tmpObject["private"] = node.get_instructor_id === session[:user].id ? true : false
</pre>
has been changed to ⇒
<pre>
+ "private" => node.get_instructor_id == session[:user].id ? true : false
</pre>
==8) Line is too long.==
Very long lines needs to be made short so that it is more readable, which was done in the following manner:
<pre>
tmpObject["is_available"] = is_available(session[:user], instructor_id) || (session[:user].role.ta? && Ta.get_my_instructors(session[:user].id).include?(instructor_id) && ta_for_current_course?(node))
</pre>
Changed to ⇒
<pre>
tmpObject["is_available"] = is_available(session[:user], instructor_id) || (session[:user].role.ta? && Ta.get_my_instructors(session[:user].id).include?(instructor_id) && ta_for_current_course?(node))
</pre>

<pre>
- available_condition_2 = session[:user].role_id == 6 and Ta.get_my_instructors(session[:user].id).include?(instructor_id) and ta_for_current_course?(child)
</pre>
Changed to ==>

<pre>
+ def is_current_user_ta?(instructor_id, child)
+ # instructor created the course, current user is the ta of this course.
+ session[:user].role_id == 6 and
+ Ta.get_my_instructors(session[:user].id).include?(instructor_id) and ta_for_current_course?(child)
end
</pre>

=Conclusion=
In conclusion, we were able to successfully refactor the tree_display_controller and related Rspec tests. We have improved and expanded the use of RESTful and DRY design choices, and overall improved the quality and efficiency of the Expertiza codebase. We have fixed all the issues detected by Code Climate Chrome Extension and refactored the code to make sure it followed good ruby practices and in the end were able to improve the Code Climate score from F to A while not breaking any of the Rspec tests related.

From:
[[File:FGrade.png]]

To:
[[File:AGrade.png]]

File:AGrade.png

2016-10-29T03:50:32Z

Bkasliw:

File:FGrade.png

2016-10-29T03:50:18Z

Bkasliw:

CSC/ECE 517 Fall 2016/E1645. Refactoring Tree Display Controller

2016-10-29T02:44:38Z

Bkasliw: Copying from old page

= '''E1645: Refactoring TreeDisplayController''' =

__TOC__

=Project Links=
[https://github.com/expertiza/expertiza Github Repo] 
[https://github.com/expertiza/expertiza/pull/744 Expertize Pull Request] 
[https://travis-ci.org/expertiza/expertiza/builds/171173212 Travis CI Test Cases Passes] 

=Setup - How To View Our Expertiza Fork Running on AWS=
NOTE: The scope of our project was only to refactor select code. There are no feature additions or changes, so it should work just like production Expertiza.

1) Go to [http://ec2-54-186-80-176.us-west-2.compute.amazonaws.com:3000/ our Expertiza project running on AWS]

2) Login as Admin 
'''User:''' user2 
'''Password:''' password

3) Click on "Manage..." if you are not automatically directed to the tree display.

=Project Description=

For this project, our team refactored the TreeDisplayController class in the [http://expertiza.ncsu.edu/ Expertiza] OSS project. This class provides access to questionnaires, review rubrics, author feedback, courses, assignments, and course evaluations. The tree display lists all of these categories with the ability for the user to "drill down" into the subcategories or just expand/collapse as needed.

=Refactoring TreeDisplayController Issues=

As part of the refactoring task, we had to resolve the following issues for enhancing code readability and maintainability. The tasks included:

#Similar code found in other locations.
#Cyclomatic and Perceived complexity for get_children_node_ng is too high.
#Useless assignment to variable - `childNodes`.
#Use snake_case for variable names.
#Prefer `each` over `for`.
#The use of `eval` is a serious security risk.
#Avoid the use of the case equality operator `===`.
#Line is too long.
#`end` at 334, 2 is not aligned with `class` at 1, 0.

==1) Similar code found in other locations==

In order to make the code DRY, similar code was moved to a new function, and that was called from the remaining part of the code.

<pre>
def goto_questionnaires
node_object = TreeFolder.find_by_name('Questionnaires')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to review rubrics
def goto_review_rubrics
node_object = TreeFolder.find_by_name('Review')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to metareview rubrics
def goto_metareview_rubrics
node_object = TreeFolder.find_by_name('Metareview')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to teammate review rubrics
def goto_teammatereview_rubrics
node_object = TreeFolder.find_by_name('Teammate Review')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to author feedbacks
def goto_author_feedbacks
node_object = TreeFolder.find_by_name('Author Feedback')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end
</pre>

Changed to ⇒

<pre>
def goto_controller(name_parameter)
node_object = TreeFolder.find_by(name: name_parameter)
session[:root] = FolderNode.find_by(node_object_id: node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to questionnaires
def goto_questionnaires
goto_controller('Questionnaires')
end

# direct access to review rubrics
def goto_review_rubrics
goto_controller('Review')
end

# direct access to metareview rubrics
def goto_metareview_rubrics
goto_controller('Metareview')
end

# direct access to teammate review rubrics
def goto_teammatereview_rubrics
goto_controller('Teammate Review')
end
</pre>

==2) Cyclomatic and Perceived complexity for get_children_node_ng is too high==
By creating two separate functions child_nodes_from_params and initialize_fnode_update_children, the complexity for this function was reduced. The initialize_fnode_update_children function was in-turn sub-functioned into update_fnode_children which updated the children nodes.
The new function looks like this:

<pre>
def children_node_ng
child_nodes = child_nodes_from_params(params[:reactParams][:child_nodes])
tmp_res = {}
child_nodes.each do |node|
initialize_fnode_update_children(params, node, tmp_res)
end
# res = res_node_for_child(tmp_res)
res = res_node_for_child(tmp_res)
respond_to do |format|
format.html { render json: res }
end
end
</pre>

==3) Useless assignment to variable - `childNodes`.==
Following were removed from the two places:
<pre>
135 - childNodes = {}
</pre>

<pre>
222 - childNodes = {}
</pre>

==4) Use snake_case for variable names.==
Variable names using camelCase were renamed to use snake_case as according to ruby coding guidelines.

Before:
<pre>
- childNodes = {}
- tmpRes = {}
- nodeType = child.type
</pre>

After:
<pre>
+ child_nodes = child_nodes_from_params(params[:reactParams][:child_nodes])
+ tmp_res = {}
+ node_type = child.type
</pre>

==5) Prefer `each` over `for`==
The following for loops were replaced by each, as follows:
Before:
<pre>
- 143 for node in childNodes
- 146 for a in node
- 159 for nodeType in tmpRes.keys
- 162 for node in tmpRes[nodeType]
- 238 for child in tmpRes
</pre>

After:
<pre>
+ child_nodes.each do |node|
+ node.each do |a|
+ tmp_res.keys.each do |node_type|
+ tmp_res[node_type].each do |node|
+ tmp_res.each do |child|
</pre>

==6)The use of `eval` is a serious security risk.==
eval() executes a string of characters as code. eval() is used in situations where the string contents are not known beforehand or even when the string is generated dynamically. Basically, when eval() is called , it starts a compiler to translate the string. This is detrimental especially when eval() is called on a string submitted by or modifiable by the user. Imagine if the string contains an OS call like rm -rf. But , it is perfectly safe to use eval() on strings , if they are known to be constrained. This problem is analogous to SQL injection.

Before:
<pre>
- for node in childNodes
- fnode = eval(params[:reactParams][:nodeType]).new
</pre>

After:
<pre>
+ def initialize_fnode_update_children(params, node, tmp_res)
+ fnode = (params[:reactParams][:nodeType]).constantize.new
</pre>

==7) Avoid the use of the case equality operator `===`.==
`===` has been replaced by `==` in the following manner:
<pre>
- tmpObject["private"] = node.get_instructor_id === session[:user].id ? true : false
</pre>
has been changed to ⇒
<pre>
+ "private" => node.get_instructor_id == session[:user].id ? true : false
</pre>
==8) Line is too long.==
Very long lines needs to be made short so that it is more readable, which was done in the following manner:
<pre>
tmpObject["is_available"] = is_available(session[:user], instructor_id) || (session[:user].role.ta? && Ta.get_my_instructors(session[:user].id).include?(instructor_id) && ta_for_current_course?(node))
</pre>
Changed to ⇒
<pre>
tmpObject["is_available"] = is_available(session[:user], instructor_id) || (session[:user].role.ta? && Ta.get_my_instructors(session[:user].id).include?(instructor_id) && ta_for_current_course?(node))
</pre>

<pre>
- available_condition_2 = session[:user].role_id == 6 and Ta.get_my_instructors(session[:user].id).include?(instructor_id) and ta_for_current_course?(child)
</pre>
Changed to ==>

<pre>
+ def is_current_user_ta?(instructor_id, child)
+ # instructor created the course, current user is the ta of this course.
+ session[:user].role_id == 6 and
+ Ta.get_my_instructors(session[:user].id).include?(instructor_id) and ta_for_current_course?(child)
end
</pre>

=Conclusion=
In conclusion, we were able to successfully refactor the tree_display_controller and related Rspec tests. We have improved and expanded the use of RESTful and DRY design choices, and overall improved the quality and efficiency of the Expertiza codebase. We have fixed all the issues detected by Code Climate Chrome Extension and refactored the code to make sure it followed good ruby practices and in the end were able to improve the Code Climate score from F to A while not breaking any of the Rspec tests related.

E1645

2016-10-28T22:39:29Z

Bkasliw: Final code updates

= '''E1645: Refactoring TreeDisplayController''' =

__TOC__

=Project Links=
[https://github.com/expertiza/expertiza Github Repo] 
[https://github.com/expertiza/expertiza/pull/744 Expertize Pull Request] 
[https://travis-ci.org/expertiza/expertiza/builds/171173212 Travis CI Test Cases Passes] 

=Setup - How To View Our Expertiza Fork Running on AWS=
NOTE: The scope of our project was only to refactor select code. There are no feature additions or changes, so it should work just like production Expertiza.

1) Go to [http://ec2-54-186-80-176.us-west-2.compute.amazonaws.com:3000/ our Expertiza project running on AWS]

2) Login as Admin 
'''User:''' user2 
'''Password:''' password

3) Click on "Manage..." if you are not automatically directed to the tree display.

=Project Description=

For this project, our team refactored the TreeDisplayController class in the [http://expertiza.ncsu.edu/ Expertiza] OSS project. This class provides access to questionnaires, review rubrics, author feedback, courses, assignments, and course evaluations. The tree display lists all of these categories with the ability for the user to "drill down" into the subcategories or just expand/collapse as needed.

=Refactoring TreeDisplayController Issues=

As part of the refactoring task, we had to resolve the following issues for enhancing code readability and maintainability. The tasks included:

#Similar code found in other locations.
#Cyclomatic and Perceived complexity for get_children_node_ng is too high.
#Useless assignment to variable - `childNodes`.
#Use snake_case for variable names.
#Prefer `each` over `for`.
#The use of `eval` is a serious security risk.
#Avoid the use of the case equality operator `===`.
#Line is too long.
#`end` at 334, 2 is not aligned with `class` at 1, 0.

==1) Similar code found in other locations==

In order to make the code DRY, similar code was moved to a new function, and that was called from the remaining part of the code.

<pre>
def goto_questionnaires
node_object = TreeFolder.find_by_name('Questionnaires')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to review rubrics
def goto_review_rubrics
node_object = TreeFolder.find_by_name('Review')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to metareview rubrics
def goto_metareview_rubrics
node_object = TreeFolder.find_by_name('Metareview')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to teammate review rubrics
def goto_teammatereview_rubrics
node_object = TreeFolder.find_by_name('Teammate Review')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to author feedbacks
def goto_author_feedbacks
node_object = TreeFolder.find_by_name('Author Feedback')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end
</pre>

Changed to ⇒

<pre>
def goto_controller(name_parameter)
node_object = TreeFolder.find_by(name: name_parameter)
session[:root] = FolderNode.find_by(node_object_id: node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to questionnaires
def goto_questionnaires
goto_controller('Questionnaires')
end

# direct access to review rubrics
def goto_review_rubrics
goto_controller('Review')
end

# direct access to metareview rubrics
def goto_metareview_rubrics
goto_controller('Metareview')
end

# direct access to teammate review rubrics
def goto_teammatereview_rubrics
goto_controller('Teammate Review')
end
</pre>

==2) Cyclomatic and Perceived complexity for get_children_node_ng is too high==
By creating two separate functions child_nodes_from_params and initialize_fnode_update_children, the complexity for this function was reduced. The initialize_fnode_update_children function was in-turn sub-functioned into update_fnode_children which updated the children nodes.
The new function looks like this:

<pre>
def children_node_ng
child_nodes = child_nodes_from_params(params[:reactParams][:child_nodes])
tmp_res = {}
child_nodes.each do |node|
initialize_fnode_update_children(params, node, tmp_res)
end
# res = res_node_for_child(tmp_res)
res = res_node_for_child(tmp_res)
respond_to do |format|
format.html { render json: res }
end
end
</pre>

==3) Useless assignment to variable - `childNodes`.==
Following were removed from the two places:
<pre>
135 - childNodes = {}
</pre>

<pre>
222 - childNodes = {}
</pre>

==4) Use snake_case for variable names.==
Variable names using camelCase were renamed to use snake_case as according to ruby coding guidelines.

Before:
<pre>
- childNodes = {}
- tmpRes = {}
- nodeType = child.type
</pre>

After:
<pre>
+ child_nodes = child_nodes_from_params(params[:reactParams][:child_nodes])
+ tmp_res = {}
+ node_type = child.type
</pre>

==5) Prefer `each` over `for`==
The following for loops were replaced by each, as follows:
Before:
<pre>
- 143 for node in childNodes
- 146 for a in node
- 159 for nodeType in tmpRes.keys
- 162 for node in tmpRes[nodeType]
- 238 for child in tmpRes
</pre>

After:
<pre>
+ child_nodes.each do |node|
+ node.each do |a|
+ tmp_res.keys.each do |node_type|
+ tmp_res[node_type].each do |node|
+ tmp_res.each do |child|
</pre>

==6)The use of `eval` is a serious security risk.==
eval() executes a string of characters as code. eval() is used in situations where the string contents are not known beforehand or even when the string is generated dynamically. Basically, when eval() is called , it starts a compiler to translate the string. This is detrimental especially when eval() is called on a string submitted by or modifiable by the user. Imagine if the string contains an OS call like rm -rf. But , it is perfectly safe to use eval() on strings , if they are known to be constrained. This problem is analogous to SQL injection.

Before:
<pre>
- for node in childNodes
- fnode = eval(params[:reactParams][:nodeType]).new
</pre>

After:
<pre>
+ def initialize_fnode_update_children(params, node, tmp_res)
+ fnode = (params[:reactParams][:nodeType]).constantize.new
</pre>

==7) Avoid the use of the case equality operator `===`.==
`===` has been replaced by `==` in the following manner:
<pre>
- tmpObject["private"] = node.get_instructor_id === session[:user].id ? true : false
</pre>
has been changed to ⇒
<pre>
+ "private" => node.get_instructor_id == session[:user].id ? true : false
</pre>
==8) Line is too long.==
Very long lines needs to be made short so that it is more readable, which was done in the following manner:
<pre>
tmpObject["is_available"] = is_available(session[:user], instructor_id) || (session[:user].role.ta? && Ta.get_my_instructors(session[:user].id).include?(instructor_id) && ta_for_current_course?(node))
</pre>
Changed to ⇒
<pre>
tmpObject["is_available"] = is_available(session[:user], instructor_id) || (session[:user].role.ta? && Ta.get_my_instructors(session[:user].id).include?(instructor_id) && ta_for_current_course?(node))
</pre>

<pre>
- available_condition_2 = session[:user].role_id == 6 and Ta.get_my_instructors(session[:user].id).include?(instructor_id) and ta_for_current_course?(child)
</pre>
Changed to ==>

<pre>
+ def is_current_user_ta?(instructor_id, child)
+ # instructor created the course, current user is the ta of this course.
+ session[:user].role_id == 6 and
+ Ta.get_my_instructors(session[:user].id).include?(instructor_id) and ta_for_current_course?(child)
end
</pre>
=Future Considerations=

=Conclusion=
In conclusion, we were able to successfully refactor the tree_display_controller and related Rspec tests. We have improved and expanded the use of RESTful and DRY design choices, and overall improved the quality and efficiency of the Expertiza codebase. We have fixed all the issues detected by Code Climate Chrome Extension and refactored the code to make sure it followed good ruby practices and in the end were able to improve the Code Climate score from F to A while not breaking any of the Rspec tests related.

E1645

2016-10-28T22:31:12Z

Bkasliw: More code updates

= '''E1645: Refactoring TreeDisplayController''' =

__TOC__

=Project Links=
[https://github.com/expertiza/expertiza Github Repo] 
[https://github.com/expertiza/expertiza/pull/744 Expertize Pull Request] 
[https://travis-ci.org/expertiza/expertiza/builds/171173212 Travis CI Test Cases Passes] 

=Setup - How To View Our Expertiza Fork Running on AWS=
NOTE: The scope of our project was only to refactor select code. There are no feature additions or changes, so it should work just like production Expertiza.

1) Go to [http://ec2-54-186-80-176.us-west-2.compute.amazonaws.com:3000/ our Expertiza project running on AWS]

2) Login as Admin 
'''User:''' user2 
'''Password:''' password

3) Click on "Manage..." if you are not automatically directed to the tree display.

=Project Description=

For this project, our team refactored the TreeDisplayController class in the [http://expertiza.ncsu.edu/ Expertiza] OSS project. This class provides access to questionnaires, review rubrics, author feedback, courses, assignments, and course evaluations. The tree display lists all of these categories with the ability for the user to "drill down" into the subcategories or just expand/collapse as needed.

=Refactoring TreeDisplayController Issues=

As part of the refactoring task, we had to resolve the following issues for enhancing code readability and maintainability. The tasks included:

#Similar code found in other locations.
#Cyclomatic and Perceived complexity for get_children_node_ng is too high.
#Useless assignment to variable - `childNodes`.
#Use snake_case for variable names.
#Prefer `each` over `for`.
#The use of `eval` is a serious security risk.
#Avoid the use of the case equality operator `===`.
#Line is too long.
#`end` at 334, 2 is not aligned with `class` at 1, 0.

==1) Similar code found in other locations==

In order to make the code DRY, similar code was moved to a new function, and that was called from the remaining part of the code.

<pre>
def goto_questionnaires
node_object = TreeFolder.find_by_name('Questionnaires')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to review rubrics
def goto_review_rubrics
node_object = TreeFolder.find_by_name('Review')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to metareview rubrics
def goto_metareview_rubrics
node_object = TreeFolder.find_by_name('Metareview')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to teammate review rubrics
def goto_teammatereview_rubrics
node_object = TreeFolder.find_by_name('Teammate Review')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to author feedbacks
def goto_author_feedbacks
node_object = TreeFolder.find_by_name('Author Feedback')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end
</pre>

Changed to ⇒

<pre>
def goto_controller(name_parameter)
node_object = TreeFolder.find_by(name: name_parameter)
session[:root] = FolderNode.find_by(node_object_id: node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to questionnaires
def goto_questionnaires
goto_controller('Questionnaires')
end

# direct access to review rubrics
def goto_review_rubrics
goto_controller('Review')
end

# direct access to metareview rubrics
def goto_metareview_rubrics
goto_controller('Metareview')
end

# direct access to teammate review rubrics
def goto_teammatereview_rubrics
goto_controller('Teammate Review')
end
</pre>

==2) Cyclomatic and Perceived complexity for get_children_node_ng is too high==
By creating two separate functions child_nodes_from_params and initialize_fnode_update_children, the complexity for this function was reduced. The initialize_fnode_update_children function was in-turn sub-functioned into update_fnode_children which updated the children nodes.
The new function looks like this:

<pre>
def children_node_ng
child_nodes = child_nodes_from_params(params[:reactParams][:child_nodes])
tmp_res = {}
child_nodes.each do |node|
initialize_fnode_update_children(params, node, tmp_res)
end
# res = res_node_for_child(tmp_res)
res = res_node_for_child(tmp_res)
respond_to do |format|
format.html { render json: res }
end
end
</pre>

==3) Useless assignment to variable - `childNodes`.==
Following were removed from the two places:
<pre>
135 - childNodes = {}
</pre>

<pre>
222 - childNodes = {}
</pre>

==4) Use snake_case for variable names.==
Variable names using camelCase were renamed to use snake_case as according to ruby coding guidelines.
Before:
<pre>
- childNodes = {}
- tmpRes = {}
</pre>

After:
<pre>
+ child_nodes = child_nodes_from_params(params[:reactParams][:child_nodes])
+ tmp_res = {}
</pre>

==5) Prefer `each` over `for`==
For was replace by each, as follows:
Before:
<pre>
</pre>

After:
<pre>
</pre>

==6)The use of `eval` is a serious security risk.==
eval() executes a string of characters as code. eval() is used in situations where the string contents are not known beforehand or even when the string is generated dynamically. Basically, when eval() is called , it starts a compiler to translate the string. This is detrimental especially when eval() is called on a string submitted by or modifiable by the user. Imagine if the string contains an OS call like rm -rf. But , it is perfectly safe to use eval() on strings , if they are known to be constrained. This problem is analogous to SQL injection.

Before:
<pre>
- for node in childNodes
- fnode = eval(params[:reactParams][:nodeType]).new
</pre>

After:
<pre>
+ def initialize_fnode_update_children(params, node, tmp_res)
+ fnode = (params[:reactParams][:nodeType]).constantize.new
</pre>

==7) Avoid the use of the case equality operator `===`.==
`===` has been replaced by `==` in the following manner:
<pre>
- tmpObject["private"] = node.get_instructor_id === session[:user].id ? true : false
</pre>
has been changed to ⇒
<pre>
+ "private" => node.get_instructor_id == session[:user].id ? true : false
</pre>
==8) Line is too long.==
<pre>
tmpObject["is_available"] = is_available(session[:user], instructor_id) || (session[:user].role.ta? && Ta.get_my_instructors(session[:user].id).include?(instructor_id) && ta_for_current_course?(node))
</pre>
Changed to ⇒
<pre>
tmpObject["is_available"] = is_available(session[:user], instructor_id) || (session[:user].role.ta? && Ta.get_my_instructors(session[:user].id).include?(instructor_id) && ta_for_current_course?(node))
</pre>

<pre>
- available_condition_2 = session[:user].role_id == 6 and Ta.get_my_instructors(session[:user].id).include?(instructor_id) and ta_for_current_course?(child)
</pre>
Changed to ==>

<pre>
+ def is_current_user_ta?(instructor_id, child)
+ # instructor created the course, current user is the ta of this course.
+ session[:user].role_id == 6 and
+ Ta.get_my_instructors(session[:user].id).include?(instructor_id) and ta_for_current_course?(child)
end
</pre>
=Future Considerations=

=Conclusion=
In conclusion, we were able to successfully refactor the tree_display_controller and related Rspec tests. We have improved and expanded the use of RESTful and DRY design choices, and overall improved the quality and efficiency of the Expertiza codebase. We have fixed all the issues detected by Code Climate Chrome Extension and refactored the code to make sure it followed good ruby practices and in the end were able to improve the Code Climate score from F to A while not breaking any of the Rspec tests related.

E1645

2016-10-28T22:15:21Z

Bkasliw: Replacing code

= '''E1645: Refactoring TreeDisplayController''' =

__TOC__

=Project Links=
[https://github.com/expertiza/expertiza Github Repo] 
[https://github.com/expertiza/expertiza/pull/744 Expertize Pull Request] 
[https://travis-ci.org/expertiza/expertiza/builds/171173212 Travis CI Test Cases Passes] 

=Setup - How To View Our Expertiza Fork Running on AWS=
NOTE: The scope of our project was only to refactor select code. There are no feature additions or changes, so it should work just like production Expertiza.

1) Go to [http://ec2-54-186-80-176.us-west-2.compute.amazonaws.com:3000/ our Expertiza project running on AWS]

2) Login as Admin 
'''User:''' user2 
'''Password:''' password

3) Click on "Manage..." if you are not automatically directed to the tree display.

=Project Description=

For this project, our team refactored the TreeDisplayController class in the [http://expertiza.ncsu.edu/ Expertiza] OSS project. This class provides access to questionnaires, review rubrics, author feedback, courses, assignments, and course evaluations. The tree display lists all of these categories with the ability for the user to "drill down" into the subcategories or just expand/collapse as needed.

=Refactoring TreeDisplayController Issues=

As part of the refactoring task, we had to resolve the following issues for enhancing code readability and maintainability. The tasks included:

#Similar code found in other locations.
#Cyclomatic and Perceived complexity for get_children_node_ng is too high.
#Useless assignment to variable - `childNodes`.
#Use snake_case for variable names.
#Prefer `each` over `for`.
#The use of `eval` is a serious security risk.
#Avoid the use of the case equality operator `===`.
#Line is too long.
#`end` at 334, 2 is not aligned with `class` at 1, 0.

==1) Similar code found in other locations==

In order to make the code DRY, similar code was moved to a new function, and that was called from the remaining part of the code.

<pre>
def goto_questionnaires
node_object = TreeFolder.find_by_name('Questionnaires')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to review rubrics
def goto_review_rubrics
node_object = TreeFolder.find_by_name('Review')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to metareview rubrics
def goto_metareview_rubrics
node_object = TreeFolder.find_by_name('Metareview')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to teammate review rubrics
def goto_teammatereview_rubrics
node_object = TreeFolder.find_by_name('Teammate Review')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to author feedbacks
def goto_author_feedbacks
node_object = TreeFolder.find_by_name('Author Feedback')
session[:root] = FolderNode.find_by_node_object_id(node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end
</pre>

Changed to ⇒

<pre>
def goto_controller(name_parameter)
node_object = TreeFolder.find_by(name: name_parameter)
session[:root] = FolderNode.find_by(node_object_id: node_object.id).id
redirect_to controller: 'tree_display', action: 'list'
end

# direct access to questionnaires
def goto_questionnaires
goto_controller('Questionnaires')
end

# direct access to review rubrics
def goto_review_rubrics
goto_controller('Review')
end

# direct access to metareview rubrics
def goto_metareview_rubrics
goto_controller('Metareview')
end

# direct access to teammate review rubrics
def goto_teammatereview_rubrics
goto_controller('Teammate Review')
end
</pre>

==2) Cyclomatic and Perceived complexity for get_children_node_ng is too high==
By creating two separate functions child_nodes_from_params and initialize_fnode_update_children, the complexity for this function was reduced. The initialize_fnode_update_children function was in-turn sub-functioned into update_fnode_children which updated the children nodes.
The new function looks like this:

<pre>
def children_node_ng
child_nodes = child_nodes_from_params(params[:reactParams][:child_nodes])
tmp_res = {}
child_nodes.each do |node|
initialize_fnode_update_children(params, node, tmp_res)
end
# res = res_node_for_child(tmp_res)
res = res_node_for_child(tmp_res)
respond_to do |format|
format.html { render json: res }
end
end
</pre>

==3) Useless assignment to variable - `childNodes` were removed from following two places.==

<pre>
135 - childNodes = {}
</pre>

<pre>
222 - childNodes = {}
</pre>

==4) Use snake_case for variable names.==
Variable names using camelCase were renamed to use snake_case as according to ruby coding guidelines.
Before:
<pre>
</pre>

After:
<pre>
</pre>

==5) Prefer `each` over `for`==
Before:
<pre>
</pre>

After:
<pre>
</pre>

==6)The use of `eval` is a serious security risk.==
eval() executes a string of characters as code. eval() is used in situations where the string contents are not known beforehand or even when the string is generated dynamically. Basically, when eval() is called , it starts a compiler to translate the string. This is detrimental especially when eval() is called on a string submitted by or modifiable by the user. Imagine if the string contains an OS call like rm -rf. But , it is perfectly safe to use eval() on strings , if they are known to be constrained. This problem is analogous to SQL injection.

Before:
<pre>
- for node in childNodes
- fnode = eval(params[:reactParams][:nodeType]).new
</pre>

After:
<pre>
+ def initialize_fnode_update_children(params, node, tmp_res)
+ fnode = (params[:reactParams][:nodeType]).constantize.new
</pre>

==7) Avoid the use of the case equality operator `===`.==
<pre>
</pre>
has been changed to ⇒
<pre>
</pre>
==8) Line is too long.==
[[File:8_1_before.png]]

Changed to ==>

[[File:8_1_after.png]]

[[File:8_2_before.png]]

Changed to ==>

[[File:8_2_after.png|upright=1.5]]

=Future Considerations=

=Conclusion=
In conclusion, we were able to successfully refactor the tree_display_controller and related Rspec tests. We have improved and expanded the use of RESTful and DRY design choices, and overall improved the quality and efficiency of the Expertiza codebase. We have fixed all the issues detected by Code Climate Chrome Extension and refactored the code to make sure it followed good ruby practices and in the end were able to improve the Code Climate score from F to A while not breaking any of the Rspec tests related.

E1645

2016-10-28T21:36:43Z

Bkasliw: Created page with "= '''E1463: Refactoring TreeDisplayController''' = __TOC__ =Project Links= [https://github.com/expertiza/expertiza Github Repo] [https://github.com/expertiza/expertiza/pull..."

= '''E1463: Refactoring TreeDisplayController''' =

__TOC__

=Project Links=
[https://github.com/expertiza/expertiza Github Repo] 
[https://github.com/expertiza/expertiza/pull/744 Expertize Pull Request] 
[https://travis-ci.org/expertiza/expertiza/builds/171173212 Travis CI Test Cases Passes] 

=Setup - How To View Our Expertiza Fork Running on AWS=
NOTE: The scope of our project was only to refactor select code. There are no feature additions or changes, so it should work just like production Expertiza.

1) Go to [http://ec2-54-186-80-176.us-west-2.compute.amazonaws.com:3000/ our Expertiza project running on AWS]

2) Login as Admin 
'''User:''' user2 
'''Password:''' password

3) Click on "Manage..." if you are not automatically directed to the tree display.

=Project Description=

For this project, our team refactored the TreeDisplayController class in the [http://expertiza.ncsu.edu/ Expertiza] OSS project. This class provides access to questionnaires, review rubrics, author feedback, courses, assignments, and course evaluations. The tree display lists all of these categories with the ability for the user to "drill down" into the subcategories or just expand/collapse as needed.

=Refactoring TreeDisplayController Issues=

As part of the refactoring task, we had to resolve the following issues for enhancing code readability and maintainability. The tasks included:

#Similar code found in other locations.
#Cyclomatic and Perceived complexity for get_children_node_ng is too high.
#Useless assignment to variable - `childNodes`.
#Use snake_case for variable names.
#Prefer `each` over `for`.
#The use of `eval` is a serious security risk.
#Avoid the use of the case equality operator `===`.
#Line is too long.
#`end` at 334, 2 is not aligned with `class` at 1, 0.

==1) Similar code found in other locations==

In order to make the codebase more [http://www.restapitutorial.com/lessons/whatisrest.html RESTful], we have replaced all the controller action redirections with a tree_display_index_path which enormously reduces the code content and as well as provides an organized approach to action redirections.

[[File:1_before.png]]

Changed to ⇒

[[File:1_after.png]]

==2) Cyclomatic and Perceived complexity for get_children_node_ng is too high==
By creating two separate functions child_nodes_from_params and initialize_fnode_update_children, the complexity for this function was reduced.
The initialize_fnode_update_children function was in-turn sub-functioned into update_fnode_children which updated the children nodes.
The new function looks like this:

[[File:2.png]]

==3) Useless assignment to variable - `childNodes` were removed from following two places.==

==4) Use snake_case for variable names.==
Variable names using camelCase were renamed to use snake_case as according to ruby coding guidelines.

==5) Prefer `each` over `for`==

==6)The use of `eval` is a serious security risk.==
==7) Avoid the use of the case equality operator `===`.==

has been changed to ⇒

==8) Line is too long.==

=Future Considerations=

=Conclusion=
In conclusion, we were able to successfully refactor the tree_display_controller and related controllers and views. We improved and expanded the use of RESTful and DRY design choices, implemented the use of routing helpers, ensured that instantiation of instance variables is minimized, and overall improved the quality and efficiency of the Expertiza codebase. We also discovered a number of potential issues and additional areas for improvement.

File:ScreenShotOODD.png

2016-10-28T21:32:58Z

Bkasliw: Initial draft

File:ScreenShotOODD.png

2016-10-28T21:01:37Z

Bkasliw: