Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T03:17:22Z

Abhutan: /* Steps to verify changes */

'''E810 Regularize staggered-deadline assignments'''

This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

'''Introduction to Expertiza''' 

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Resources =

[https://github.com/abhutan/expertiza GitHub Project Repository]

[http://152.7.99.160:3000/ VCL IP Address]

[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Wiki]

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

Additionally, project required removal of redundant and dead code which enhances code readability and optimizes code performance.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. We have made a single method call and condition check in various files ,for type of assignment, has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Current Scenario===

The add_signup_topics calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it introduced code smells. So it was checked if there was any reference to this code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Current Scenario===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes===

def create_default_for_microtask
.....

.....
end

=Steps to verify changes=
Log into the application with the user having instructor's role or super user's role.

1. Go to Manage -> Assignments and hover over the assignment “StaggeredDeadlines_Refactoring”.

2. Click on “New Topic”.

3. Enter the details of the topic you want to create. Create at least 2 topics for better analysis of the project.

[[File:AddTopic.png]]

4. Now once you have created two new topics , then Click on “Show start/due date”.

5. You should be able to view the new start and due dates of your topics confirming these are the staggered deadlines for “StaggeredDeadlines_Refactoring” which has many topics with different deadlines.

[[File:ShowdueDate.png]]

6. Now to view the difference between the Stagerred and Non-Staggered Deadlines, follow steps.

7. Go to Manage -> Assignments and hover over “SALT Demo” and click on “Edit Signup sheet”.

8. Click on “New Topic” and fill in the details for a new topic.

[[File:NonstaggeredAddTopic.png]]

9. Now you will be able to see that there is no option for “Show Start/Due Date” which is because of the reason that this is not a staggered assignment.

[[File:NodueDate.png]]

10. Hence there is only one due date and has no dependencies on others.

= Concise Report on Refactoring =

The project had redundant code, multiple functionalities in a method and extra conditional statements in controller, model and view files. We analyzed each occurrence of these issues, thus creating a list which needed to be refactored. Controllers like sign_up_sheet_controler, assignment.rb, due_date.rb,deadline_types.rb along with other files were modified. It's very difficult to explain the sequential and detailed procedure, but it has been explained in the sections above within the capacity of the Wiki.

= Additional Learning and Future Work=

In current implementation, our database has two tables for staggered and non-staggered deadlines. For any future improvements, we can make use of STI (Single Table Inheritance) and analyze if applying STI would really impact query performance when application runs and extracts data from database.

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T03:16:35Z

Abhutan: /* Steps to verify changes */

'''E810 Regularize staggered-deadline assignments'''

This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

'''Introduction to Expertiza''' 

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Resources =

[https://github.com/abhutan/expertiza GitHub Project Repository]

[http://152.7.99.160:3000/ VCL IP Address]

[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Wiki]

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

Additionally, project required removal of redundant and dead code which enhances code readability and optimizes code performance.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. We have made a single method call and condition check in various files ,for type of assignment, has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Current Scenario===

The add_signup_topics calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it introduced code smells. So it was checked if there was any reference to this code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Current Scenario===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes===

def create_default_for_microtask
.....

.....
end

=Steps to verify changes=
Log into the application with the user having instructor's role or super user's role.

1. Go to Manage -> Assignments and hover over the assignment “StaggeredDeadlines_Refactoring”.

2. Click on “New Topic”.

3. Enter the details of the topic you want to create. Create at least 2 topics for better analysis of the project.

[[File:AddTopic.png]]

4. Now once you have created two new topics , then Click on “Show start/due date”.

5. You should be able to view the new start and due dates of your topics confirming these are the staggered deadlines for “StaggeredDeadlines_Refactoring” which has many topics with different deadlines.

[[File:ShowdueDate.png]]

6. Now to view the difference between the Stagerred and Non-Staggered Deadlines, follow steps.

7. Go to Manage -> Assignments and hover over “SALT Demo” and click on “Edit Signup sheet”.

8. Click on “New Topic” and fill in the details for a new topic.

[[File:NonstaggeredAddTopic.png]]

9. Now you will be able to see that there is no option for “Show Start/Due Date” which is because of the reason that this is not a staggered assignment.

[[File:NodueDate.png|200px]]

10. Hence there is only one due date and has no dependencies on others.

= Concise Report on Refactoring =

The project had redundant code, multiple functionalities in a method and extra conditional statements in controller, model and view files. We analyzed each occurrence of these issues, thus creating a list which needed to be refactored. Controllers like sign_up_sheet_controler, assignment.rb, due_date.rb,deadline_types.rb along with other files were modified. It's very difficult to explain the sequential and detailed procedure, but it has been explained in the sections above within the capacity of the Wiki.

= Additional Learning and Future Work=

In current implementation, our database has two tables for staggered and non-staggered deadlines. For any future improvements, we can make use of STI (Single Table Inheritance) and analyze if applying STI would really impact query performance when application runs and extracts data from database.

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T03:15:55Z

Abhutan: /* Steps to verify changes */

'''E810 Regularize staggered-deadline assignments'''

This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

'''Introduction to Expertiza''' 

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Resources =

[https://github.com/abhutan/expertiza GitHub Project Repository]

[http://152.7.99.160:3000/ VCL IP Address]

[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Wiki]

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

Additionally, project required removal of redundant and dead code which enhances code readability and optimizes code performance.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. We have made a single method call and condition check in various files ,for type of assignment, has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Current Scenario===

The add_signup_topics calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it introduced code smells. So it was checked if there was any reference to this code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Current Scenario===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes===

def create_default_for_microtask
.....

.....
end

=Steps to verify changes=
Log into the application with the user having instructor's role or super user's role.

1. Go to Manage -> Assignments and hover over the assignment “StaggeredDeadlines_Refactoring”.

2. Click on “New Topic”.

3. Enter the details of the topic you want to create. Create at least 2 topics for better analysis of the project.

[[File:AddTopic.png]]

4. Now once you have created two new topics , then Click on “Show start/due date”.

5. You should be able to view the new start and due dates of your topics confirming these are the staggered deadlines for “StaggeredDeadlines_Refactoring” which has many topics with different deadlines.

[[File:ShowdueDate.png]]

6. Now to view the difference between the Stagerred and Non-Staggered Deadlines, follow steps.

7. Go to Manage -> Assignments and hover over “SALT Demo” and click on “Edit Signup sheet”.

8. Click on “New Topic” and fill in the details for a new topic.

[[File:NonstaggeredAddTopic.png]]

9. Now you will be able to see that there is no option for “Show Start/Due Date” which is because of the reason that this is not a staggered assignment.

[[File:NodueDate.png]]200px

10. Hence there is only one due date and has no dependencies on others.

= Concise Report on Refactoring =

The project had redundant code, multiple functionalities in a method and extra conditional statements in controller, model and view files. We analyzed each occurrence of these issues, thus creating a list which needed to be refactored. Controllers like sign_up_sheet_controler, assignment.rb, due_date.rb,deadline_types.rb along with other files were modified. It's very difficult to explain the sequential and detailed procedure, but it has been explained in the sections above within the capacity of the Wiki.

= Additional Learning and Future Work=

In current implementation, our database has two tables for staggered and non-staggered deadlines. For any future improvements, we can make use of STI (Single Table Inheritance) and analyze if applying STI would really impact query performance when application runs and extracts data from database.

File:NonstaggeredAddTopic.png

2013-10-31T03:14:45Z

Abhutan:

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T03:13:43Z

Abhutan: /* Steps to verify changes */

'''E810 Regularize staggered-deadline assignments'''

This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

'''Introduction to Expertiza''' 

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Resources =

[https://github.com/abhutan/expertiza GitHub Project Repository]

[http://152.7.99.160:3000/ VCL IP Address]

[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza Wiki]

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

Additionally, project required removal of redundant and dead code which enhances code readability and optimizes code performance.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. We have made a single method call and condition check in various files ,for type of assignment, has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Current Scenario===

The add_signup_topics calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it introduced code smells. So it was checked if there was any reference to this code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Current Scenario===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes===

def create_default_for_microtask
.....

.....
end

=Steps to verify changes=
Log into the application with the user having instructor's role or super user's role.

1. Go to Manage -> Assignments and hover over the assignment “StaggeredDeadlines_Refactoring”.

2. Click on “New Topic”.

3. Enter the details of the topic you want to create. Create at least 2 topics for better analysis of the project.

[[File:AddTopic.png]]

4. Now once you have created two new topics , then Click on “Show start/due date”.

5. You should be able to view the new start and due dates of your topics confirming these are the staggered deadlines for “StaggeredDeadlines_Refactoring” which has many topics with different deadlines.

[[File:ShowdueDate.png]]

6. Now to view the difference between the Stagerred and Non-Staggered Deadlines, follow steps.

7. Go to Manage -> Assignments and hover over “SALT Demo” and click on “Edit Signup sheet”.

8. Click on “New Topic” and fill in the details for a new topic.

[[File:AddTopic.png]]

9. Now you will be able to see that there is no option for “Show Start/Due Date” which is because of the reason that this is not a staggered assignment.

[[File:NodueDate.png]]

10. Hence there is only one due date and has no dependencies on others.

= Concise Report on Refactoring =

The project had redundant code, multiple functionalities in a method and extra conditional statements in controller, model and view files. We analyzed each occurrence of these issues, thus creating a list which needed to be refactored. Controllers like sign_up_sheet_controler, assignment.rb, due_date.rb,deadline_types.rb along with other files were modified. It's very difficult to explain the sequential and detailed procedure, but it has been explained in the sections above within the capacity of the Wiki.

= Additional Learning and Future Work=

In current implementation, our database has two tables for staggered and non-staggered deadlines. For any future improvements, we can make use of STI (Single Table Inheritance) and analyze if applying STI would really impact query performance when application runs and extracts data from database.

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T03:13:14Z

Abhutan: /* Steps to verify changes */

'''E810 Regularize staggered-deadline assignments'''

This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

'''Introduction to Expertiza''' 

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Resources =

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

Additionally, project required removal of redundant and dead code which enhances code readability and optimizes code performance.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. We have made a single method call and condition check in various files ,for type of assignment, has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Current Scenario===

The add_signup_topics calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it introduced code smells. So it was checked if there was any reference to this code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Current Scenario===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes===

def create_default_for_microtask
.....

.....
end

=Steps to verify changes=
Log into the application with the user having instructor's role or super user's role.

1. Go to Manage-> Assignments and hover over the assignment “StaggeredDeadlines_Refactoring”.

2. Click on “New Topic”.

3. Enter the details of the topic you want to create. Create at least 2 topics for better analysis of the project.

[[File:AddTopic.png]]

4. Now once you have created two new topics , then Click on “Show start/due date”.

5. You should be able to view the new start and due dates of your topics confirming these are the staggered deadlines for “StaggeredDeadlines_Refactoring” which has many topics with different deadlines.

[[File:ShowdueDate.png]]

6. Now to view the difference between the Stagerred and Non-Staggered Deadlines, follow steps.

7. Go to Manage Assignments and hover over “SALT Demo” and click on “Edit Signup sheet”.

8. Click on “New Topic” and fill in the details for a new topic.

[[File:AddTopic.png]]

9. Now you will be able to see that there is no option for “Show Start/Due Date” which is because of the reason that this is not a staggered assignment.

[[File:NodueDate.png]]

10. Hence there is only one due date and has no dependencies on others.

= Concise Report on Refactoring =

The project had redundant code, multiple functionalities in a method and extra conditional statements in controller, model and view files. We analyzed each occurrence of these issues, thus creating a list which needed to be refactored. Controllers like sign_up_sheet_controler, assignment.rb, due_date.rb,deadline_types.rb along with other files were modified. It's very difficult to explain the sequential and detailed procedure, but it has been explained in the sections above within the capacity of the Wiki.

= Additional Learning and Future Work=

In current implementation, our database has two tables for staggered and non-staggered deadlines. For any future improvements, we can make use of STI (Single Table Inheritance) and analyze if applying STI would really impact query performance when application runs and extracts data from database.

File:AddTopic.png

2013-10-31T03:12:35Z

Abhutan: uploaded a new version of "File:AddTopic.png"

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T03:10:47Z

Abhutan: /* Steps to verify changes */

'''E810 Regularize staggered-deadline assignments'''

This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

'''Introduction to Expertiza''' 

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Resources =

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

Additionally, project required removal of redundant and dead code which enhances code readability and optimizes code performance.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. We have made a single method call and condition check in various files ,for type of assignment, has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Current Scenario===

The add_signup_topics calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it introduced code smells. So it was checked if there was any reference to this code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Current Scenario===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes===

def create_default_for_microtask
.....

.....
end

=Steps to verify changes=
Log into the application with the user having instructor's role or super user's role.

1. Go to Manage-> Assignments and hover over the assignment “StaggeredDeadlines_Refactoring”.

2. Click on “New Topic”.

3. Enter the details of the topic you want to create. Create at least 2 topics for better analysis of the project.

[[File:AddTopic.png]]

4. Now once you have created two new topics , then Click on “Show start/due date”.

5. You should be able to view the new start and due dates of your topics confirming these are the staggered deadlines for “StaggeredDeadlines_Refactoring” which has many topics with different deadlines.

[[File:ShowdueDate.png]]

6. Now to view the difference between the Stagerred and Non-Staggered Deadlines, follow steps.

7. Go to Manage Assignments and Hover over “SALT Demo” and click on “Edit Signup sheet”.

8. Click on “New Topic” and fill in the details for a new topic.

[[File:AddTopic.png]]

9. Now you will be able to see that there is no option for “Show Start/Due Date” which is because of the reason that this is not a staggered assignment.

[[File:NodueDate.png]]

10. Hence there is only one due date and has no dependencies on others.

= Concise Report on Refactoring =

The project had redundant code, multiple functionalities in a method and extra conditional statements in controller, model and view files. We analyzed each occurrence of these issues, thus creating a list which needed to be refactored. Controllers like sign_up_sheet_controler, assignment.rb, due_date.rb,deadline_types.rb along with other files were modified. It's very difficult to explain the sequential and detailed procedure, but it has been explained in the sections above within the capacity of the Wiki.

= Additional Learning and Future Work=

In current implementation, our database has two tables for staggered and non-staggered deadlines. For any future improvements, we can make use of STI (Single Table Inheritance) and analyze if applying STI would really impact query performance when application runs and extracts data from database.

File:NodueDate.png

2013-10-31T03:07:41Z

Abhutan: uploaded a new version of "File:NodueDate.png"

File:ShowdueDate.png

2013-10-31T03:07:17Z

Abhutan: uploaded a new version of "File:ShowdueDate.png"

File:AddTopic.png

2013-10-31T03:06:50Z

Abhutan: uploaded a new version of "File:AddTopic.png"

File:AddTopic.png

2013-10-31T03:06:14Z

Abhutan: uploaded a new version of "File:AddTopic.png"

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T02:52:21Z

Abhutan: /* Steps to verify changes */

'''E810 Regularize staggered-deadline assignments'''

This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

'''Introduction to Expertiza''' 

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Current Scenario===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it introduced code smells. So it was checked if there was any reference to this code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Current Scenario===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes===

def create_default_for_microtask
.....

.....
end

=Steps to verify changes=
Log into the application with the user having instructor's role or super user's role.

1. Go to Manage-> Assignments and hover over the assignment “StaggeredDeadlines_Refactoring”.

2. Click on “New Topic”.

3. Enter the details of the topic you want to create. Create at least 2 topics for better analysis of the project.

[[File:AddTopic.png]]

4. Now once you have created two new topics , then Click on “Show start/due date”.

5. You should be able to view the new start and due dates of your topics confirming these are the staggered deadlines for “StaggeredDeadlines_Refactoring” which has many topics with different deadlines.

[[File:ShowdueDate.png]]

6. Now to view the difference between the Stagerred and Non-Staggered Deadlines, follow steps.

7. Go to Manage Assignments and Hover over “SALT Demo” and click on “Edit Signup sheet”.

[[File:NodueDate.png]]

8. Click on “New Topic” and fill in the details for a new topic.

9. Now you will be able to see that there is no option for “Show Start/Due Date” which is because of the reason that this is not a staggered assignment.

10. Hence there is only one due date and has no dependencies on others.

= Concise Report on Refactoring =

The project had redundant code, multiple functionalities in a method and extra conditional statements in controller, model and view files. We analyzed each occurrence of these issues, thus creating a list which needed to be refactored. Controllers like sign_up_sheet_controler, assignment.rb, due_date.rb,deadline_types.rb along with other files were modified. It's very difficult to explain the sequential and detailed procedure, but it has been explained in the sections above within the capacity of the Wiki.

= Additional Learning and Future Work=

In current implementation, our database has two tables for staggered and non-staggered deadlines. For any future improvements, we can make use of STI (Single Table Inheritance) and analyze if applying STI would really impact query performance when application runs and extracts data from database.

File:NodueDate.png

2013-10-31T02:51:43Z

Abhutan:

File:ShowdueDate.png

2013-10-31T02:48:32Z

Abhutan:

File:AddTopic.png

2013-10-31T02:46:03Z

Abhutan: uploaded a new version of "File:AddTopic.png"

File:AddTopic.png

2013-10-31T02:44:56Z

Abhutan:

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T02:41:09Z

Abhutan: /* Steps to verify changes */

'''E810 Regularize staggered-deadline assignments'''

This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

'''Introduction to Expertiza''' 

[http://expertiza.ncsu.edu/ Expertiza] is a project developed using Ruby on Rails platform. It provides features like peer review, team assignments and submission of projects. This can be achieved by submitting code base, URL of hosted code on Remote Servers and Wiki submissions. It is open source application and the code can be cloned from [https://github.com/expertiza/expertiza github]. This application provides an efficient way to manage assignments, grades and reviews. This makes the process easier and faster when the class strength is large.

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Current Scenario===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it introduced code smells. So it was checked if there was any reference to this code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Current Scenario===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes===

def create_default_for_microtask
.....

.....
end

=Steps to verify changes=
Log into the application with the user having instructor's role or super user's role.

1. Go to Manage-> Assignments and hover over the assignment “StaggeredDeadlines_Refactoring”.

2. Click on “New Topic”.

3. Enter the details of the topic you want to create. Create at least 2 topics for better analysis of the project.

4. Now once you have created two new topics , then Click on “Show start/due date”.

5. You should be able to view the new start and due dates of your topics confirming these are the staggered deadlines for “StaggeredDeadlines_Refactoring” which has many topics with different deadlines.

6. Now to view the difference between the Stagerred and Non-Staggered Deadlines, follow steps.

7. Go to Manage Assignments and Hover over “SALT Demo” and click on “Edit Signup sheet”.

8. Click on “New Topic” and fill in the details for a new topic.

9. Now you will be able to see that there is no option for “Show Start/Due Date” which is because of the reason that this is not a staggered assignment.

10. Hence there is only one due date and has no dependencies on others.

= Concise Report on Refactoring =

The project had redundant code, multiple functionalities in a method and extra conditional statements in controller, model and view files. We analyzed each occurrence of these issues, thus creating a list which needed to be refactored. Controllers like sign_up_sheet_controler, assignment.rb, due_date.rb,deadline_types.rb along with other files were modified. It's very difficult to explain the sequential and detailed procedure, but it has been explained in the sections above within the capacity of the Wiki.

= Additional Learning and Future Work=

In current implementation, our database has two tables for staggered and non-staggered deadlines. For any future improvements, we can make use of STI (Single Table Inheritance) and analyze if applying STI would really impact query performance when application runs and extracts data from database.

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T02:38:20Z

Abhutan: /* Steps to verify changes */

'''E810 Regularize staggered-deadline assignments'''

This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

= Concise Report on Refactoring =

The project had redundant code, multiple functionalities in a method and extra conditional statements in controller, model and view files. We analyzed each occurrence of these issues, thus creating a list which needed to be refactored. Controllers like sign_up_sheet_controler, assignment.rb, due_date.rb,deadline_types.rb along with other files were modified. It's very difficult to explain the sequential and detailed procedure, but it has been explained in the sections above within the capacity of the Wiki.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Current Scenario===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it introduced code smells. So it was checked if there was any reference to this code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Current Scenario===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes===

def create_default_for_microtask
.....

.....
end

=Steps to verify changes=
Log into the application with the user having instructor's role or super user's role.

1. Go to Manage-> Assignments and hover over the assignment “StaggeredDeadlines_Refactoring”.

2. Click on “New Topic”.

3. Enter the details of the topic you want to create. Create at least 2 topics for better analysis of the project.

4. Now once you have created two new topics , then Click on “Show start/due date”.

5. You should be able to view the new start and due dates of your topics confirming these are the staggered deadlines for “StaggeredDeadlines_Refactoring” which has many topics with different deadlines.

= Additional Learning and Future Work=

In current implementation, our database has two tables for staggered and non-staggered deadlines. For any future improvements, we can make use of STI (Single Table Inheritance) and analyze if applying STI would really impact query performance when application runs and extracts data from database.

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T02:36:22Z

Abhutan: /* Steps to verify changes */

'''=E810 Regularize staggered-deadline assignments=''' 

This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Current Scenario===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it introduced code smells. So it was checked if there was any reference to this code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Current Scenario===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes===

def create_default_for_microtask
.....

.....
end

=Steps to verify changes=
Log into the application with the user having instructor's role or super user's role.

1. Go to Manage-> Assignments and hover over the assignment “StaggeredDeadlines_Refactoring”

= Additional Learning and Future Work=

In current implementation, our database has two tables for staggered and non-staggered deadlines. For any future improvements, we can make use of STI (Single Table Inheritance) and analyze if applying STI would really impact query performance when application runs and extracts data from database.

= Concise Report on Refactoring =

The project had redundant code, multiple functionalities in a method and extra conditional statements in controller, model and view files. We analyzed each occurrence of these issues, thus creating a list which needed to be refactored. Controllers like sign_up_sheet_controler, assignment.rb, due_date.rb,deadline_types.rb along with other files were modified. It's very difficult to explain the sequential and detailed procedure, but it has been explained in the sections above within the capacity of the Wiki.

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T02:36:09Z

Abhutan: /* Steps to verify changes */

'''E810 Regularize staggered-deadline assignments''' 

This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Current Scenario===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it introduced code smells. So it was checked if there was any reference to this code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Current Scenario===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes===

def create_default_for_microtask
.....

.....
end

=Steps to verify changes=
Log into the application with the user having instructor's role or super user's role.
1. Go to Manage-> Assignments and hover over the assignment “StaggeredDeadlines_Refactoring”

= Additional Learning and Future Work=

In current implementation, our database has two tables for staggered and non-staggered deadlines. For any future improvements, we can make use of STI (Single Table Inheritance) and analyze if applying STI would really impact query performance when application runs and extracts data from database.

= Concise Report on Refactoring =

The project had redundant code, multiple functionalities in a method and extra conditional statements in controller, model and view files. We analyzed each occurrence of these issues, thus creating a list which needed to be refactored. Controllers like sign_up_sheet_controler, assignment.rb, due_date.rb,deadline_types.rb along with other files were modified. It's very difficult to explain the sequential and detailed procedure, but it has been explained in the sections above within the capacity of the Wiki.

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T02:30:35Z

Abhutan:

=E810 Regularize staggered-deadline assignments=
This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Current Scenario===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it introduced code smells. So it was checked if there was any reference to this code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Before Changes to Code===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes to Code===

def create_default_for_microtask
.....

.....
end

=Steps to verify changes=

= Additional Learning and Future Work=

In current implementation, our database has two tables for staggered and non-staggered deadlines. For any future improvements, we can make use of STI (Single Table Inheritance) and analyze if applying STI would really impact query performance when application runs and extracts data from database.

= Concise Report on Refactoring =

The project had redundant code, multiple functionalities in a method and extra conditional statements in controller, model and view files. We analyzed each occurrence of these issues, thus creating a list which needed to be refactored. Controllers like sign_up_sheet_controler, assignment.rb, due_date.rb,deadline_types.rb along with other files were modified. It's very difficult to explain the sequential and detailed procedure, but it has been explained in the sections above within the capacity of the Wiki.

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:58:27Z

Abhutan: /* Current Scenario */

=E810 Regularize staggered-deadline assignments=
This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Before Changes to code===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes to Code===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

assignment.rb

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

The local variables topic_set and topic under the staggered deadline check statement were never used in the entire scope of the project , it made the code smelly. So it was checked if there was any reference to this smelly code, and upon discovering it was not used anywhere, we decided to eliminate this code.

===Before Changes to Code===

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

===After Changes to Code===

def create_default_for_microtask
.....

.....
end

= Additional Learning and Future Work=

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:56:55Z

Abhutan: /* After changes */

=E810 Regularize staggered-deadline assignments=
This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Before Changes to code===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes to Code===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

= Additional Learning and Future Work=

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:55:31Z

Abhutan: /* After changes */

=E810 Regularize staggered-deadline assignments=
This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Before Changes to code===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes to Code===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model:

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb:
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date method defined in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method defined in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

= Additional Learning and Future Work=

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:54:34Z

Abhutan: /* Case 3 : Modularize Code in application.rb */

=E810 Regularize staggered-deadline assignments=
This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
....

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
....

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Before Changes to code===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes to Code===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model:

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

New find_next_due_date defined in topic_deadline.rb:
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

New find_next_due_date in due_date.rb

def self.find_next_due_date(assignment_id
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

New find_drop_topic_deadline_id method in deadline_type.rb

def self.find_drop_topic_deadline_id()
DeadlineType.find_by_name('drop_topic').id
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

def create_default_for_microtask
.....

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end

.....
end

= Additional Learning and Future Work=

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:51:21Z

Abhutan: /* After changes */

=E810 Regularize staggered-deadline assignments=
This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
}
end
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Before Changes to code===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes to Code===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model:

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

topic_deadline.rb:
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

def create_default_for_microtask
assignment_id = params[:id]
@sign_up_topic = SignUpTopic.new
@sign_up_topic.topic_identifier = 'MT1'
@sign_up_topic.topic_name = 'Microtask Topic'

@sign_up_topic.max_choosers = '0'
@sign_up_topic.micropayment = 0
@sign_up_topic.assignment_id = assignment_id
@assignment = Assignment.find(params[:id])

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
flash[:notice] = 'Default Microtask topic was created - please update.'
redirect_to_sign_up(assignment_id)
else
render :action => 'new', :id => assignment_id
end
end

= Additional Learning and Future Work=

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:50:51Z

Abhutan: /* Case 3 : Modularize Code in application.rb */

=E810 Regularize staggered-deadline assignments=
This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
}
end
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in various views.
For instance, for view _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Before Changes to code===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes to Code===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model:

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

topic_deadline.rb:
def self.find_next_due_date(topic_id,assignment_id)
drop_topic_deadline_id = DeadlineType.find_drop_topic_deadline_id()
if topic_id
TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else
TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
assignment_id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

def create_default_for_microtask
assignment_id = params[:id]
@sign_up_topic = SignUpTopic.new
@sign_up_topic.topic_identifier = 'MT1'
@sign_up_topic.topic_name = 'Microtask Topic'

@sign_up_topic.max_choosers = '0'
@sign_up_topic.micropayment = 0
@sign_up_topic.assignment_id = assignment_id
@assignment = Assignment.find(params[:id])

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
flash[:notice] = 'Default Microtask topic was created - please update.'
redirect_to_sign_up(assignment_id)
else
render :action => 'new', :id => assignment_id
end
end

= Additional Learning and Future Work=

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:48:36Z

Abhutan: /* Case 3 : Modularize Code in application.rb */

=E810 Regularize staggered-deadline assignments=
This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
}
end
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in views like _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% else %>
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>
<% end %>

After Changes 
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'),
{:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Edit signup sheet'} %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

===Before Changes to code===

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

===After Changes to Code===

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model:

if self.staggered_deadline?
next_due_date = TopicDeadline.find_next_due_date(topic_id,self.id)
else
next_due_date = DueDate.find_next_due_date(self.id)
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

def create_default_for_microtask
assignment_id = params[:id]
@sign_up_topic = SignUpTopic.new
@sign_up_topic.topic_identifier = 'MT1'
@sign_up_topic.topic_name = 'Microtask Topic'
@sign_up_topic.max_choosers = '0'
@sign_up_topic.micropayment = 0
@sign_up_topic.assignment_id = assignment_id

@assignment = Assignment.find(params[:id])

if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id

end

if @sign_up_topic.save

flash[:notice] = 'Default Microtask topic was created - please update.'
redirect_to_sign_up(assignment_id)
else
render :action => 'new', :id => assignment_id
end
end

= Additional Learning and Future Work=

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:42:49Z

Abhutan: /* After changes */

=E810 Regularize staggered-deadline assignments=
This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
}
end
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
We had to make conditional check every time the function is called for the assignment type. For instance, below method redirects to the /add_signup_topics or the /add_signup_topics_staggered page depending on assignment type
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end

===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
redirect_to :action => 'add_signup_topics', :id => assignment_id
end

Similarly the method call is re-factored in views like _assignments_actions.html.erb

Before Changes 
<% if @assignment.staggered_deadline == true %>
- <%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'), {:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Edit signup sheet'} %>
- <% else %>
+
<%= link_to image_tag('/images/tree_view/edit-signup-sheet-24.png', :title => 'Edit signup sheet'), {:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id}, {:title => 'Edit signup sheet'} %>
- <% end %>

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

Before Changes to code

The add_signup_topics , calculated due dates for separate topics for a Staggered assignment with individual Topic deadlines.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

After Changes to Code

The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the new code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

assignment.rb model:

if self.staggered_deadline?
next_due_date = find_next_due_date(topic_id,self.id)
else
next_due_date = find_next_due_date(self.id)
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

= Additional Learning and Future Work=

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:34:46Z

Abhutan: /* After changes */

=E810 Regularize staggered-deadline assignments=
This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
}
end
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end
===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

[b]Before Changes to code
The add_signup_topics , made a call to load_add_signup_topics method followed by a check for staggered assignments and calculation of due
dates for separate topics in this Staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

[b] After Changes to Code
The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)

if !@topics.nil?
i=0
@topics.each { |topic|
.......
i = i + 1
}
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

if self.staggered_deadline?
next_due_date = find_next_due_date(topic_id,self.id)
else
next_due_date = find_next_due_date(self.id)
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

= Additional Learning and Future Work=

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:34:23Z

Abhutan: /* Case 3 : Modularize Code in application.rb */

=E810 Regularize staggered-deadline assignments=
This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Languages and Systems coursework.

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

Expertiza is supported by National Science Foundation under Grant No. 0536558. Additional funding from the NCSU Learning in a Technology-Rich Environment (LITRE) program, the NCSU Faculty Center for Teaching and Learning, the NCSU STEM Initiative, and the Center for Advanced Computing and Communication.

= Problem Statement =
According to the existing code flow, Assignment deadlines belonged to two categories i.e. Staggered Deadlines and Deadlines (Normal Due Date). If an Assignment has different topics which have dependencies i.e. if Assignment A has two topics Topic A and Topic B , where Topic A can have deadline before Topic B, and therefore the Due Date of Assignment A is dependent on deadlines of Topics designed in that particular assignment. Hence these deadlines are called Staggered Deadlines.
On the other hand, If Assignment A has Topic A and Topic B, but they all have the same deadlines i.e. there is no dependency on each other then that's Normal Due Date scenario. In this case an Assignment may or may not have separate Topics.

Original code had various check statements for staggered and normal deadlines, which had to eliminated and structured in a way that with minimum checks we could distinguish between Staggered and Normal Due Dates. This required refactoring and restructuring of the whole functionality where we reduce these checks by distributing code into separate actions.

= Re-factored Code Cases =

== Case 1 : Refactoring in sign_up_sheet_controller.rb ==

===Current Scenario===
Different method definitions for setting up staggered and non-staggered assignment sign up sheet.

method:add_signup_topics_staggered 
This method lists all the available topics for an assignment and allows admin to set due dates for assignment.Staggered means that different topics can have different deadlines.
def add_signup_topics_staggered
load_add_signup_topics(params[:id])
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
}
end
end

method:add_signup_topics 
It is similar to the above function except that all the topics and review/submission rounds have the similar deadlines.
def add_signup_topics
load_add_signup_topics(params[:id])
end

Conditional call 
def redirect_to_sign_up(assignment_id)
assignment = Assignment.find(assignment_id)
if assignment.staggered_deadline == true
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
else
redirect_to :action => 'add_signup_topics', :id => assignment_id
end
end
===After Changes===
We have redundant code in two methods so we merged add_signup_topics_staggered and add_signup_topics into add_signup_topics. The action calls single method for both type of assignments and renders views based on condition of staggered or non-staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

Single method call 
At several places in the project, there was separate method call based on staggered and non-staggered assignments. Now there is a single method call and condition check in various files for type of assignment has been removed as part of re-factoring.

== Case 2 : Method Extraction ==

Improved Readability by extracting two separate functionalities from the same method into separate methods with appropriate naming convention and responsibilities.

[b]Before Changes to code
The add_signup_topics , made a call to load_add_signup_topics method followed by a check for staggered assignments and calculation of due
dates for separate topics in this Staggered assignment.

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#below functionality finds allows to set due dates for topics of assignment
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
if !@topics.nil?
i=0
@topics.each { |topic|
......
i = i + 1
end

#Render a view different for staggered deadlines assignment from the add_sign_up.html.erb
render "add_signup_topics_staggered"
end
end

[b] After Changes to Code
The logic to calculate due_dates was moved to a separate method called assignment_due_date , as this is only valid for staggered assignments
and hence it should be placed in a different method instead of merging it the add_signup_topics

def add_signup_topics
load_add_signup_topics(params[:id])
if @assignment.staggered_deadline ==true
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_all_by_assignment_id(params[:id])

#Function call to set up due dates
assignment_due_date

#Render a view different from the add_sign_up.html.erb , so rendering a view for staggered deadlines.
render "add_signup_topics_staggered"
end
end

def assignment_due_date
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)

if !@topics.nil?
i=0
@topics.each { |topic|
.......
i = i + 1
}
end
end

==Case 3 : Modularize Code in application.rb==
===Current Scenario===
In the assignment.rb model, there exists one method(check_condition) which checks whether review, meta-review, etc are allowed or not. This method makes database calls to TopicDeadline table, DueDate and DeadlineType tables. Following is the code which was existing before the changes were made. It has the logic to find the nearest due date that hasn't passed.

drop_topic_deadline_id = DeadlineType.find_by_name('drop_topic').id
if self.staggered_deadline?

if topic_id

next_due_date = TopicDeadline.find(:first, :conditions => ['topic_id = ? and due_at >= ? and deadline_type_id <> ?',
topic_id, Time.now, drop_topic_deadline_id], :order => 'due_at')
else

next_due_date = TopicDeadline.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :joins => {:topic => :assignment}, :order => 'due_at')
end
else
next_due_date = DueDate.find(:first, :conditions => ['assignment_id = ? and due_at >= ? and deadline_type_id <> ?',
self.id, Time.now, drop_topic_deadline_id], :order => 'due_at')
end

===After changes===
The database queries have been moved to their respective models. The queries to TopicDeadline table, DueDate table and DeadlineType table have been moved to their models. Below is the code in assignments.rb model which calls TopicDeadline.rb, DueDate.rb and DeadlineType.rb respectively for the queries in their tables:

if self.staggered_deadline?
next_due_date = find_next_due_date(topic_id,self.id)
else
next_due_date = find_next_due_date(self.id)
end

== Case 4 : DeadCode Elimination in sign_up_sheet_controller.rb ==

= Additional Learning and Future Work=

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:26:13Z

Abhutan: /* Case 3 : Modularize Code in application.rb */

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:25:34Z

Abhutan: /* Case 3 : Modularize Code in application.rb */

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:25:05Z

Abhutan: /* Case 3 : Modularize Code in application.rb */

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:24:26Z

Abhutan: /* Case 3 : Modularize Code in application.rb */

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:23:36Z

Abhutan: /* Case 3 : Modularize Code in application.rb */

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:20:40Z

Abhutan: /* Case 3 : Modularize Code in application.rb */

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T01:16:13Z

Abhutan: /* Case 3 : Modularize Code in application.rb */

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T00:22:32Z

Abhutan: /* Introduction to Expertiza */

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T00:16:40Z

Abhutan: /* Introduction to Expertiza */

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-31T00:11:34Z

Abhutan: /* Introduction to Expertiza */

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-30T23:55:38Z

Abhutan: /* Additional Learning and Future Work = */

CSC/ECE 517 Fall 2013/oss E810 aas

2013-10-30T23:06:27Z

Abhutan: Created page with "=E810 Regularize staggered-deadline assignments= This page provides a description of the OSS project conducted on Expertiza which was done as the part of the Object Oriented Lang..."

CSC/ECE 517 Fall 2013

2013-10-30T23:04:33Z

Abhutan:

* [[ CSC/ECE 517 Fall 2012/ch1 1w23 ph ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w30 nn]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w21 w]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w01 aj]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w24 nv]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w29 rkld]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w25 aras]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w30 ps]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w19 rj]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w18 bs]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w17 pk]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w22 ss]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w12 vn]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w14 st]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w08 cc]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w10 ga ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w26 as ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w27 ma ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w13 aa ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w11 sv ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w07 d ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w20 gq ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w03 ss ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w28 nm ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w02 pp ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w6 zs ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w04 y ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w05 st ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w09 hs ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w32 av ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w48 x ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w43 av]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w46 ka]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w33 aa]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w35 sa ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w39 as ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w31 vm ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w43 sm ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w44 s ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w47 ka ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w34 fs ]]
* [[ CSC/ECE 517 Fall 2013/ch1 1w40 ao ]]
* [[ CSC/ECE 517 Fall 2013/oss fmv ]]
* [[ CSC/ECE 517 Fall 2013/oss vna ]]
* [[ CSC/ECE 517 Fall 2013/oss paa ]]
* [[ CSC/ECE 517 Fall 2013/oss mapFeeds ]]
* [[ CSC/ECE 517 Fall 2013/oss ssp ]]
* [[ CSC/ECE 517 Fall 2013/ch2 0e808 nsv ]]
* [[ CSC/ECE 517 Fall 2013/oss aoa ]]
* [[ CSC/ECE 517 Fall 2013/oss cmh ]]
* [[ CSC/ECE 517 Fall 2013/oss ans ]]
* [[ CSC/ECE 517 Fall 2013/oss ssv]]
* [[ CSC/ECE 517 Fall 2013/oss E818 mra ]]
* [[ CSC/ECE 517 Fall 2013/oss SocialMediaFeeds ]]
* [[ CSC/ECE 517 Fall 2013/oss E811 syn ]]
* [[ CSC/ECE 517 Fall 2013/oss E804 spb ]]
* [[ CSC/ECE 517 Fall 2013/oss E812 amp ]]
* [[ CSC/ECE 517 Fall 2013/oss S805 ahs ]]
* [[ CSC/ECE 517 Fall 2013/oss E820 gzs ]]
* [[ CSC/ECE 517 Fall 2013/oss E816 cyy ]]
* [[ CSC/ECE 517 Fall 2013/oss M801 as ]]
* [[ CSC/ECE 517 Fall 2013/oss E814 vd ]]
* [[ CSC/ECE 517 Fall 2013/oss E815 saa]]
* [[ CSC/ECE 517 Fall 2013/oss E810 aas ]]

CSC/ECE 517 Fall 2013/oss E810 tr

2013-10-30T21:17:38Z

Abhutan: /* E818 Refactoring and testing -- analytics */

CSC/ECE 517 Fall 2013/oss E810 tr

2013-10-30T19:59:45Z

Abhutan: Wiki page for OSS assignment 2a

=E818 Refactoring and testing -- analytics=
This Wiki page provides a detailed description of the Open Source Software project conducted on Expertiza, as part of the Object Oriented Languages and Systems coursework.

=Introduction to Expertiza=
[http://expertiza.ncsu.edu/ Expertiza] is an open source project built using the Ruby on Rails platform. It is a web application where students can submit and peer-review learning objects (articles, code, web sites, etc). It is used in select courses at NC State and by professors at several other colleges and universities to manage peer reviews in coursework. The source code can be forked from [https://github.com/expertiza/expertiza github] and cloned for performing modifications. The Expertiza environment is already set up in NC State's VCL image "Ruby on Rails". If you have access, this is quickest way to get a development environment running for Expertiza. See the Expertiza wiki(provide hyperlink) on developing Expertiza on the VCL.

CSC/ECE 517 Fall 2013

2013-10-30T19:57:51Z

Abhutan: Wiki Link for team Rails E810 staggered deadline

CSC/ECE 517 Fall 2013/ch1 1w01 aj

2013-10-02T03:09:57Z

Abhutan: /* IBM Rational ClearCase */

== Version Control Tools ==

Version control tools are the tools which manage the changes to documents, computer programs, large web sites, and other collections of information. It is a repository of code along with the history of the changes. All the change made to the source is tracked, along with the other details like who made the changes, why the changes were made and other comments. This concept is very important for large projects requiring collaborated development. Whether it is the history of this wiki page or large software development project like Facebook, the ability to track the changes, and to reverse changes when necessary can make all huge difference between a well-managed and controlled process and an uncontrolled ‘first come, first served’ system. It can be used to track the development lifecycle of a project in detail.

== Categories of version control tools ==

=== Distributed Model ===

[http://en.wikipedia.org/wiki/Peer-to-peer Peer-to-peer] approach is followed in distributed revision control system in which each person’s copy of codebase is the current version of his code. In this way, each developer has the copy of full code rather than a part of code on which that developer is working. This system then synchronizes the copies of each developer by exchanging patches which contain the sets of changes. In this way each developer gets the latest copy of the code portion that others are working on. This method, most of the times, does not use the central repository.
Major advantages of this system are:

• As the full code is available on the hard disk, most of the actions are very fast as the interaction with the remote server is not required.

• Committing new change sets can be done locally without anyone else seeing them. Once you have a group of change sets ready, you can push all of them at once.

• Except pushing and pulling, most of the actions can be performed without an internet connection.

Despite the above advantages, Distributed Version Control Tools pose some problems. As the copy of whole code is maintained at the local machine, it requires a huge amount of space in case the files cannot be compressed (binary files). Moreover, in case the project has a huge history of changes, it might require large amount of time to download the entire patches.

Few examples of such tools are Codeville, Fossil, LibreSource, Monotone, Veracity and Git.
Let us consider Git to explain the features of distributed model for version control tools.

==== Git ====
Git is a free and open source distributed version control system. Its highest priority is to provide the high speed to its users. It was initially designed and developed for Linux kernel in 2005. was originally designed as a low-level version control system engine on top of which others could write front ends. However, the core Git project has since become a complete version control system that is usable directly. As of today, Git is estimated to have captured 30% of the market.
Every Git working directory is a full-fledged repository with complete history and full version tracking capabilities, not dependent on network access or a central server.

[[File:Branching-Git.png]]
''(Image showing the concept of branching for Git)''

==== Design of Git ====
Git, like any other distributed version control system, has three main functionalities:

• Code storage

• Keeping track of the changes made to the code

• Synchronizing all the developers for the latest code

===== Code Storage =====

Blob is the basic storage in Git. Git stores the contents of the file for tracking history, and not just the differences between individual files for each change. The contents are then referenced by a 40 character [http://en.wikipedia.org/wiki/SHA-1 SHA1 hash]. Pretty much every object, be it a commit, tree, or blob has a SHA.

This gives an added advantage that if two or more copies of the same file are stored in the repository, Git will store only one file internally.

The next level object is a tree. These can be thought of as folders or directories. Finally, this brings us to the most important object: the commit. Commits can be thought of as snapshots. The major difference between Git and any other tool is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. Tools consider the information they keep as a set of files and the changes made to each file over time.

[[File:Data_storage_git.png]]
''(Image showing data storage in case of normal control system)''
In contrast, Git thinks of its data more like a set of snapshots of a mini file system.
Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.

Git stores data as:

[[File:Git_commit.png‎]]
''(Image showing data storage in case of Git)''

This is an important difference between Git and all other tools. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation.

===== Tracking the changes made to the code =====
Git uses directed acyclic graph to store its history. Each commit in Git can have multiple or single parent commits. This info about the ancestors is stored with each commit. Here we can have nonlinear history. That means a commit can have multiple parent commits on which the child commit depends. Below example shows 3-way merge that has 3 parents:

[[File:Git_Tree.png‎]]

The history of a file is linked all the way up its directory structure to the root directory, which is then linked to a commit node. This commit node, in turn, can have one or more parents. When merging multiple branches we are merging the contents in a DAG. This allows Git to determine common ancestors.

===== Synchronizing all the developers for the latest code =====

In Git, when a developer makes the same modification to the equivalent file in the local Git code, the change will be recorded locally first, then they can "push" the commits to the other users who are working on the same project. The content changes are stored identically for each Git repository that the commit exists in.
Upon the local commit, the local Git repository will create a new object representing a file for the changed file. For each directory above the changed file, a new tree object is created with a new identifier. A DAG is created starting from the newly created root tree object pointing to the files and referencing the newly created blob in place of that file's previous blob object in the previous tree hierarchy.
At this point the commit is still local to the current Git code on developer’s local device. When he "pushes" the commit to a publicly accessible Git repository this commit gets sent to that repository. After the public repository verifies that the commit can apply to the branch, the same objects are stored in the public repository as were originally created in the local Git repository.

==== Tools available for Git ====

Git provides many command line and UI tools for most of the platforms. All these tools are based on Git core toolkit.
Git toolkit is divided into 2 parts: plumbing and porcelain. Plumbing contains two level commands that enable basic content tracking and modification of directed acyclic graphs. Procelain contains the more commonly used commands which are used to maintain repositories and communicating with other developers. Work is in progress for improving the toolkit design and making it faster.

===== Some of the major characteristics of Git: =====
===== Good support for expansion =====
Git is extremely fast and scalable. Referring to a local copy of code instead of the copy on remote server is very fast. As the project size increases, the affect of size on performance is very less.

===== Distributed development =====
Each developer is provided with the local copy of the entire development history. Changes are copied from one of the repository to another. These changes are transferred and can integrate the same way the local branches of the repository.

===== Backward compatibility =====
Repositories can be published by HTTP, FTP, rsync, or a Git protocol over either a plain socket, ssh or HTTP. Git also has a CVS server emulation, which enables the use of existing CVS clients and IDE plugins to access Git repositories.

===== Non-linear development =====
Git provides quick branching and merging. A branch in git is only a reference to a single commit. It supports non-linear development through various tools.

===== Support for incomplete merge =====
In case of an incomplete merge, Git provides multiple algorithms for letting the user know of this situation and also provides support for manual editing.

===== Cryptographic authentication of history =====
Git stores the history so that the id of a particular version depends upon the history of changes resulting into that commit. Once it is published, it is not possible to change the old versions without it being noticed.

Some of the major companies using Git in their projects include Google, Facebook, Microsoft(ASP.NET), Twitter, Eclipse and Netflix.

'''Some of the other major tools in this category are given below'''

==== GNU Bazaar ====
[http://en.wikipedia.org/wiki/GNU_Bazaar GNU Bazaar] (formerly Bazaar-NG, command line tool bzr) is a distributed revision control system sponsored by Canonical.
Bazaar can be used by a single developer working on multiple branches of local content, or by teams collaborating across a network.
Bazaar is written in the Python programming language, with packages for major GNU/Linux distributions, Mac OS X and Microsoft Windows.

==== Mercurial ====
[http://mercurial.selenic.com/ Mercurial] is a cross-platform, distributed revision control tool for software developers. It is mainly implemented using the Python programming language, but includes a binary diff implementation written in C. It is supported on Windows and Unix-like systems, such as FreeBSD, Mac OS X andLinux. Mercurial is primarily a command line program but graphical user interface extensions are available. All of Mercurial's operations are invoked as arguments to its driver program hg, a reference to the chemical symbol of the element mercury.

==== Bitkeeper ====
[http://www.bitkeeper.com/ BitKeeper] is a software tool for distributed revision control (configuration management, SCM, etc.) of computer source code. A distributed system, BitKeeper competes largely against other systems such as Git and Mercurial. BitKeeper is produced by BitMover Inc., a privately held company based in Campbell, California[2] and owned by CEO Larry McVoy, who had previously designed TeamWare.

BitKeeper builds upon many of the TeamWare concepts. Its key selling point is the fact that it is a distributed version control tool, as opposed to CVSor SVN. One of the defining characteristics of any distributed version control tool is the ease with which distributed development teams can keep their own local source repositories and still work with the central repository. Its web site claims that "BitKeeper has been shown to double the pace of software development".

=== Client Server Model ===
Centralized or client-server version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Most modern version control systems deal with “changesets,” which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. For example: a change to a C header file and the corresponding .c file should always be kept together.

==== Major Advantages of Centralized Version Control over Distributed Version Control ====
If the project contains many large, binary files that cannot be easily compressed, the space needed to store all versions of these files can accumulate quickly.

If the project has a very long history (50,000 changesets or more), downloading the entire history can take an impractical amount of time and disk space.

==== Perforce ====
Perforce is an enterprise version control and management system which uses centralized Version Control System. Dedicated Perforce applications are used to sync files between the file repository and individual users' workstations.
Perforce supports both Git clients and clients that use Perforce's own protocol. A Git client can communicate with the Perforce server over SSH, and other Perforce clients communicate with the server via TCP/IP using a proprietary RPC and streaming protocol.

[[File:perf1.jpg]]

===== The Perforce Versioning Service =====
The Perforce versioning service manages shared file repositories called depots. Depots contains all revisions of all file under Perforce control. Perforce organizes all the files in depots into directory trees, like a hard drive. Files in a depot are referred to as depot files or versioned files. Files are identified by namespace (i.e., by OS-neutral filenames). File content itself is not stored in the database. MD5 hashes of file content are stored in the database. Text file revisions are stored as RCS deltas and binary file revisions are stored in their entirety.

　　The service maintains a database to track change logs, user permissions, and which users have which files checked out at any time. The
information stored in this database is referred to as metadata.

　　Database tables are stored as binary files. Checkpoints and journals are written as text files that can be compressed and taken out. A database that has been corrupted by hardware failure or other catastrophe can be recovered from the most recent journal and checkpoint. Administrators must plan for disaster recovery by configuring database journaling and setting up regular checkpoints.

[[File:perf2.jpg]]

===== Perforce applications (clients) =====
Dedicated Perforce applications communicate with the versioning service to enable the checking in and out, conflict management, branch development, bug tracking request changing and more. They include:

　　• P4, the Perforce Command-Line Client, for all platforms

　　• P4V, the Perforce Visual Client, for Mac OS X, UNIX, Linux, and Windows

　　• P4Web, the Perforce Web Client, a browser-based interface to Perforce

　　• Integrations, or plug-ins, that work with commercial IDEs and productivity software

　　
When the files are loaded into the workspace, the Perforce application requests the files from the central data repository. To optimize the network utilization, the service keeps track of which files you (and other users) have retrieved. Perforce applications do not require a persistent connection to the versioning service.

===== Connecting and Mapping files to the workspace =====
　　Perforce applications manages files in a certain location of the hard disk, called the workspace. More than one client workspace can co-exist, even on the same workstation.

　　To customize the location of depot files under the root workspace, users must map the files and directories on the shared versioning service to corresponding areas of local hard drive.
　　Workspace views:

　　• Determine which files in the depot needs to be in the workspace.

　　• Custom-map files in the depot to files in the workspace.

　　Client workspace views may consist multiple lines or mappings. Each line in the workspace view has a "depot side", designates a subset of files within the depot, and a "client side" that controls where the files specified on the depot side are located under the workspace root.

[[File:perf3.jpg]]

=====　What file types are supported? =====
　　Perforce file types include seven base file types.

　　• text files,

　　• binary files,

　　• native apple files on the Macintosh,

　　• Mac resource forks,

　　• symbolic links (symlinks),

　　• unicode (and utf16) files.

===== Working with files =====
The changelist is the fundamental unit of work. The basic file operations which are common to all VCS (such as editing, adding, deleting, rolling back changes, and file check in) are taken care in changelists.
A changelist consists file list, their revision numbers, the changes made, and a description that describes the work that has been performed.
Changelists serve two purposes:

　　• To logically organize the work by grouping related changes to files together,

　　• To ensure the work integrity by making sure that related changes to files are checked in together.

Perforce changelists are atomic change transactions; if a changelist affects three files, then the changes for all three files are committed to the depot, or none of the changes are. Even if the network connection between your Perforce client program and the Perforce server is interrupted during changelist submission, the entire submit fails. Each changelist is identified by a changelist number (generated by Perforce), and a description (supplied by the user).

[[File:perf4.jpg]]

===== Working concurrently =====
　　Perforce helps teams to work concurrently. The conflict resolution and three-way merge process enables multiple users to work on the same files at the same time without interfering with each other's work.

　　The three-way merge process for resolving file conflicts helps you to resolve conflicting changes to text files, but is not necessarily meaningful for binary files such as graphics or compiled code. If the user is working on files where merges are not meaningful, locking such files is an option to prevent others from making changes that conflict.

　　Perforce supports two types of file locking:

　　• To prevent inconsistencies in current file changes, lock the file. Other users can still check out the locked file, but are restricted to view only privileges.

　　• To prevent a file from being checked out by more than one user at a time, use the +l exclusive-open filetype modifier. Files that have the +l filetype modifier can only be opened by one user at a time. Your Perforce administrator can use a special table called the typemap table to automatically specify certain file types as exclusive-open.
　　
=====　Streams =====
　　Perforce streams are structured containers for the files that consist projects, codelines, and components. Streams confer the following benefits:

　　• Ensures a hierarchical approach to branching

　　• Provides an "out of the box" best-practice branching strategy

　　• Provide metadata about the branch hierarchy to the Perforce service

　　• Provide a standard approach to structuring code (stability and hierarchy)

　　• Automate the generation of client workspace views and branch views

　　• Offer a compelling and informative visualization of stream structure and status

　　• Enable you to organize and visualize (bodies of) code.

　　• Provide rules to make development easier.
　　
=====　Codeline Management =====
Codelines are inter-related files that grow together. To organize groups of related files by purpose, branches are created. To move changes between branches, changelists are integrated. To create a snapshot of files in a specific phase, labels can be used.
　　
=====　Branching =====
　　Branching is a method of managing changes between two or more sets of files. Perforce's Inter-File Branching mechanism enables copying of any set of files to a new location in the depot by allowing changes made to one set of files to be copied, or integrated, to the other. The new file set (or codeline) evolves separately from the original files, but changes in either codeline can be propagated to the other by means of integration. Almost all of the version control systems support some form of branching.

　　Merging is actually only one of three possible outcomes of an integration. The others are ignoring (aka "blocking") and copying (aka "promoting"). Merging is used to keep one set of files up to date with another. For example, a development branch may be kept up to date with its trunk through repeated merging. Ignoring disqualifies changes in one set of files from future integration into another. It is often used when a development branch must be up to date with, and yet divergent from, its trunk. Copying is typically used to promote the content of an up-to-date development branch into a trunk.

'''Some other tools in this category are given below'''

==== AccuRev ====
[http://www.accurev.com/ AccuRev] is a centralized version control system which uses a client/server model. Communication is performed via TCP/IP using a proprietary protocol. Servers function as team servers, continuous integration servers, or build servers. AccuRev is built around a stream-based architecture in which streams form a hierarchical structure of code changes where parent streams pass on certain properties to child streams. Developers make changes using command line functions, the Java GUI, the web interface, or one of the IDE plug-ins.

Characteristics:

• Streams and parallel development

• Private developer history

• Change packages

• Distributed development

• Automated merging

==== IBM Rational ClearCase ====
[http://www-03.ibm.com/software/products/us/en/clearcase/ The Rational ClearCase] family consists of several software tools for supporting software configuration management (SCM) of source code and other software development assets. It is developed by the Rational Software division of IBM. ClearCase forms the base for configuration management for many large and medium sized businesses and can handle projects with hundreds or thousands of developers.
A part of Rational ClearCase is revision control system, which is a feature for end users.

ClearCase supports two kinds of use models, UCM (Unified Change Management), and base ClearCase. UCM provides an out-of-the-box model while base ClearCase provides a basic infrastructure (upon which UCM is built). Both can be configured to support a wide variety of needs. UCM is part of RUP (Rational Unified Process) and therefore all process templates and roles can be used from RUP.

'''Features:'''

• Build auditing

• VOB (Versioned Object Base)

• Configuration Record

• Build Avoidance

• Unix/Windows Interoperability

• Integration With Other Products

• Space Saving

'''Weaknesses:'''

• Speed

• Sensitivity to network problems

=== Local Data Model ===
In the local-only approach, all developers must use the same computer system. These software often manage single files individually and are largely replaced or embedded within newer software. This data model is the grandfather of all the modern version control softwares. These are the very first softwares for version control that were implemented in the late 1970's. Technological and software advances have rendered these practically useless but certain legacy systems still use these due to the hardware and software limitations.

==== Source Code Control System (SCCS) ====
　　Source Code Control System (SCCS) is an early revision control system, geared toward program source code and other text files. It was originally developed in SNOBOL at Bell Labs in 1972 by Marc Rochkind for an IBM System/370 computer running OS/360 MVT. SCCS was the dominant version control system for Unix until the release of the Revision Control System (RCS)[dubious – discuss]. Today, SCCS is generally considered obsolete. However, its file format is still used internally by a few other revision control programs, including BitKeeper and TeamWare. The latter is a frontend to SCCS. Sablime has been developed from a modified version of SCCS but uses a history file format that is incompatible with SCCS. The SCCS file format uses a storage technique called interleaved deltas (or the weave). This storage technique is now considered by many revision control system developers as foundational to advanced merging and versioning techniques, such as the "Precise Codeville" ("pcdv") merge.
　　
==== Revision Control System (RCS) ====
The Revision Control System (RCS) is a software implementation of revision control that automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, for example programs, documentation, procedural graphics, papers, and form letters. RCS is also capable of handling binary files, though with reduced efficiency. Revisions are stored with the aid of the diff utility.

This came into existency in 1982 and gave the version control systems a new dimension. It was the best VCS for the single user system, where all the files related to a project are in a single system. RCS just locks a single file that is being used and doesn't lock the entire project which is computationally cheaper.

== References ==

1. [http://www.oss-watch.ac.uk/resources/versioncontrol Version Control Tools]

2. [http://www.mediamosa.org/content/source-code DVS]

3. [http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Distributed Version Control]

4. [http://git-scm.com/ Git]

5. [http://gitready.com/beginner/2009/02/17/how-git-stores-your-data.html GitReady]

6. [https://wiki.archlinux.org/index.php/Git‎ Archlinux]

7. [http://stackoverflow.com/questions/8198105/how-git-stores-files StackOverflow]

8. [http://en.wikipedia.org Wikipedia]

9. [http://www.perforce.com/perforce/doc.current/manuals/p4v-gs/p4v-gs.pdf Perforce documentation and manuals ‎]

CSC/ECE 517 Fall 2013/ch1 1w01 aj

2013-10-02T03:09:25Z

Abhutan: /* AccuRev */

== Version Control Tools ==

Version control tools are the tools which manage the changes to documents, computer programs, large web sites, and other collections of information. It is a repository of code along with the history of the changes. All the change made to the source is tracked, along with the other details like who made the changes, why the changes were made and other comments. This concept is very important for large projects requiring collaborated development. Whether it is the history of this wiki page or large software development project like Facebook, the ability to track the changes, and to reverse changes when necessary can make all huge difference between a well-managed and controlled process and an uncontrolled ‘first come, first served’ system. It can be used to track the development lifecycle of a project in detail.

== Categories of version control tools ==

=== Distributed Model ===

[http://en.wikipedia.org/wiki/Peer-to-peer Peer-to-peer] approach is followed in distributed revision control system in which each person’s copy of codebase is the current version of his code. In this way, each developer has the copy of full code rather than a part of code on which that developer is working. This system then synchronizes the copies of each developer by exchanging patches which contain the sets of changes. In this way each developer gets the latest copy of the code portion that others are working on. This method, most of the times, does not use the central repository.
Major advantages of this system are:

• As the full code is available on the hard disk, most of the actions are very fast as the interaction with the remote server is not required.

• Committing new change sets can be done locally without anyone else seeing them. Once you have a group of change sets ready, you can push all of them at once.

• Except pushing and pulling, most of the actions can be performed without an internet connection.

Despite the above advantages, Distributed Version Control Tools pose some problems. As the copy of whole code is maintained at the local machine, it requires a huge amount of space in case the files cannot be compressed (binary files). Moreover, in case the project has a huge history of changes, it might require large amount of time to download the entire patches.

Few examples of such tools are Codeville, Fossil, LibreSource, Monotone, Veracity and Git.
Let us consider Git to explain the features of distributed model for version control tools.

==== Git ====
Git is a free and open source distributed version control system. Its highest priority is to provide the high speed to its users. It was initially designed and developed for Linux kernel in 2005. was originally designed as a low-level version control system engine on top of which others could write front ends. However, the core Git project has since become a complete version control system that is usable directly. As of today, Git is estimated to have captured 30% of the market.
Every Git working directory is a full-fledged repository with complete history and full version tracking capabilities, not dependent on network access or a central server.

[[File:Branching-Git.png]]
''(Image showing the concept of branching for Git)''

==== Design of Git ====
Git, like any other distributed version control system, has three main functionalities:

• Code storage

• Keeping track of the changes made to the code

• Synchronizing all the developers for the latest code

===== Code Storage =====

Blob is the basic storage in Git. Git stores the contents of the file for tracking history, and not just the differences between individual files for each change. The contents are then referenced by a 40 character [http://en.wikipedia.org/wiki/SHA-1 SHA1 hash]. Pretty much every object, be it a commit, tree, or blob has a SHA.

This gives an added advantage that if two or more copies of the same file are stored in the repository, Git will store only one file internally.

The next level object is a tree. These can be thought of as folders or directories. Finally, this brings us to the most important object: the commit. Commits can be thought of as snapshots. The major difference between Git and any other tool is the way Git thinks about its data. Conceptually, most other systems store information as a list of file-based changes. Tools consider the information they keep as a set of files and the changes made to each file over time.

[[File:Data_storage_git.png]]
''(Image showing data storage in case of normal control system)''
In contrast, Git thinks of its data more like a set of snapshots of a mini file system.
Every time you commit, or save the state of your project in Git, it basically takes a picture of what all your files look like at that moment and stores a reference to that snapshot.

Git stores data as:

[[File:Git_commit.png‎]]
''(Image showing data storage in case of Git)''

This is an important difference between Git and all other tools. It makes Git reconsider almost every aspect of version control that most other systems copied from the previous generation.

===== Tracking the changes made to the code =====
Git uses directed acyclic graph to store its history. Each commit in Git can have multiple or single parent commits. This info about the ancestors is stored with each commit. Here we can have nonlinear history. That means a commit can have multiple parent commits on which the child commit depends. Below example shows 3-way merge that has 3 parents:

[[File:Git_Tree.png‎]]

The history of a file is linked all the way up its directory structure to the root directory, which is then linked to a commit node. This commit node, in turn, can have one or more parents. When merging multiple branches we are merging the contents in a DAG. This allows Git to determine common ancestors.

===== Synchronizing all the developers for the latest code =====

In Git, when a developer makes the same modification to the equivalent file in the local Git code, the change will be recorded locally first, then they can "push" the commits to the other users who are working on the same project. The content changes are stored identically for each Git repository that the commit exists in.
Upon the local commit, the local Git repository will create a new object representing a file for the changed file. For each directory above the changed file, a new tree object is created with a new identifier. A DAG is created starting from the newly created root tree object pointing to the files and referencing the newly created blob in place of that file's previous blob object in the previous tree hierarchy.
At this point the commit is still local to the current Git code on developer’s local device. When he "pushes" the commit to a publicly accessible Git repository this commit gets sent to that repository. After the public repository verifies that the commit can apply to the branch, the same objects are stored in the public repository as were originally created in the local Git repository.

==== Tools available for Git ====

Git provides many command line and UI tools for most of the platforms. All these tools are based on Git core toolkit.
Git toolkit is divided into 2 parts: plumbing and porcelain. Plumbing contains two level commands that enable basic content tracking and modification of directed acyclic graphs. Procelain contains the more commonly used commands which are used to maintain repositories and communicating with other developers. Work is in progress for improving the toolkit design and making it faster.

===== Some of the major characteristics of Git: =====
===== Good support for expansion =====
Git is extremely fast and scalable. Referring to a local copy of code instead of the copy on remote server is very fast. As the project size increases, the affect of size on performance is very less.

===== Distributed development =====
Each developer is provided with the local copy of the entire development history. Changes are copied from one of the repository to another. These changes are transferred and can integrate the same way the local branches of the repository.

===== Backward compatibility =====
Repositories can be published by HTTP, FTP, rsync, or a Git protocol over either a plain socket, ssh or HTTP. Git also has a CVS server emulation, which enables the use of existing CVS clients and IDE plugins to access Git repositories.

===== Non-linear development =====
Git provides quick branching and merging. A branch in git is only a reference to a single commit. It supports non-linear development through various tools.

===== Support for incomplete merge =====
In case of an incomplete merge, Git provides multiple algorithms for letting the user know of this situation and also provides support for manual editing.

===== Cryptographic authentication of history =====
Git stores the history so that the id of a particular version depends upon the history of changes resulting into that commit. Once it is published, it is not possible to change the old versions without it being noticed.

Some of the major companies using Git in their projects include Google, Facebook, Microsoft(ASP.NET), Twitter, Eclipse and Netflix.

'''Some of the other major tools in this category are given below'''

==== GNU Bazaar ====
[http://en.wikipedia.org/wiki/GNU_Bazaar GNU Bazaar] (formerly Bazaar-NG, command line tool bzr) is a distributed revision control system sponsored by Canonical.
Bazaar can be used by a single developer working on multiple branches of local content, or by teams collaborating across a network.
Bazaar is written in the Python programming language, with packages for major GNU/Linux distributions, Mac OS X and Microsoft Windows.

==== Mercurial ====
[http://mercurial.selenic.com/ Mercurial] is a cross-platform, distributed revision control tool for software developers. It is mainly implemented using the Python programming language, but includes a binary diff implementation written in C. It is supported on Windows and Unix-like systems, such as FreeBSD, Mac OS X andLinux. Mercurial is primarily a command line program but graphical user interface extensions are available. All of Mercurial's operations are invoked as arguments to its driver program hg, a reference to the chemical symbol of the element mercury.

==== Bitkeeper ====
[http://www.bitkeeper.com/ BitKeeper] is a software tool for distributed revision control (configuration management, SCM, etc.) of computer source code. A distributed system, BitKeeper competes largely against other systems such as Git and Mercurial. BitKeeper is produced by BitMover Inc., a privately held company based in Campbell, California[2] and owned by CEO Larry McVoy, who had previously designed TeamWare.

BitKeeper builds upon many of the TeamWare concepts. Its key selling point is the fact that it is a distributed version control tool, as opposed to CVSor SVN. One of the defining characteristics of any distributed version control tool is the ease with which distributed development teams can keep their own local source repositories and still work with the central repository. Its web site claims that "BitKeeper has been shown to double the pace of software development".

=== Client Server Model ===
Centralized or client-server version control systems are based on the idea that there is a single “central” copy of your project somewhere (probably on a server), and programmers will “commit” their changes to this central copy.

“Committing” a change simply means recording the change in the central system. Other programmers can then see this change. They can also pull down the change, and the version control tool will automatically update the contents of any files that were changed.

Most modern version control systems deal with “changesets,” which simply are a groups of changes (possibly to many files) that should be treated as a cohesive whole. For example: a change to a C header file and the corresponding .c file should always be kept together.

==== Major Advantages of Centralized Version Control over Distributed Version Control ====
If the project contains many large, binary files that cannot be easily compressed, the space needed to store all versions of these files can accumulate quickly.

If the project has a very long history (50,000 changesets or more), downloading the entire history can take an impractical amount of time and disk space.

==== Perforce ====
Perforce is an enterprise version control and management system which uses centralized Version Control System. Dedicated Perforce applications are used to sync files between the file repository and individual users' workstations.
Perforce supports both Git clients and clients that use Perforce's own protocol. A Git client can communicate with the Perforce server over SSH, and other Perforce clients communicate with the server via TCP/IP using a proprietary RPC and streaming protocol.

[[File:perf1.jpg]]

===== The Perforce Versioning Service =====
The Perforce versioning service manages shared file repositories called depots. Depots contains all revisions of all file under Perforce control. Perforce organizes all the files in depots into directory trees, like a hard drive. Files in a depot are referred to as depot files or versioned files. Files are identified by namespace (i.e., by OS-neutral filenames). File content itself is not stored in the database. MD5 hashes of file content are stored in the database. Text file revisions are stored as RCS deltas and binary file revisions are stored in their entirety.

　　The service maintains a database to track change logs, user permissions, and which users have which files checked out at any time. The
information stored in this database is referred to as metadata.

　　Database tables are stored as binary files. Checkpoints and journals are written as text files that can be compressed and taken out. A database that has been corrupted by hardware failure or other catastrophe can be recovered from the most recent journal and checkpoint. Administrators must plan for disaster recovery by configuring database journaling and setting up regular checkpoints.

[[File:perf2.jpg]]

===== Perforce applications (clients) =====
Dedicated Perforce applications communicate with the versioning service to enable the checking in and out, conflict management, branch development, bug tracking request changing and more. They include:

　　• P4, the Perforce Command-Line Client, for all platforms

　　• P4V, the Perforce Visual Client, for Mac OS X, UNIX, Linux, and Windows

　　• P4Web, the Perforce Web Client, a browser-based interface to Perforce

　　• Integrations, or plug-ins, that work with commercial IDEs and productivity software

　　
When the files are loaded into the workspace, the Perforce application requests the files from the central data repository. To optimize the network utilization, the service keeps track of which files you (and other users) have retrieved. Perforce applications do not require a persistent connection to the versioning service.

===== Connecting and Mapping files to the workspace =====
　　Perforce applications manages files in a certain location of the hard disk, called the workspace. More than one client workspace can co-exist, even on the same workstation.

　　To customize the location of depot files under the root workspace, users must map the files and directories on the shared versioning service to corresponding areas of local hard drive.
　　Workspace views:

　　• Determine which files in the depot needs to be in the workspace.

　　• Custom-map files in the depot to files in the workspace.

　　Client workspace views may consist multiple lines or mappings. Each line in the workspace view has a "depot side", designates a subset of files within the depot, and a "client side" that controls where the files specified on the depot side are located under the workspace root.

[[File:perf3.jpg]]

=====　What file types are supported? =====
　　Perforce file types include seven base file types.

　　• text files,

　　• binary files,

　　• native apple files on the Macintosh,

　　• Mac resource forks,

　　• symbolic links (symlinks),

　　• unicode (and utf16) files.

===== Working with files =====
The changelist is the fundamental unit of work. The basic file operations which are common to all VCS (such as editing, adding, deleting, rolling back changes, and file check in) are taken care in changelists.
A changelist consists file list, their revision numbers, the changes made, and a description that describes the work that has been performed.
Changelists serve two purposes:

　　• To logically organize the work by grouping related changes to files together,

　　• To ensure the work integrity by making sure that related changes to files are checked in together.

Perforce changelists are atomic change transactions; if a changelist affects three files, then the changes for all three files are committed to the depot, or none of the changes are. Even if the network connection between your Perforce client program and the Perforce server is interrupted during changelist submission, the entire submit fails. Each changelist is identified by a changelist number (generated by Perforce), and a description (supplied by the user).

[[File:perf4.jpg]]

===== Working concurrently =====
　　Perforce helps teams to work concurrently. The conflict resolution and three-way merge process enables multiple users to work on the same files at the same time without interfering with each other's work.

　　The three-way merge process for resolving file conflicts helps you to resolve conflicting changes to text files, but is not necessarily meaningful for binary files such as graphics or compiled code. If the user is working on files where merges are not meaningful, locking such files is an option to prevent others from making changes that conflict.

　　Perforce supports two types of file locking:

　　• To prevent inconsistencies in current file changes, lock the file. Other users can still check out the locked file, but are restricted to view only privileges.

　　• To prevent a file from being checked out by more than one user at a time, use the +l exclusive-open filetype modifier. Files that have the +l filetype modifier can only be opened by one user at a time. Your Perforce administrator can use a special table called the typemap table to automatically specify certain file types as exclusive-open.
　　
=====　Streams =====
　　Perforce streams are structured containers for the files that consist projects, codelines, and components. Streams confer the following benefits:

　　• Ensures a hierarchical approach to branching

　　• Provides an "out of the box" best-practice branching strategy

　　• Provide metadata about the branch hierarchy to the Perforce service

　　• Provide a standard approach to structuring code (stability and hierarchy)

　　• Automate the generation of client workspace views and branch views

　　• Offer a compelling and informative visualization of stream structure and status

　　• Enable you to organize and visualize (bodies of) code.

　　• Provide rules to make development easier.
　　
=====　Codeline Management =====
Codelines are inter-related files that grow together. To organize groups of related files by purpose, branches are created. To move changes between branches, changelists are integrated. To create a snapshot of files in a specific phase, labels can be used.
　　
=====　Branching =====
　　Branching is a method of managing changes between two or more sets of files. Perforce's Inter-File Branching mechanism enables copying of any set of files to a new location in the depot by allowing changes made to one set of files to be copied, or integrated, to the other. The new file set (or codeline) evolves separately from the original files, but changes in either codeline can be propagated to the other by means of integration. Almost all of the version control systems support some form of branching.

　　Merging is actually only one of three possible outcomes of an integration. The others are ignoring (aka "blocking") and copying (aka "promoting"). Merging is used to keep one set of files up to date with another. For example, a development branch may be kept up to date with its trunk through repeated merging. Ignoring disqualifies changes in one set of files from future integration into another. It is often used when a development branch must be up to date with, and yet divergent from, its trunk. Copying is typically used to promote the content of an up-to-date development branch into a trunk.

'''Some other tools in this category are given below'''

==== AccuRev ====
[http://www.accurev.com/ AccuRev] is a centralized version control system which uses a client/server model. Communication is performed via TCP/IP using a proprietary protocol. Servers function as team servers, continuous integration servers, or build servers. AccuRev is built around a stream-based architecture in which streams form a hierarchical structure of code changes where parent streams pass on certain properties to child streams. Developers make changes using command line functions, the Java GUI, the web interface, or one of the IDE plug-ins.

Characteristics:

• Streams and parallel development

• Private developer history

• Change packages

• Distributed development

• Automated merging

==== IBM Rational ClearCase ====
The Rational ClearCase family consists of several software tools for supporting software configuration management (SCM) of source code and other software development assets. It is developed by the Rational Software division of IBM. ClearCase forms the base for configuration management for many large and medium sized businesses and can handle projects with hundreds or thousands of developers.
A part of Rational ClearCase is revision control system, which is a feature for end users.

ClearCase supports two kinds of use models, UCM (Unified Change Management), and base ClearCase. UCM provides an out-of-the-box model while base ClearCase provides a basic infrastructure (upon which UCM is built). Both can be configured to support a wide variety of needs. UCM is part of RUP (Rational Unified Process) and therefore all process templates and roles can be used from RUP.

'''Features:'''

• Build auditing

• VOB (Versioned Object Base)

• Configuration Record

• Build Avoidance

• Unix/Windows Interoperability

• Integration With Other Products

• Space Saving

'''Weaknesses:'''

• Speed

• Sensitivity to network problems

=== Local Data Model ===
In the local-only approach, all developers must use the same computer system. These software often manage single files individually and are largely replaced or embedded within newer software. This data model is the grandfather of all the modern version control softwares. These are the very first softwares for version control that were implemented in the late 1970's. Technological and software advances have rendered these practically useless but certain legacy systems still use these due to the hardware and software limitations.

==== Source Code Control System (SCCS) ====
　　Source Code Control System (SCCS) is an early revision control system, geared toward program source code and other text files. It was originally developed in SNOBOL at Bell Labs in 1972 by Marc Rochkind for an IBM System/370 computer running OS/360 MVT. SCCS was the dominant version control system for Unix until the release of the Revision Control System (RCS)[dubious – discuss]. Today, SCCS is generally considered obsolete. However, its file format is still used internally by a few other revision control programs, including BitKeeper and TeamWare. The latter is a frontend to SCCS. Sablime has been developed from a modified version of SCCS but uses a history file format that is incompatible with SCCS. The SCCS file format uses a storage technique called interleaved deltas (or the weave). This storage technique is now considered by many revision control system developers as foundational to advanced merging and versioning techniques, such as the "Precise Codeville" ("pcdv") merge.
　　
==== Revision Control System (RCS) ====
The Revision Control System (RCS) is a software implementation of revision control that automates the storing, retrieval, logging, identification, and merging of revisions. RCS is useful for text that is revised frequently, for example programs, documentation, procedural graphics, papers, and form letters. RCS is also capable of handling binary files, though with reduced efficiency. Revisions are stored with the aid of the diff utility.

This came into existency in 1982 and gave the version control systems a new dimension. It was the best VCS for the single user system, where all the files related to a project are in a single system. RCS just locks a single file that is being used and doesn't lock the entire project which is computationally cheaper.

== References ==

1. [http://www.oss-watch.ac.uk/resources/versioncontrol Version Control Tools]

2. [http://www.mediamosa.org/content/source-code DVS]

3. [http://blogs.atlassian.com/2012/02/version-control-centralized-dvcs/ Distributed Version Control]

4. [http://git-scm.com/ Git]

5. [http://gitready.com/beginner/2009/02/17/how-git-stores-your-data.html GitReady]

6. [https://wiki.archlinux.org/index.php/Git‎ Archlinux]

7. [http://stackoverflow.com/questions/8198105/how-git-stores-files StackOverflow]

8. [http://en.wikipedia.org Wikipedia]

9. [http://www.perforce.com/perforce/doc.current/manuals/p4v-gs/p4v-gs.pdf Perforce documentation and manuals ‎]