Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2015 E1529 GLDS

2015-04-22T18:10:15Z

Jli53: /* Drop one-person topics */

E1529. Extend the Email notification feature to scheduled tasks 

=Overview=

==Introduction to Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities<ref>[https://github.com/expertiza/expertiza Expertiza Github]</ref>. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc). It is also a powerful tool for professor to manage courses and assignments and so on. The latest "Rails 4" branch of Expertiza, although combined with various enhancements from the past two years, is seriously broken, from data migration to key feature implementation. Part of the reason has been the design strategy and code changes by various teams.

==Email notification feature to scheduled tasks==
This is a feature that has already been partially implemented in Expertiza [https://github.com/expertiza/expertiza/pull/445 E1451] implemented both sychronous and asychoronous mailers. Sychronous Emails refer to the Emails sent immediatly after an event (e.g. when student receive a peer-review). Asychoronous Email we implemented by the Gem "delayed job” and when a task (asychronous Email) is added to the delayed queue, a count-down number of minutes needs to be specified. 

Our team aims to extend this project. This wiki page documents the problem analysis and provides a guideline for future development and enhancement.

__TOC__

=Scope=
==Project Scope==
E1451. Create Mailers for All Email Messages [https://github.com/expertiza/expertiza/pull/445 github] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/OSS_E1451_las wiki] [http://expertiza.ncsu.edu/submitted_content/download/28122?current_folder%5Bname%5D=%2Flocal%2Frails%2Fexpertiza%2Freleases%2F20140702225848%2Fpg_data%2Fefg%2Fcsc517%2Ff14%2F%2F18&download=E1451_Report.pdf report] (Merged in [https://docs.google.com/a/ncsu.edu/document/d/1aypHb5UOe-3nPfruNeh2HZjeT-wfv6f-ZsZg2jDMNkQ/edit E1483])

Extending this project, the new system should be capable of
*If one task is added to the delayed job queue, the asychronous Email should be updated or deleted automatically.
*Add UI to visualize for the task in delayed job queue, instructors should be able to view tasks related to the assignments they have created.
*Keep log of the scheduled tasks when they are scheduled and done, record events in the same log as project [https://github.com/expertiza/expertiza/pull/462 E1478].
*[optional] support more scheduled task:
**instructors are able to schedule the time to drop all the outstanding reviews (reviews which has not been started)
**instructors are able to schedule a specific time to send Emails to all the assignment participants who are still not in any team to find or form one.
**(new) instructor should be able to schedule a time to drop all the topics which are held by 1 person teams.
*create tests to make sure the test coverage increases.
==Files Involved==
Mailers:
*delayed_mailer.rb

Models:
*assignment_form.rb
*due_date.rb
*delayed_job.rb(new created)
*scheduled_task.rb(new created)

Views:
*_due_dates.html.erb
*_assignments_actions.html.erb
* scheduled_tasks.erb(new created)

Controllers:
*assignments_controller.rb

==Gems Related==
*gem 'delayed_job_active_record'

[https://github.com/collectiveidea/delayed_job Delayed:Job] encapsulates the common pattern of asynchronously executing longer tasks in the background<ref> [https://github.com/collectiveidea/delayed_job Delayed_job Gem]</ref>. It allows to support multiple backends for storing the job queue. By using 'delayed_job_active_record' gem, we can use delayed_job with Active Record. This Active Record backend requires a job table.

After running rails generate delayed_job:active_record and rake db:migrate, a "delayed_jobs" table is created in our database. This gem integrates well with many [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS] backend such as MySQL. Using this gem, we can store all scheduled tasks queue into the "delayed_jobs" table.

*gem 'paper_trail'
PaperTrail allows to track changes of models' data, which is good for versioning. You can see how a model looked at any stage in its lifecycle, revert it to any version, and even undelete it after it's been destroyed<ref>[https://github.com/airblade/paper_trail Paper_trail Gem]</ref>. Using this gem, we can keep log of the scheduled tasks.

=Problem Analysis=

== Time Issues==

Initially, when we want to verify the email function, we found many time issues in this system. That blocks our work about email notification. Some related problems are explained and analyzed in this section.

===Wrong displayed time===

Firstly, when we set a due time to test the mail features, we found the display of time is incorrect.

In the “Assignment Edit”->“Due dates”, when we modify the “Date & time” of the deadline, the displayed time will be 4 hours ahead of the time we saved. 

[[File:Wrong display of time.png‎ |frame|center|Set due time]]

[[File:Wrong display of time 2.png |frame|center|After we click the save button, we can see that all the time are 4 hours ahead of the set time]]

[[File:database_deadline.png |frame|center|The deadline time is stored correct in the database]]

After several tries, we found that every time when we click "save", the saved time is 4 hours earlier then the last saved time. However, the time in the database is alway correct as the time we save. After we analyze, we found the problem may lay in the line of 68 of <code>views/assignment/edit/_due_dates.html.erb</code> file.

<pre>due_at = new Date(due_at.substr(0, 16)).format('yyyy/mm/dd HH:MM');</pre>

When we declare a Data object, this Data() function will perform a time zone conversion automatically. Yet Rails’ default timezone stored in database is UTC. So the displayed time(local time, which is EDT) and time in database is different.

===Different time zone===

In the previous version, when current time is compared with the time stored in database, they may apply to different time zones so that the result of comparison may be wrong. 
When we delay a deadline of an assignment, for example, we set the deadline of metareview from2015/03/28 16:00 to 2015/04/04 20:00 and set the reminder hr to 16 hours.

[[File:Delayassign.png |frame|center|Delay a time]]

After click "save", the run time showed database is about 8:00 am. Since 20-16=4, the correct run time is 4:00 am.

[[File:delaydatabase.png |frame|center|Time Stored in Database]]

The reason why there is a four-hour time difference is generated from the file <code>application_form.rb</code>, method <code> find_min_from_now(due_at)</code>, and line 142 <code>time_in_min=((due_at - curr_time).to_i/60)</code>. <code> due_at </code> is the system time for Rails (UTC), while <code> curr_time </code> is the local time which is EDT. The two time zones have four-hour time difference. 

===New deadline replace the old one===
This time, we add a new delay in Review section, we delay the deadline from 2015/03/22 21:00 to 2015/03/30 21:00, and set the remind hr to 8 hours.

[[File:delayagain.png |frame|center|Delay a new deadline type]]

However, the delayed_jobs database form is still the same, which means in one assignment there is only one reminder can work. 
As a result, we conclude that only one due_time record associated with different period exists in the database:
*In Expertiza, one assignment has several period, such as submission, review, metareview. Administrates are able to set and postpone due dates for each period separately.
*In the previous version, when the instructor postpone the review deadline and then postpone the submit deadline, the submit deadline’s modification will replace the the review deadline’s modification in database.
*In this case, if both of them need Email reminder, there will be no Email about the former modified deadline.
*After our analysis, we found the due time object is identified with assignment_id, instead of deadline type id.

==UI issues==
In the previous version, there is no UI to display the reminders of assignments. There is no way for instructors to view or delete their delayed tasks related to an assignment. We are going to add a button under Assignment->edit, and add a view to display all delayed jobs derived from the delayed_jobs table in our database.

=System Design=
==Fix Time Issues==
===Unified time zone===
We convert current time to the same time zone as the deadline stored in database. Then the result of comparison will be right so that it can be used for further usage.
In <code>app/models/assignment_form.rb</code>, we modified <code>curr_time=DateTime.now.to_s(:db)</code> to <code>curr_time=DateTime.now.in_time_zone(zone='UTC').to_s(:db)</code> in the <code>find_min_from_now</code> method, to make sure when calculating the minutes from now, the time zone is right. 
Also, to make sure the right display of time, when log in as a administrator, go to Profile and choose the Preferred Time Zone to be "(GMT-05:00) Eastern Time (US&Canada)".

===Separate deadline of each topic period===
In each Assignment, each deadline type (E.g review, submit, metareview) should has its own Email reminder time in the database. New postponed deadline of one type can only replace the same deadline type in the same assignment id category. This bug has been fixed by TA.

==Add UI to visualize for scheduled tasks==
All the scheduled tasks are in the <code>delayed_jobs</code> table in database, so the system will read from that table to show all the tasks‘ information. A new page is created to show all of those scheduled tasks and there is also a delete button for instructor to delete any task. Instructor can view this page via a <code>view delayed jobs</code> button in <code> assignment->edit </code>. 
The code in <code>app/models/assignment_form.rb</code> add the scheduled tasks into <code>delayed_jobs</code> table. 
<pre>
if diff>0
dj=DelayedJob.enqueue(ScheduledTask.new(@assignment.id, deadline_type, due_date.due_at.to_s(:db)), 1, diff.minutes.from_now)
change_item_type(dj.id)
due_date.update_attribute(:delayed_job_id, dj.id)

# If the deadline type is review, add a delayed job to drop outstanding review
if deadline_type == "review"
dj = DelayedJob.enqueue(ScheduledTask.new(@assignment.id, "drop_outstanding_reviews", due_date.due_at.to_s(:db)), 1, diff.minutes.from_now)
change_item_type(dj.id)
end

# If the deadline type is team_formation, add a delayed job to drop one member team
if deadline_type == "team_formation"
dj = DelayedJob.enqueue(ScheduledTask.new(@assignment.id, "drop_one_member_topics", due_date.due_at.to_s(:db)), 1, diff.minutes.from_now)
change_item_type(dj.id)
end
end
</pre>
After adding to the delayed_jobs, the database will store each task's assignment's id, deadline type, due date, task run time etc. 

[[File:delayedjobs.png |frame|center|the delayed jobs table in database]] 
We create a file <code>scheduled_tasks.erb</code> in the path: <code>/views/assignments</code> to show the form. In this file, we use a <code>@scheduled_jobs = DelayedJob.all </code> to read all datas from the "delayed_jobs" table. 
<pre>
<% @assignment = Assignment.find(params[:id]) %>
<h1>Scheduled tasks for <%= @assignment.name %> assignment</h1>
<% if flash[:notice] %>
<div class="flash_note"><%= flash_message :notice %></div>
<% end %>
<% @scheduled_jobs = DelayedJob.all %>
<table class="general">
<th width="25%">Deadline type #</th>
<th width="25%">Run time</th>
<th width="25%">Due date</th>
<th width="25 %">Action</th>
<th width="25 %">Delete</th>
<% i=1 %>
<% for delayed_job in @scheduled_jobs %>
<tr>
<%if delayed_job.handler.include? "assignment_id: #{@assignment.id}"%>
<% handler = delayed_job.handler.split()%>
<td><%= handler[5] %></td>
<td><%= delayed_job.run_at %></td>
<td><%= handler[7][1..-1] + ":" + handler[8][0..-2]%></td>
<%if handler[5] == "submission" %>
<td><%= " "%></td>
<%end%>
<%if handler[5] == "review" %>
<td><%= " "%></td>
<%end%>
<%if handler[5] == "metareview" %>
<td><%= " "%></td>
<%end%>
<%if handler[5] == "team_formation" %>
<td><%= "send email to ask students to form teams"%></td>
<%end%>
<%if handler[5] == "drop_outstanding_reviews" %>
<td><%= "drop outstanding reviews and send emails to those students"%></td>
<%end%>
<%if handler[5] == "drop_one_member_topics" %>
<td><%= "drop one member team topics and send emails to those students"%></td>
<%end%>
<td><%= link_to image_tag('delete_icon.png', :title => 'Delete'),{:controller => 'assignments', :action => 'delete_scheduled_task',:id => @assignment.id, :delayed_job_id => delayed_job.id}%></td>
<% end %>
</tr>
<% i=i+1 %>
<% end %>
</table>
<% session[:return_to] = request.url %>
 
<a href="javascript:history.back()">Back</a>
</pre> 
The following two pictures show our UI works. 
[[File:viewdelayedjobs.png |frame|center|add a button to display all scheduled tasks]] 
[[File:showscheduledtask.png|frame|center|The UI to show all the scheduled tasks]] 

==Keep log of the scheduled tasks==
According to the project [https://github.com/expertiza/expertiza/pull/462 E1478], there is a paper_trail<ref name = "Paper_trail Gem"> https://github.com/airblade/paper_trail]</ref> gem which can keep log of the models' data. What we need to do is let it also keep track of our scheduled task data. 
Since the gem need to work with <code>ActiveRecord 3+</code>, while <code>assignment_form</code> doesn't. So we created a new file named <code>delayed_job.rb</code> in <code>models</code> folder, add <code>has_paper_trail</code> in it. Then it is like: 
<pre>
class DelayedJob < Delayed::Job
has_paper_trail
end
</pre>
When the <code>delayed_jobs</code> table changes, a <code>Delayed::Backend::ActiveRecord::Job</code> record is automatically created in the log. In <code>assignment_form.rb</code>, we define a method to change the item type displayed in the log.
<pre>
def change_item_type(delayed_job_id)
log = Version.where(item_type: "Delayed::Backend::ActiveRecord::Job", item_id: delayed_job_id).first
log.update_attribute(:item_type, "ScheduledTask") #Change the item type in the log
end
</pre>
Then we call it in <code>add_to_delayed_queue</code> method of the same file. Every time when the <code>delayed_jobs</code> table has added or deleted or updated data, the log can keep track of them. The following picture shows what the log is after creating scheduled tasks. You can see a "Search log" under the "logout" button. 
[[File:scheduledtasklog.png|frame|center|four scheduled tasks are added in log]] 

==support more schedule tasks==

In our system, we would have four scheduled time: submission, review, metareview and team_formation. When due time comes, the system takes corresponding actions. These scheduled actions are called scheduled tasks.

[[File:Support more scheduled tasks.png|frame|center|Support more scheduled tasks]]

===Drop outstanding reviews===
In this task, instructors should be able to schedule a time to drop all the outstanding reviews, which means the reviews which has not been started. 

Firstly, we create a new deadline type called "drop_outstanding_reviews". When we set the review’s due date, add an item into “delayed job” queue at the same time( refer to "Add UI to visualize for scheduled tasks").
When the review is due, it will automatically call a method to find all the outstanding reviews (reviews which have not been started) in the database then delete them. 
There are two tables in the database to store the information about the reviews: <code>responses</code> and <code>response_maps </code>. 
<code>responses</code> is used to store all the submitted reviews while <code>response_maps</code> stores all the requested reviews, which means if one review has began it will not stored in <code>responses</code> table. Thus, we just need to find the review data in <code>response_maps</code> while not in <code>responses</code> for one assignment and delete them in database. 
We add a method in <code>/models/scheduled_task.rb</code> named <code>drop_outstanding_reviews</code> to drop those reviews. 
<pre>
def drop_outstanding_reviews
reviews = ResponseMap.where(reviewed_object_id: self.assignment_id)
for review in reviews
review_has_began = Response.where(map_id: review.id)
if review_has_began.size.zero?
review_to_drop = ResponseMap.where(id: review.id)
review_to_drop.first.destroy
end
end
end
</pre>
Then, add the following code in <code>perform</code> method of the same file to drop one specified assignment's outstanding reviews at the due time. 
<pre>
if(self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
</pre>

===Send team formation Emails===
In this task, the instructors are able to schedule a specific time to send Emails to all the assignment participants who are still not in any team to find or form one.
We use a previously existed deadline type called "team_formation" and enable to set a team_formation's due date and a reminder under "Assignment->edit->due date". Then add an item into “delayed job” at the same time(refer to "Add UI to visualize for scheduled tasks"). When “delayed job” is triggered, it will automatically call a method to find all the assignment participants who are still not in any team in the database, and send Emails to them to find teammate.
<pre>
if(self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if(assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
</pre>

===Drop one-person topics===
In this task, the instructor should be able to schedule a time to drop all the topics which are held by 1 person teams.
We create a new deadline type called "drop_one_member_topics". When deadline type is team_formation, we add an item to the "delayed_job" queue( refer to "Add UI to visualize for scheduled tasks").
Then when time is due, the system will call a method to find all the topics which are held by 1 person teams in the database, then the professor can drop those topics.
<pre>
def drop_one_member_topics
teams = TeamsUser.all.group(:team_id).count(:team_id)
for team_id in teams.keys
if teams[team_id] == 1
topic_to_drop = SignedUpUser.where(creator_id: team_id).first
if topic_to_drop#check if the one-person-team has signed up a topic
topic_to_drop.delete
end
end
end
end
</pre>
<pre>
if(self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
if(assignment.team_assignment?)
drop_one_member_topics
end
end
</pre>

=Tests=
In this project, our jobs involve two gems as mentioned above. They are "Delayed Job", which can insert a job into queue and execute it at a certain time, and "Paper Trail", to log actions like create, update and destroy for a model. We write rspec tests to make sure that the functionality works well.
In "scheduled_task_spec.rb", we test the functionality that when a due date is created, then delayed jobs of certain deadline type will be created. We may take "team_formation" deadline as an example:
<pre>
describe 'Team formation deadline reminder email' do
it 'should send reminder email for team formation deadline to reviewers ' do
id = 2
@name = "user"
due_at = DateTime.now.advance(:minutes => +2)
due_at1 = Time.parse(due_at.to_s(:db))
curr_time=DateTime.now.to_s(:db)
curr_time=Time.parse(curr_time)
time_in_min=((due_at1 - curr_time).to_i/60) *60
Delayed::Job.delete_all
Delayed::Job.count.should == 0
dj = Delayed::Job.enqueue(ScheduledTask.new(id, "team_formation", due_at), 1, time_in_min)
Delayed::Job.count.should == 1
Delayed::Job.last.handler.should include("deadline_type: team_formation")
dj2 = Delayed::Job.enqueue(ScheduledTask.new(id, "drop_one_member_topics", due_at), 1, time_in_min)
Delayed::Job.count.should == 2
Delayed::Job.last.handler.should include("deadline_type: drop_one_member_topics")
end
end
</pre>
When team_formation deadline is created, there will be two delayed jobs created. One is reminder email and the other one is drop topics from students who don't have a team yet.
For the functionality of keeping log of scheduled tasks, "has_paper_trail_spec.rb" file is used to make sure that when a delayed job instance is created, one log will be generated.
<pre>
require 'rails_helper'
describe 'has_paper_trail' do
it "will create Version record when create delayed jobs record" do
PaperTrail.enabled =true
for version in Version.all
version.delete
end
Version.all.count.should == 0
@delayed_job = DelayedJob.new
@delayed_job.id = 1
@delayed_job.priority = 1
@delayed_job.attempts = 0
@delayed_job.save
Version.all.count.should == 1
end
end
</pre>

=References=
<references/>

CSC/ECE 517 Spring 2015 E1529 GLDS

2015-04-22T18:09:40Z

Jli53: /* Send team formation Emails */

CSC/ECE 517 Spring 2015 E1529 GLDS

2015-04-22T18:09:11Z

Jli53: /* Drop outstanding reviews */

CSC/ECE 517 Spring 2015 E1529 GLDS

2015-04-22T18:08:35Z

Jli53: /* Keep log of the scheduled tasks */

CSC/ECE 517 Spring 2015 E1529 GLDS

2015-04-22T18:08:11Z

Jli53: /* Add UI to visualize for scheduled tasks */

CSC/ECE 517 Spring 2015 E1529 GLDS

2015-04-22T18:06:39Z

Jli53: /* Add UI to visualize for scheduled tasks */

E1529. Extend the Email notification feature to scheduled tasks 

=Overview=

==Introduction to Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities<ref>[https://github.com/expertiza/expertiza Expertiza Github]</ref>. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc). It is also a powerful tool for professor to manage courses and assignments and so on. The latest "Rails 4" branch of Expertiza, although combined with various enhancements from the past two years, is seriously broken, from data migration to key feature implementation. Part of the reason has been the design strategy and code changes by various teams.

==Email notification feature to scheduled tasks==
This is a feature that has already been partially implemented in Expertiza [https://github.com/expertiza/expertiza/pull/445 E1451] implemented both sychronous and asychoronous mailers. Sychronous Emails refer to the Emails sent immediatly after an event (e.g. when student receive a peer-review). Asychoronous Email we implemented by the Gem "delayed job” and when a task (asychronous Email) is added to the delayed queue, a count-down number of minutes needs to be specified. 

Our team aims to extend this project. This wiki page documents the problem analysis and provides a guideline for future development and enhancement.

__TOC__

=Scope=
==Project Scope==
E1451. Create Mailers for All Email Messages [https://github.com/expertiza/expertiza/pull/445 github] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/OSS_E1451_las wiki] [http://expertiza.ncsu.edu/submitted_content/download/28122?current_folder%5Bname%5D=%2Flocal%2Frails%2Fexpertiza%2Freleases%2F20140702225848%2Fpg_data%2Fefg%2Fcsc517%2Ff14%2F%2F18&download=E1451_Report.pdf report] (Merged in [https://docs.google.com/a/ncsu.edu/document/d/1aypHb5UOe-3nPfruNeh2HZjeT-wfv6f-ZsZg2jDMNkQ/edit E1483])

Extending this project, the new system should be capable of
*If one task is added to the delayed job queue, the asychronous Email should be updated or deleted automatically.
*Add UI to visualize for the task in delayed job queue, instructors should be able to view tasks related to the assignments they have created.
*Keep log of the scheduled tasks when they are scheduled and done, record events in the same log as project [https://github.com/expertiza/expertiza/pull/462 E1478].
*[optional] support more scheduled task:
**instructors are able to schedule the time to drop all the outstanding reviews (reviews which has not been started)
**instructors are able to schedule a specific time to send Emails to all the assignment participants who are still not in any team to find or form one.
**(new) instructor should be able to schedule a time to drop all the topics which are held by 1 person teams.
*create tests to make sure the test coverage increases.
==Files Involved==
Mailers:
*delayed_mailer.rb

Models:
*assignment_form.rb
*due_date.rb
*delayed_job.rb(new created)
*scheduled_task.rb(new created)

Views:
*_due_dates.html.erb
*_assignments_actions.html.erb
* scheduled_tasks.erb(new created)

Controllers:
*assignments_controller.rb

==Gems Related==
*gem 'delayed_job_active_record'

[https://github.com/collectiveidea/delayed_job Delayed:Job] encapsulates the common pattern of asynchronously executing longer tasks in the background<ref> [https://github.com/collectiveidea/delayed_job Delayed_job Gem]</ref>. It allows to support multiple backends for storing the job queue. By using 'delayed_job_active_record' gem, we can use delayed_job with Active Record. This Active Record backend requires a job table.

After running rails generate delayed_job:active_record and rake db:migrate, a "delayed_jobs" table is created in our database. This gem integrates well with many [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS] backend such as MySQL. Using this gem, we can store all scheduled tasks queue into the "delayed_jobs" table.

*gem 'paper_trail'
PaperTrail allows to track changes of models' data, which is good for versioning. You can see how a model looked at any stage in its lifecycle, revert it to any version, and even undelete it after it's been destroyed<ref>[https://github.com/airblade/paper_trail Paper_trail Gem]</ref>. Using this gem, we can keep log of the scheduled tasks.

=Problem Analysis=

== Time Issues==

Initially, when we want to verify the email function, we found many time issues in this system. That blocks our work about email notification. Some related problems are explained and analyzed in this section.

===Wrong displayed time===

Firstly, when we set a due time to test the mail features, we found the display of time is incorrect.

In the “Assignment Edit”->“Due dates”, when we modify the “Date & time” of the deadline, the displayed time will be 4 hours ahead of the time we saved. 

[[File:Wrong display of time.png‎ |frame|center|Set due time]]

[[File:Wrong display of time 2.png |frame|center|After we click the save button, we can see that all the time are 4 hours ahead of the set time]]

[[File:database_deadline.png |frame|center|The deadline time is stored correct in the database]]

After several tries, we found that every time when we click "save", the saved time is 4 hours earlier then the last saved time. However, the time in the database is alway correct as the time we save. After we analyze, we found the problem may lay in the line of 68 of <code>views/assignment/edit/_due_dates.html.erb</code> file.

<pre>due_at = new Date(due_at.substr(0, 16)).format('yyyy/mm/dd HH:MM');</pre>

When we declare a Data object, this Data() function will perform a time zone conversion automatically. Yet Rails’ default timezone stored in database is UTC. So the displayed time(local time, which is EDT) and time in database is different.

===Different time zone===

In the previous version, when current time is compared with the time stored in database, they may apply to different time zones so that the result of comparison may be wrong. 
When we delay a deadline of an assignment, for example, we set the deadline of metareview from2015/03/28 16:00 to 2015/04/04 20:00 and set the reminder hr to 16 hours.

[[File:Delayassign.png |frame|center|Delay a time]]

After click "save", the run time showed database is about 8:00 am. Since 20-16=4, the correct run time is 4:00 am.

[[File:delaydatabase.png |frame|center|Time Stored in Database]]

The reason why there is a four-hour time difference is generated from the file <code>application_form.rb</code>, method <code> find_min_from_now(due_at)</code>, and line 142 <code>time_in_min=((due_at - curr_time).to_i/60)</code>. <code> due_at </code> is the system time for Rails (UTC), while <code> curr_time </code> is the local time which is EDT. The two time zones have four-hour time difference. 

===New deadline replace the old one===
This time, we add a new delay in Review section, we delay the deadline from 2015/03/22 21:00 to 2015/03/30 21:00, and set the remind hr to 8 hours.

[[File:delayagain.png |frame|center|Delay a new deadline type]]

However, the delayed_jobs database form is still the same, which means in one assignment there is only one reminder can work. 
As a result, we conclude that only one due_time record associated with different period exists in the database:
*In Expertiza, one assignment has several period, such as submission, review, metareview. Administrates are able to set and postpone due dates for each period separately.
*In the previous version, when the instructor postpone the review deadline and then postpone the submit deadline, the submit deadline’s modification will replace the the review deadline’s modification in database.
*In this case, if both of them need Email reminder, there will be no Email about the former modified deadline.
*After our analysis, we found the due time object is identified with assignment_id, instead of deadline type id.

==UI issues==
In the previous version, there is no UI to display the reminders of assignments. There is no way for instructors to view or delete their delayed tasks related to an assignment. We are going to add a button under Assignment->edit, and add a view to display all delayed jobs derived from the delayed_jobs table in our database.

=System Design=
==Fix Time Issues==
===Unified time zone===
We convert current time to the same time zone as the deadline stored in database. Then the result of comparison will be right so that it can be used for further usage.
In <code>app/models/assignment_form.rb</code>, we modified <code>curr_time=DateTime.now.to_s(:db)</code> to <code>curr_time=DateTime.now.in_time_zone(zone='UTC').to_s(:db)</code> in the <code>find_min_from_now</code> method, to make sure when calculating the minutes from now, the time zone is right. 
Also, to make sure the right display of time, when log in as a administrator, go to Profile and choose the Preferred Time Zone to be "(GMT-05:00) Eastern Time (US&Canada)".

===Separate deadline of each topic period===
In each Assignment, each deadline type (E.g review, submit, metareview) should has its own Email reminder time in the database. New postponed deadline of one type can only replace the same deadline type in the same assignment id category. This bug has been fixed by TA.

==Add UI to visualize for scheduled tasks==
All the scheduled tasks are in the <code>delayed_jobs</code> table in database, so the system will read from that table to show all the tasks‘ information. A new page is created to show all of those scheduled tasks and there is also a delete button for instructor to delete any task. Instructor can view this page via a <code>view delayed jobs</code> button in <code> assignment->edit </code>. 
The code in <code>app/models/assignment_form.rb</code> add the scheduled tasks into <code>delayed_jobs</code> table. 
<pre>
if diff>0
dj=DelayedJob.enqueue(ScheduledTask.new(@assignment.id, deadline_type, due_date.due_at.to_s(:db)), 1, diff.minutes.from_now)
change_item_type(dj.id)
due_date.update_attribute(:delayed_job_id, dj.id)

# If the deadline type is review, add a delayed job to drop outstanding review
if deadline_type == "review"
dj = DelayedJob.enqueue(ScheduledTask.new(@assignment.id, "drop_outstanding_reviews", due_date.due_at.to_s(:db)), 1, diff.minutes.from_now)
change_item_type(dj.id)
end

# If the deadline type is team_formation, add a delayed job to drop one member team
if deadline_type == "team_formation"
dj = DelayedJob.enqueue(ScheduledTask.new(@assignment.id, "drop_one_member_topics", due_date.due_at.to_s(:db)), 1, diff.minutes.from_now)
change_item_type(dj.id)
end
end
</pre>
After adding to the delayed_jobs, the database will store each task's assignment's id, deadline type, due date, task run time etc. 

[[File:delayedjobs.png |frame|center|the delayed jobs table in database]] 
We create a file <code>scheduled_tasks.erb</code> in the path: <code>/views/assignments</code> to show the form. In this file, we use a <code>@scheduled_jobs = DelayedJob.all </code> to read all datas from the "delayed_jobs" table. 
<pre>
<% @assignment = Assignment.find(params[:id]) %>
<h1>Scheduled tasks for <%= @assignment.name %> assignment</h1>
<% if flash[:notice] %>
<div class="flash_note"><%= flash_message :notice %></div>
<% end %>
<% @scheduled_jobs = DelayedJob.all %>
<table class="general">
<th width="25%">Deadline type #</th>
<th width="25%">Run time</th>
<th width="25%">Due date</th>
<th width="25 %">Action</th>
<th width="25 %">Delete</th>
<% i=1 %>
<% for delayed_job in @scheduled_jobs %>
<tr>
<% if delayed_job.handler.include? "assignment_id: #{@assignment.id}"%>
<% handler = delayed_job.handler.split()%>
<td><%= handler[5] %></td>
<td><%= delayed_job.run_at %></td>
<td><%= handler[7][1..-1] + ":" + handler[8][0..-2]%></td>
<% if handler[5] == "submission" %>
<td><%= " "%></td>
<%end%>
<% if handler[5] == "review" %>
<td><%= " "%></td>
<%end%>
<% if handler[5] == "metareview" %>
<td><%= " "%></td>
<%end%>
<% if handler[5] == "team_formation" %>
<td><%= "send email to ask students to form teams"%></td>
<%end%>
<% if handler[5] == "drop_outstanding_reviews" %>
<td><%= "drop outstanding reviews and send emails to those students"%></td>
<%end%>
<% if handler[5] == "drop_one_member_topics" %>
<td><%= "drop one member team topics and send emails to those students"%></td>
<%end%>
<td><%= link_to image_tag('delete_icon.png', :title => 'Delete'),
{:controller => 'assignments', :action => 'delete_scheduled_task',
:id => @assignment.id, :delayed_job_id => delayed_job.id}%></td>
<% end %>
</tr>
<% i=i+1 %>
<% end %>
</table>
<% session[:return_to] = request.url %>
 
<a href="javascript:history.back()">Back</a>
</pre> 
The following two pictures show our UI works. 
[[File:viewdelayedjobs.png |frame|center|add a button to display all scheduled tasks]] 
[[File:showscheduledtask.png|frame|center|The UI to show all the scheduled tasks]] 

==Keep log of the scheduled tasks==
According to the project [https://github.com/expertiza/expertiza/pull/462 E1478], there is a paper_trail<ref name = "Paper_trail Gem"> https://github.com/airblade/paper_trail]</ref> gem which can keep log of the models' data. What we need to do is let it also keep track of our scheduled task data. 
Since the gem need to work with <code>ActiveRecord 3+</code>, while <code>assignment_form</code> doesn't. So we created a new file named <code>delayed_job.rb</code> in <code>models</code> folder, add <code>has_paper_trail</code> in it. Then it is like: 
<pre>
class DelayedJob < Delayed::Job
has_paper_trail
end
</pre>
When the <code>delayed_jobs</code> table changes, a <code>Delayed::Backend::ActiveRecord::Job</code> record is automatically created in the log. In <code>assignment_form.rb</code>, we define a method to change the item type displayed in the log.
<pre>
def change_item_type(delayed_job_id)
log = Version.where(item_type: "Delayed::Backend::ActiveRecord::Job", item_id: delayed_job_id).first
log.update_attribute(:item_type, "ScheduledTask") #Change the item type in the log
end
</pre>
Then we call it in <code>add_to_delayed_queue</code> method of the same file. Every time when the <code>delayed_jobs</code> table has added or deleted or updated data, the log can keep track of them. The following picture shows what the log is after creating scheduled tasks. You can see a "Search log" under the "logout" button. 
[[File:scheduledtasklog.png|frame|center|four scheduled tasks are added in log]] 

==support more schedule tasks==

In our system, we would have four scheduled time: submission, review, metareview and team_formation. When due time comes, the system takes corresponding actions. These scheduled actions are called scheduled tasks.

[[File:Support more scheduled tasks.png|frame|center|Support more scheduled tasks]]

===Drop outstanding reviews===
In this task, instructors should be able to schedule a time to drop all the outstanding reviews, which means the reviews which has not been started. 

Firstly, we create a new deadline type called "drop_outstanding_reviews". When we set the review’s due date, add an item into “delayed job” queue at the same time( refer to "Add UI to visualize for scheduled tasks").
When the review is due, it will automatically call a method to find all the outstanding reviews (reviews which have not been started) in the database then delete them. 
There are two tables in the database to store the information about the reviews: <code>responses</code> and <code>response_maps </code>. 
<code>responses</code> is used to store all the submitted reviews while <code>response_maps</code> stores all the requested reviews, which means if one review has began it will not stored in <code>responses</code> table. Thus, we just need to find the review data in <code>response_maps</code> while not in <code>responses</code> for one assignment and delete them in database. 
We add a method in <code>/models/scheduled_task.rb</code> named <code>drop_outstanding_reviews</code> to drop those reviews. 
<pre>
def drop_outstanding_reviews
reviews = ResponseMap.where(reviewed_object_id: self.assignment_id)
for review in reviews
review_has_began = Response.where(map_id: review.id)
if review_has_began.size.zero?
review_to_drop = ResponseMap.where(id: review.id)
review_to_drop.first.destroy
end
end
end
</pre>
Then, add the following code in <code>perform</code> method of the same file to drop one specified assignment's outstanding reviews at the due time. 
<pre>
if(self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
</pre>

===Send team formation Emails===
In this task, the instructors are able to schedule a specific time to send Emails to all the assignment participants who are still not in any team to find or form one.
We use a previously existed deadline type called "team_formation" and enable to set a team_formation's due date and a reminder under "Assignment->edit->due date". Then add an item into “delayed job” at the same time(refer to "Add UI to visualize for scheduled tasks"). When “delayed job” is triggered, it will automatically call a method to find all the assignment participants who are still not in any team in the database, and send Emails to them to find teammate.
<pre>
if(self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if(assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
</pre>

===Drop one-person topics===
In this task, the instructor should be able to schedule a time to drop all the topics which are held by 1 person teams.
We create a new deadline type called "drop_one_member_topics". When deadline type is team_formation, we add an item to the "delayed_job" queue( refer to "Add UI to visualize for scheduled tasks").
Then when time is due, the system will call a method to find all the topics which are held by 1 person teams in the database, then the professor can drop those topics.
<pre>
def drop_one_member_topics
teams = TeamsUser.all.group(:team_id).count(:team_id)
for team_id in teams.keys
if teams[team_id] == 1
topic_to_drop = SignedUpUser.where(creator_id: team_id).first
if topic_to_drop#check if the one-person-team has signed up a topic
topic_to_drop.delete
end
end
end
end
</pre>
<pre>
if(self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
if(assignment.team_assignment?)
drop_one_member_topics
end
end
</pre>

=Tests=
In this project, our jobs involve two gems as mentioned above. They are "Delayed Job", which can insert a job into queue and execute it at a certain time, and "Paper Trail", to log actions like create, update and destroy for a model. We write rspec tests to make sure that the functionality works well.
In "scheduled_task_spec.rb", we test the functionality that when a due date is created, then delayed jobs of certain deadline type will be created. We may take "team_formation" deadline as an example:
<pre>
describe 'Team formation deadline reminder email' do
it 'should send reminder email for team formation deadline to reviewers ' do
id = 2
@name = "user"
due_at = DateTime.now.advance(:minutes => +2)
due_at1 = Time.parse(due_at.to_s(:db))
curr_time=DateTime.now.to_s(:db)
curr_time=Time.parse(curr_time)
time_in_min=((due_at1 - curr_time).to_i/60) *60
Delayed::Job.delete_all
Delayed::Job.count.should == 0
dj = Delayed::Job.enqueue(ScheduledTask.new(id, "team_formation", due_at), 1, time_in_min)
Delayed::Job.count.should == 1
Delayed::Job.last.handler.should include("deadline_type: team_formation")
dj2 = Delayed::Job.enqueue(ScheduledTask.new(id, "drop_one_member_topics", due_at), 1, time_in_min)
Delayed::Job.count.should == 2
Delayed::Job.last.handler.should include("deadline_type: drop_one_member_topics")
end
end
</pre>
When team_formation deadline is created, there will be two delayed jobs created. One is reminder email and the other one is drop topics from students who don't have a team yet.
For the functionality of keeping log of scheduled tasks, "has_paper_trail_spec.rb" file is used to make sure that when a delayed job instance is created, one log will be generated.
<pre>
require 'rails_helper'
describe 'has_paper_trail' do
it "will create Version record when create delayed jobs record" do
PaperTrail.enabled =true
for version in Version.all
version.delete
end
Version.all.count.should == 0
@delayed_job = DelayedJob.new
@delayed_job.id = 1
@delayed_job.priority = 1
@delayed_job.attempts = 0
@delayed_job.save
Version.all.count.should == 1
end
end
</pre>

=References=
<references/>

CSC/ECE 517 Spring 2015 E1529 GLDS

2015-04-22T18:02:50Z

Jli53: /* Tests */

E1529. Extend the Email notification feature to scheduled tasks 

=Overview=

==Introduction to Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities<ref>[https://github.com/expertiza/expertiza Expertiza Github]</ref>. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc). It is also a powerful tool for professor to manage courses and assignments and so on. The latest "Rails 4" branch of Expertiza, although combined with various enhancements from the past two years, is seriously broken, from data migration to key feature implementation. Part of the reason has been the design strategy and code changes by various teams.

==Email notification feature to scheduled tasks==
This is a feature that has already been partially implemented in Expertiza [https://github.com/expertiza/expertiza/pull/445 E1451] implemented both sychronous and asychoronous mailers. Sychronous Emails refer to the Emails sent immediatly after an event (e.g. when student receive a peer-review). Asychoronous Email we implemented by the Gem "delayed job” and when a task (asychronous Email) is added to the delayed queue, a count-down number of minutes needs to be specified. 

Our team aims to extend this project. This wiki page documents the problem analysis and provides a guideline for future development and enhancement.

__TOC__

=Scope=
==Project Scope==
E1451. Create Mailers for All Email Messages [https://github.com/expertiza/expertiza/pull/445 github] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/OSS_E1451_las wiki] [http://expertiza.ncsu.edu/submitted_content/download/28122?current_folder%5Bname%5D=%2Flocal%2Frails%2Fexpertiza%2Freleases%2F20140702225848%2Fpg_data%2Fefg%2Fcsc517%2Ff14%2F%2F18&download=E1451_Report.pdf report] (Merged in [https://docs.google.com/a/ncsu.edu/document/d/1aypHb5UOe-3nPfruNeh2HZjeT-wfv6f-ZsZg2jDMNkQ/edit E1483])

Extending this project, the new system should be capable of
*If one task is added to the delayed job queue, the asychronous Email should be updated or deleted automatically.
*Add UI to visualize for the task in delayed job queue, instructors should be able to view tasks related to the assignments they have created.
*Keep log of the scheduled tasks when they are scheduled and done, record events in the same log as project [https://github.com/expertiza/expertiza/pull/462 E1478].
*[optional] support more scheduled task:
**instructors are able to schedule the time to drop all the outstanding reviews (reviews which has not been started)
**instructors are able to schedule a specific time to send Emails to all the assignment participants who are still not in any team to find or form one.
**(new) instructor should be able to schedule a time to drop all the topics which are held by 1 person teams.
*create tests to make sure the test coverage increases.
==Files Involved==
Mailers:
*delayed_mailer.rb

Models:
*assignment_form.rb
*due_date.rb
*delayed_job.rb(new created)
*scheduled_task.rb(new created)

Views:
*_due_dates.html.erb
*_assignments_actions.html.erb
* scheduled_tasks.erb(new created)

Controllers:
*assignments_controller.rb

==Gems Related==
*gem 'delayed_job_active_record'

[https://github.com/collectiveidea/delayed_job Delayed:Job] encapsulates the common pattern of asynchronously executing longer tasks in the background<ref> [https://github.com/collectiveidea/delayed_job Delayed_job Gem]</ref>. It allows to support multiple backends for storing the job queue. By using 'delayed_job_active_record' gem, we can use delayed_job with Active Record. This Active Record backend requires a job table.

After running rails generate delayed_job:active_record and rake db:migrate, a "delayed_jobs" table is created in our database. This gem integrates well with many [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS] backend such as MySQL. Using this gem, we can store all scheduled tasks queue into the "delayed_jobs" table.

*gem 'paper_trail'
PaperTrail allows to track changes of models' data, which is good for versioning. You can see how a model looked at any stage in its lifecycle, revert it to any version, and even undelete it after it's been destroyed<ref>[https://github.com/airblade/paper_trail Paper_trail Gem]</ref>. Using this gem, we can keep log of the scheduled tasks.

=Problem Analysis=

== Time Issues==

Initially, when we want to verify the email function, we found many time issues in this system. That blocks our work about email notification. Some related problems are explained and analyzed in this section.

===Wrong displayed time===

Firstly, when we set a due time to test the mail features, we found the display of time is incorrect.

In the “Assignment Edit”->“Due dates”, when we modify the “Date & time” of the deadline, the displayed time will be 4 hours ahead of the time we saved. 

[[File:Wrong display of time.png‎ |frame|center|Set due time]]

[[File:Wrong display of time 2.png |frame|center|After we click the save button, we can see that all the time are 4 hours ahead of the set time]]

[[File:database_deadline.png |frame|center|The deadline time is stored correct in the database]]

After several tries, we found that every time when we click "save", the saved time is 4 hours earlier then the last saved time. However, the time in the database is alway correct as the time we save. After we analyze, we found the problem may lay in the line of 68 of <code>views/assignment/edit/_due_dates.html.erb</code> file.

<pre>due_at = new Date(due_at.substr(0, 16)).format('yyyy/mm/dd HH:MM');</pre>

When we declare a Data object, this Data() function will perform a time zone conversion automatically. Yet Rails’ default timezone stored in database is UTC. So the displayed time(local time, which is EDT) and time in database is different.

===Different time zone===

In the previous version, when current time is compared with the time stored in database, they may apply to different time zones so that the result of comparison may be wrong. 
When we delay a deadline of an assignment, for example, we set the deadline of metareview from2015/03/28 16:00 to 2015/04/04 20:00 and set the reminder hr to 16 hours.

[[File:Delayassign.png |frame|center|Delay a time]]

After click "save", the run time showed database is about 8:00 am. Since 20-16=4, the correct run time is 4:00 am.

[[File:delaydatabase.png |frame|center|Time Stored in Database]]

The reason why there is a four-hour time difference is generated from the file <code>application_form.rb</code>, method <code> find_min_from_now(due_at)</code>, and line 142 <code>time_in_min=((due_at - curr_time).to_i/60)</code>. <code> due_at </code> is the system time for Rails (UTC), while <code> curr_time </code> is the local time which is EDT. The two time zones have four-hour time difference. 

===New deadline replace the old one===
This time, we add a new delay in Review section, we delay the deadline from 2015/03/22 21:00 to 2015/03/30 21:00, and set the remind hr to 8 hours.

[[File:delayagain.png |frame|center|Delay a new deadline type]]

However, the delayed_jobs database form is still the same, which means in one assignment there is only one reminder can work. 
As a result, we conclude that only one due_time record associated with different period exists in the database:
*In Expertiza, one assignment has several period, such as submission, review, metareview. Administrates are able to set and postpone due dates for each period separately.
*In the previous version, when the instructor postpone the review deadline and then postpone the submit deadline, the submit deadline’s modification will replace the the review deadline’s modification in database.
*In this case, if both of them need Email reminder, there will be no Email about the former modified deadline.
*After our analysis, we found the due time object is identified with assignment_id, instead of deadline type id.

==UI issues==
In the previous version, there is no UI to display the reminders of assignments. There is no way for instructors to view or delete their delayed tasks related to an assignment. We are going to add a button under Assignment->edit, and add a view to display all delayed jobs derived from the delayed_jobs table in our database.

=System Design=
==Fix Time Issues==
===Unified time zone===
We convert current time to the same time zone as the deadline stored in database. Then the result of comparison will be right so that it can be used for further usage.
In <code>app/models/assignment_form.rb</code>, we modified <code>curr_time=DateTime.now.to_s(:db)</code> to <code>curr_time=DateTime.now.in_time_zone(zone='UTC').to_s(:db)</code> in the <code>find_min_from_now</code> method, to make sure when calculating the minutes from now, the time zone is right. 
Also, to make sure the right display of time, when log in as a administrator, go to Profile and choose the Preferred Time Zone to be "(GMT-05:00) Eastern Time (US&Canada)".

===Separate deadline of each topic period===
In each Assignment, each deadline type (E.g review, submit, metareview) should has its own Email reminder time in the database. New postponed deadline of one type can only replace the same deadline type in the same assignment id category. This bug has been fixed by TA.

==Add UI to visualize for scheduled tasks==
All the scheduled tasks are in the <code>delayed_jobs</code> table in database, so the system will read from that table to show all the tasks‘ information. A new page is created to show all of those scheduled tasks and there is also a delete button for instructor to delete any task. Instructor can view this page via a <code>view delayed jobs</code> button in <code> assignment->edit </code>. 
The code in <code>app/models/assignment_form.rb</code> add the scheduled tasks into <code>delayed_jobs</code> table. 
<pre>
if diff>0
dj=DelayedJob.enqueue(ScheduledTask.new(@assignment.id, deadline_type, due_date.due_at.to_s(:db)),
1, diff.minutes.from_now)
change_item_type(dj.id)
due_date.update_attribute(:delayed_job_id, dj.id)

# If the deadline type is review, add a delayed job to drop outstanding review
if deadline_type == "review"
dj = DelayedJob.enqueue(ScheduledTask.new(@assignment.id, "drop_outstanding_reviews", due_date.due_at.to_s(:db)),
1, diff.minutes.from_now)
change_item_type(dj.id)
end

# If the deadline type is team_formation, add a delayed job to drop one member team
if deadline_type == "team_formation"
dj = DelayedJob.enqueue(ScheduledTask.new(@assignment.id, "drop_one_member_topics", due_date.due_at.to_s(:db)),
1, diff.minutes.from_now)
change_item_type(dj.id)
end
end
</pre>
After adding to the delayed_jobs, the database will store each task's assignment's id, deadline type, due date, task run time etc. 

[[File:delayedjobs.png |frame|center|the delayed jobs table in database]] 
We create a file <code>scheduled_tasks.erb</code> in the path: <code>/views/assignments</code> to show the form. In this file, we use a <code>@scheduled_jobs = DelayedJob.all </code> to read all datas from the "delayed_jobs" table. 
<pre>
<% @assignment = Assignment.find(params[:id]) %>
<h1>Scheduled tasks for <%= @assignment.name %> assignment</h1>
<% if flash[:notice] %>
<div class="flash_note"><%= flash_message :notice %></div>
<% end %>
<% @scheduled_jobs = DelayedJob.all %>
<table class="general">
<th width="25%">Deadline type #</th>
<th width="25%">Run time</th>
<th width="25%">Due date</th>
<th width="25 %">Action</th>
<th width="25 %">Delete</th>
<% i=1 %>
<% for delayed_job in @scheduled_jobs %>
<tr>
<% if delayed_job.handler.include? "assignment_id: #{@assignment.id}"%>
<% handler = delayed_job.handler.split()%>
<td><%= handler[5] %></td>
<td><%= delayed_job.run_at %></td>
<td><%= handler[7][1..-1] + ":" + handler[8][0..-2]%></td>
<% if handler[5] == "submission" %>
<td><%= " "%></td>
<%end%>
<% if handler[5] == "review" %>
<td><%= " "%></td>
<%end%>
<% if handler[5] == "metareview" %>
<td><%= " "%></td>
<%end%>
<% if handler[5] == "team_formation" %>
<td><%= "send email to ask students to form teams"%></td>
<%end%>
<% if handler[5] == "drop_outstanding_reviews" %>
<td><%= "drop outstanding reviews and send emails to those students"%></td>
<%end%>
<% if handler[5] == "drop_one_member_topics" %>
<td><%= "drop one member team topics and send emails to those students"%></td>
<%end%>
<td><%= link_to image_tag('delete_icon.png', :title => 'Delete'),
{:controller => 'assignments', :action => 'delete_scheduled_task',
:id => @assignment.id, :delayed_job_id => delayed_job.id}%></td>
<% end %>
</tr>
<% i=i+1 %>
<% end %>
</table>
<% session[:return_to] = request.url %>
 
<a href="javascript:history.back()">Back</a>
</pre> 
The following two pictures show our UI works. 
[[File:viewdelayedjobs.png |frame|center|add a button to display all scheduled tasks]] 
[[File:showscheduledtask.png|frame|center|The UI to show all the scheduled tasks]] 

==Keep log of the scheduled tasks==
According to the project [https://github.com/expertiza/expertiza/pull/462 E1478], there is a paper_trail<ref name = "Paper_trail Gem"> https://github.com/airblade/paper_trail]</ref> gem which can keep log of the models' data. What we need to do is let it also keep track of our scheduled task data. 
Since the gem need to work with <code>ActiveRecord 3+</code>, while <code>assignment_form</code> doesn't. So we created a new file named <code>delayed_job.rb</code> in <code>models</code> folder, add <code>has_paper_trail</code> in it. Then it is like: 
<pre>
class DelayedJob < Delayed::Job
has_paper_trail
end
</pre>
When the <code>delayed_jobs</code> table changes, a <code>Delayed::Backend::ActiveRecord::Job</code> record is automatically created in the log. In <code>assignment_form.rb</code>, we define a method to change the item type displayed in the log.
<pre>
def change_item_type(delayed_job_id)
log = Version.where(item_type: "Delayed::Backend::ActiveRecord::Job", item_id: delayed_job_id).first
log.update_attribute(:item_type, "ScheduledTask") #Change the item type in the log
end
</pre>
Then we call it in <code>add_to_delayed_queue</code> method of the same file. Every time when the <code>delayed_jobs</code> table has added or deleted or updated data, the log can keep track of them. The following picture shows what the log is after creating scheduled tasks. You can see a "Search log" under the "logout" button. 
[[File:scheduledtasklog.png|frame|center|four scheduled tasks are added in log]] 

==support more schedule tasks==

In our system, we would have four scheduled time: submission, review, metareview and team_formation. When due time comes, the system takes corresponding actions. These scheduled actions are called scheduled tasks.

[[File:Support more scheduled tasks.png|frame|center|Support more scheduled tasks]]

===Drop outstanding reviews===
In this task, instructors should be able to schedule a time to drop all the outstanding reviews, which means the reviews which has not been started. 

Firstly, we create a new deadline type called "drop_outstanding_reviews". When we set the review’s due date, add an item into “delayed job” queue at the same time( refer to "Add UI to visualize for scheduled tasks").
When the review is due, it will automatically call a method to find all the outstanding reviews (reviews which have not been started) in the database then delete them. 
There are two tables in the database to store the information about the reviews: <code>responses</code> and <code>response_maps </code>. 
<code>responses</code> is used to store all the submitted reviews while <code>response_maps</code> stores all the requested reviews, which means if one review has began it will not stored in <code>responses</code> table. Thus, we just need to find the review data in <code>response_maps</code> while not in <code>responses</code> for one assignment and delete them in database. 
We add a method in <code>/models/scheduled_task.rb</code> named <code>drop_outstanding_reviews</code> to drop those reviews. 
<pre>
def drop_outstanding_reviews
reviews = ResponseMap.where(reviewed_object_id: self.assignment_id)
for review in reviews
review_has_began = Response.where(map_id: review.id)
if review_has_began.size.zero?
review_to_drop = ResponseMap.where(id: review.id)
review_to_drop.first.destroy
end
end
end
</pre>
Then, add the following code in <code>perform</code> method of the same file to drop one specified assignment's outstanding reviews at the due time. 
<pre>
if(self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
</pre>

===Send team formation Emails===
In this task, the instructors are able to schedule a specific time to send Emails to all the assignment participants who are still not in any team to find or form one.
We use a previously existed deadline type called "team_formation" and enable to set a team_formation's due date and a reminder under "Assignment->edit->due date". Then add an item into “delayed job” at the same time(refer to "Add UI to visualize for scheduled tasks"). When “delayed job” is triggered, it will automatically call a method to find all the assignment participants who are still not in any team in the database, and send Emails to them to find teammate.
<pre>
if(self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if(assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
</pre>

===Drop one-person topics===
In this task, the instructor should be able to schedule a time to drop all the topics which are held by 1 person teams.
We create a new deadline type called "drop_one_member_topics". When deadline type is team_formation, we add an item to the "delayed_job" queue( refer to "Add UI to visualize for scheduled tasks").
Then when time is due, the system will call a method to find all the topics which are held by 1 person teams in the database, then the professor can drop those topics.
<pre>
def drop_one_member_topics
teams = TeamsUser.all.group(:team_id).count(:team_id)
for team_id in teams.keys
if teams[team_id] == 1
topic_to_drop = SignedUpUser.where(creator_id: team_id).first
if topic_to_drop#check if the one-person-team has signed up a topic
topic_to_drop.delete
end
end
end
end
</pre>
<pre>
if(self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
if(assignment.team_assignment?)
drop_one_member_topics
end
end
</pre>

=Tests=
In this project, our jobs involve two gems as mentioned above. They are "Delayed Job", which can insert a job into queue and execute it at a certain time, and "Paper Trail", to log actions like create, update and destroy for a model. We write rspec tests to make sure that the functionality works well.
In "scheduled_task_spec.rb", we test the functionality that when a due date is created, then delayed jobs of certain deadline type will be created. We may take "team_formation" deadline as an example:
<pre>
describe 'Team formation deadline reminder email' do
it 'should send reminder email for team formation deadline to reviewers ' do
id = 2
@name = "user"
due_at = DateTime.now.advance(:minutes => +2)
due_at1 = Time.parse(due_at.to_s(:db))
curr_time=DateTime.now.to_s(:db)
curr_time=Time.parse(curr_time)
time_in_min=((due_at1 - curr_time).to_i/60) *60
Delayed::Job.delete_all
Delayed::Job.count.should == 0
dj = Delayed::Job.enqueue(ScheduledTask.new(id, "team_formation", due_at), 1, time_in_min)
Delayed::Job.count.should == 1
Delayed::Job.last.handler.should include("deadline_type: team_formation")
dj2 = Delayed::Job.enqueue(ScheduledTask.new(id, "drop_one_member_topics", due_at), 1, time_in_min)
Delayed::Job.count.should == 2
Delayed::Job.last.handler.should include("deadline_type: drop_one_member_topics")
end
end
</pre>
When team_formation deadline is created, there will be two delayed jobs created. One is reminder email and the other one is drop topics from students who don't have a team yet.
For the functionality of keeping log of scheduled tasks, "has_paper_trail_spec.rb" file is used to make sure that when a delayed job instance is created, one log will be generated.
<pre>
require 'rails_helper'
describe 'has_paper_trail' do
it "will create Version record when create delayed jobs record" do
PaperTrail.enabled =true
for version in Version.all
version.delete
end
Version.all.count.should == 0
@delayed_job = DelayedJob.new
@delayed_job.id = 1
@delayed_job.priority = 1
@delayed_job.attempts = 0
@delayed_job.save
Version.all.count.should == 1
end
end
</pre>

=References=
<references/>

CSC/ECE 517 Spring 2015 E1529 GLDS

2015-04-22T17:57:21Z

Jli53: /* Tests */

E1529. Extend the Email notification feature to scheduled tasks 

=Overview=

==Introduction to Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities<ref>[https://github.com/expertiza/expertiza Expertiza Github]</ref>. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc). It is also a powerful tool for professor to manage courses and assignments and so on. The latest "Rails 4" branch of Expertiza, although combined with various enhancements from the past two years, is seriously broken, from data migration to key feature implementation. Part of the reason has been the design strategy and code changes by various teams.

==Email notification feature to scheduled tasks==
This is a feature that has already been partially implemented in Expertiza [https://github.com/expertiza/expertiza/pull/445 E1451] implemented both sychronous and asychoronous mailers. Sychronous Emails refer to the Emails sent immediatly after an event (e.g. when student receive a peer-review). Asychoronous Email we implemented by the Gem "delayed job” and when a task (asychronous Email) is added to the delayed queue, a count-down number of minutes needs to be specified. 

Our team aims to extend this project. This wiki page documents the problem analysis and provides a guideline for future development and enhancement.

__TOC__

=Scope=
==Project Scope==
E1451. Create Mailers for All Email Messages [https://github.com/expertiza/expertiza/pull/445 github] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/OSS_E1451_las wiki] [http://expertiza.ncsu.edu/submitted_content/download/28122?current_folder%5Bname%5D=%2Flocal%2Frails%2Fexpertiza%2Freleases%2F20140702225848%2Fpg_data%2Fefg%2Fcsc517%2Ff14%2F%2F18&download=E1451_Report.pdf report] (Merged in [https://docs.google.com/a/ncsu.edu/document/d/1aypHb5UOe-3nPfruNeh2HZjeT-wfv6f-ZsZg2jDMNkQ/edit E1483])

Extending this project, the new system should be capable of
*If one task is added to the delayed job queue, the asychronous Email should be updated or deleted automatically.
*Add UI to visualize for the task in delayed job queue, instructors should be able to view tasks related to the assignments they have created.
*Keep log of the scheduled tasks when they are scheduled and done, record events in the same log as project [https://github.com/expertiza/expertiza/pull/462 E1478].
*[optional] support more scheduled task:
**instructors are able to schedule the time to drop all the outstanding reviews (reviews which has not been started)
**instructors are able to schedule a specific time to send Emails to all the assignment participants who are still not in any team to find or form one.
**(new) instructor should be able to schedule a time to drop all the topics which are held by 1 person teams.
*create tests to make sure the test coverage increases.
==Files Involved==
Mailers:
*delayed_mailer.rb

Models:
*assignment_form.rb
*due_date.rb
*delayed_job.rb(new created)
*scheduled_task.rb(new created)

Views:
*_due_dates.html.erb
*_assignments_actions.html.erb
* scheduled_tasks.erb(new created)

Controllers:
*assignments_controller.rb

==Gems Related==
*gem 'delayed_job_active_record'

[https://github.com/collectiveidea/delayed_job Delayed:Job] encapsulates the common pattern of asynchronously executing longer tasks in the background<ref> [https://github.com/collectiveidea/delayed_job Delayed_job Gem]</ref>. It allows to support multiple backends for storing the job queue. By using 'delayed_job_active_record' gem, we can use delayed_job with Active Record. This Active Record backend requires a job table.

After running rails generate delayed_job:active_record and rake db:migrate, a "delayed_jobs" table is created in our database. This gem integrates well with many [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS] backend such as MySQL. Using this gem, we can store all scheduled tasks queue into the "delayed_jobs" table.

*gem 'paper_trail'
PaperTrail allows to track changes of models' data, which is good for versioning. You can see how a model looked at any stage in its lifecycle, revert it to any version, and even undelete it after it's been destroyed<ref>[https://github.com/airblade/paper_trail Paper_trail Gem]</ref>. Using this gem, we can keep log of the scheduled tasks.

=Problem Analysis=

== Time Issues==

Initially, when we want to verify the email function, we found many time issues in this system. That blocks our work about email notification. Some related problems are explained and analyzed in this section.

===Wrong displayed time===

Firstly, when we set a due time to test the mail features, we found the display of time is incorrect.

In the “Assignment Edit”->“Due dates”, when we modify the “Date & time” of the deadline, the displayed time will be 4 hours ahead of the time we saved. 

[[File:Wrong display of time.png‎ |frame|center|Set due time]]

[[File:Wrong display of time 2.png |frame|center|After we click the save button, we can see that all the time are 4 hours ahead of the set time]]

[[File:database_deadline.png |frame|center|The deadline time is stored correct in the database]]

After several tries, we found that every time when we click "save", the saved time is 4 hours earlier then the last saved time. However, the time in the database is alway correct as the time we save. After we analyze, we found the problem may lay in the line of 68 of <code>views/assignment/edit/_due_dates.html.erb</code> file.

<pre>due_at = new Date(due_at.substr(0, 16)).format('yyyy/mm/dd HH:MM');</pre>

When we declare a Data object, this Data() function will perform a time zone conversion automatically. Yet Rails’ default timezone stored in database is UTC. So the displayed time(local time, which is EDT) and time in database is different.

===Different time zone===

In the previous version, when current time is compared with the time stored in database, they may apply to different time zones so that the result of comparison may be wrong. 
When we delay a deadline of an assignment, for example, we set the deadline of metareview from2015/03/28 16:00 to 2015/04/04 20:00 and set the reminder hr to 16 hours.

[[File:Delayassign.png |frame|center|Delay a time]]

After click "save", the run time showed database is about 8:00 am. Since 20-16=4, the correct run time is 4:00 am.

[[File:delaydatabase.png |frame|center|Time Stored in Database]]

The reason why there is a four-hour time difference is generated from the file <code>application_form.rb</code>, method <code> find_min_from_now(due_at)</code>, and line 142 <code>time_in_min=((due_at - curr_time).to_i/60)</code>. <code> due_at </code> is the system time for Rails (UTC), while <code> curr_time </code> is the local time which is EDT. The two time zones have four-hour time difference. 

===New deadline replace the old one===
This time, we add a new delay in Review section, we delay the deadline from 2015/03/22 21:00 to 2015/03/30 21:00, and set the remind hr to 8 hours.

[[File:delayagain.png |frame|center|Delay a new deadline type]]

However, the delayed_jobs database form is still the same, which means in one assignment there is only one reminder can work. 
As a result, we conclude that only one due_time record associated with different period exists in the database:
*In Expertiza, one assignment has several period, such as submission, review, metareview. Administrates are able to set and postpone due dates for each period separately.
*In the previous version, when the instructor postpone the review deadline and then postpone the submit deadline, the submit deadline’s modification will replace the the review deadline’s modification in database.
*In this case, if both of them need Email reminder, there will be no Email about the former modified deadline.
*After our analysis, we found the due time object is identified with assignment_id, instead of deadline type id.

==UI issues==
In the previous version, there is no UI to display the reminders of assignments. There is no way for instructors to view or delete their delayed tasks related to an assignment. We are going to add a button under Assignment->edit, and add a view to display all delayed jobs derived from the delayed_jobs table in our database.

=System Design=
==Fix Time Issues==
===Unified time zone===
We convert current time to the same time zone as the deadline stored in database. Then the result of comparison will be right so that it can be used for further usage.
In <code>app/models/assignment_form.rb</code>, we modified <code>curr_time=DateTime.now.to_s(:db)</code> to <code>curr_time=DateTime.now.in_time_zone(zone='UTC').to_s(:db)</code> in the <code>find_min_from_now</code> method, to make sure when calculating the minutes from now, the time zone is right. 
Also, to make sure the right display of time, when log in as a administrator, go to Profile and choose the Preferred Time Zone to be "(GMT-05:00) Eastern Time (US&Canada)".

===Separate deadline of each topic period===
In each Assignment, each deadline type (E.g review, submit, metareview) should has its own Email reminder time in the database. New postponed deadline of one type can only replace the same deadline type in the same assignment id category. This bug has been fixed by TA.

==Add UI to visualize for scheduled tasks==
All the scheduled tasks are in the <code>delayed_jobs</code> table in database, so the system will read from that table to show all the tasks‘ information. A new page is created to show all of those scheduled tasks and there is also a delete button for instructor to delete any task. Instructor can view this page via a <code>view delayed jobs</code> button in <code> assignment->edit </code>. 
The code in <code>app/models/assignment_form.rb</code> add the scheduled tasks into <code>delayed_jobs</code> table. 
<pre>
if diff>0
dj=DelayedJob.enqueue(ScheduledTask.new(@assignment.id, deadline_type, due_date.due_at.to_s(:db)),
1, diff.minutes.from_now)
change_item_type(dj.id)
due_date.update_attribute(:delayed_job_id, dj.id)

# If the deadline type is review, add a delayed job to drop outstanding review
if deadline_type == "review"
dj = DelayedJob.enqueue(ScheduledTask.new(@assignment.id, "drop_outstanding_reviews", due_date.due_at.to_s(:db)),
1, diff.minutes.from_now)
change_item_type(dj.id)
end

# If the deadline type is team_formation, add a delayed job to drop one member team
if deadline_type == "team_formation"
dj = DelayedJob.enqueue(ScheduledTask.new(@assignment.id, "drop_one_member_topics", due_date.due_at.to_s(:db)),
1, diff.minutes.from_now)
change_item_type(dj.id)
end
end
</pre>
After adding to the delayed_jobs, the database will store each task's assignment's id, deadline type, due date, task run time etc. 

[[File:delayedjobs.png |frame|center|the delayed jobs table in database]] 
We create a file <code>scheduled_tasks.erb</code> in the path: <code>/views/assignments</code> to show the form. In this file, we use a <code>@scheduled_jobs = DelayedJob.all </code> to read all datas from the "delayed_jobs" table. 
<pre>
<% @assignment = Assignment.find(params[:id]) %>
<h1>Scheduled tasks for <%= @assignment.name %> assignment</h1>
<% if flash[:notice] %>
<div class="flash_note"><%= flash_message :notice %></div>
<% end %>
<% @scheduled_jobs = DelayedJob.all %>
<table class="general">
<th width="25%">Deadline type #</th>
<th width="25%">Run time</th>
<th width="25%">Due date</th>
<th width="25 %">Action</th>
<th width="25 %">Delete</th>
<% i=1 %>
<% for delayed_job in @scheduled_jobs %>
<tr>
<% if delayed_job.handler.include? "assignment_id: #{@assignment.id}"%>
<% handler = delayed_job.handler.split()%>
<td><%= handler[5] %></td>
<td><%= delayed_job.run_at %></td>
<td><%= handler[7][1..-1] + ":" + handler[8][0..-2]%></td>
<% if handler[5] == "submission" %>
<td><%= " "%></td>
<%end%>
<% if handler[5] == "review" %>
<td><%= " "%></td>
<%end%>
<% if handler[5] == "metareview" %>
<td><%= " "%></td>
<%end%>
<% if handler[5] == "team_formation" %>
<td><%= "send email to ask students to form teams"%></td>
<%end%>
<% if handler[5] == "drop_outstanding_reviews" %>
<td><%= "drop outstanding reviews and send emails to those students"%></td>
<%end%>
<% if handler[5] == "drop_one_member_topics" %>
<td><%= "drop one member team topics and send emails to those students"%></td>
<%end%>
<td><%= link_to image_tag('delete_icon.png', :title => 'Delete'),
{:controller => 'assignments', :action => 'delete_scheduled_task',
:id => @assignment.id, :delayed_job_id => delayed_job.id}%></td>
<% end %>
</tr>
<% i=i+1 %>
<% end %>
</table>
<% session[:return_to] = request.url %>
 
<a href="javascript:history.back()">Back</a>
</pre> 
The following two pictures show our UI works. 
[[File:viewdelayedjobs.png |frame|center|add a button to display all scheduled tasks]] 
[[File:showscheduledtask.png|frame|center|The UI to show all the scheduled tasks]] 

==Keep log of the scheduled tasks==
According to the project [https://github.com/expertiza/expertiza/pull/462 E1478], there is a paper_trail<ref name = "Paper_trail Gem"> https://github.com/airblade/paper_trail]</ref> gem which can keep log of the models' data. What we need to do is let it also keep track of our scheduled task data. 
Since the gem need to work with <code>ActiveRecord 3+</code>, while <code>assignment_form</code> doesn't. So we created a new file named <code>delayed_job.rb</code> in <code>models</code> folder, add <code>has_paper_trail</code> in it. Then it is like: 
<pre>
class DelayedJob < Delayed::Job
has_paper_trail
end
</pre>
When the <code>delayed_jobs</code> table changes, a <code>Delayed::Backend::ActiveRecord::Job</code> record is automatically created in the log. In <code>assignment_form.rb</code>, we define a method to change the item type displayed in the log.
<pre>
def change_item_type(delayed_job_id)
log = Version.where(item_type: "Delayed::Backend::ActiveRecord::Job", item_id: delayed_job_id).first
log.update_attribute(:item_type, "ScheduledTask") #Change the item type in the log
end
</pre>
Then we call it in <code>add_to_delayed_queue</code> method of the same file. Every time when the <code>delayed_jobs</code> table has added or deleted or updated data, the log can keep track of them. The following picture shows what the log is after creating scheduled tasks. You can see a "Search log" under the "logout" button. 
[[File:scheduledtasklog.png|frame|center|four scheduled tasks are added in log]] 

==support more schedule tasks==

In our system, we would have four scheduled time: submission, review, metareview and team_formation. When due time comes, the system takes corresponding actions. These scheduled actions are called scheduled tasks.

[[File:Support more scheduled tasks.png|frame|center|Support more scheduled tasks]]

===Drop outstanding reviews===
In this task, instructors should be able to schedule a time to drop all the outstanding reviews, which means the reviews which has not been started. 

Firstly, we create a new deadline type called "drop_outstanding_reviews". When we set the review’s due date, add an item into “delayed job” queue at the same time( refer to "Add UI to visualize for scheduled tasks").
When the review is due, it will automatically call a method to find all the outstanding reviews (reviews which have not been started) in the database then delete them. 
There are two tables in the database to store the information about the reviews: <code>responses</code> and <code>response_maps </code>. 
<code>responses</code> is used to store all the submitted reviews while <code>response_maps</code> stores all the requested reviews, which means if one review has began it will not stored in <code>responses</code> table. Thus, we just need to find the review data in <code>response_maps</code> while not in <code>responses</code> for one assignment and delete them in database. 
We add a method in <code>/models/scheduled_task.rb</code> named <code>drop_outstanding_reviews</code> to drop those reviews. 
<pre>
def drop_outstanding_reviews
reviews = ResponseMap.where(reviewed_object_id: self.assignment_id)
for review in reviews
review_has_began = Response.where(map_id: review.id)
if review_has_began.size.zero?
review_to_drop = ResponseMap.where(id: review.id)
review_to_drop.first.destroy
end
end
end
</pre>
Then, add the following code in <code>perform</code> method of the same file to drop one specified assignment's outstanding reviews at the due time. 
<pre>
if(self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
</pre>

===Send team formation Emails===
In this task, the instructors are able to schedule a specific time to send Emails to all the assignment participants who are still not in any team to find or form one.
We use a previously existed deadline type called "team_formation" and enable to set a team_formation's due date and a reminder under "Assignment->edit->due date". Then add an item into “delayed job” at the same time(refer to "Add UI to visualize for scheduled tasks"). When “delayed job” is triggered, it will automatically call a method to find all the assignment participants who are still not in any team in the database, and send Emails to them to find teammate.
<pre>
if(self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if(assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
</pre>

===Drop one-person topics===
In this task, the instructor should be able to schedule a time to drop all the topics which are held by 1 person teams.
We create a new deadline type called "drop_one_member_topics". When deadline type is team_formation, we add an item to the "delayed_job" queue( refer to "Add UI to visualize for scheduled tasks").
Then when time is due, the system will call a method to find all the topics which are held by 1 person teams in the database, then the professor can drop those topics.
<pre>
def drop_one_member_topics
teams = TeamsUser.all.group(:team_id).count(:team_id)
for team_id in teams.keys
if teams[team_id] == 1
topic_to_drop = SignedUpUser.where(creator_id: team_id).first
if topic_to_drop#check if the one-person-team has signed up a topic
topic_to_drop.delete
end
end
end
end
</pre>
<pre>
if(self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
if(assignment.team_assignment?)
drop_one_member_topics
end
end
</pre>

=Tests=
In this project, our jobs involve two gems as mentioned above. They are "Delayed Job", which can insert a job into queue and execute it at a certain time, and "Paper Trail", to log actions like create, update and destroy for a model. We write rspec tests to make sure that the functionality works well. In "scheduled_task_spec.rb", we test the functionality that when a due date is created, then delayed jobs of certain deadline type will be created. We may take "team_formation" deadline as an example:
<pre>
describe 'Team formation deadline reminder email' do

it 'should send reminder email for team formation deadline to reviewers ' do

id = 2
@name = "user"
due_at = DateTime.now.advance(:minutes => +2)

due_at1 = Time.parse(due_at.to_s(:db))
curr_time=DateTime.now.to_s(:db)
curr_time=Time.parse(curr_time)
time_in_min=((due_at1 - curr_time).to_i/60) *60
Delayed::Job.delete_all
Delayed::Job.count.should == 0

dj = Delayed::Job.enqueue(ScheduledTask.new(id, "team_formation", due_at), 1, time_in_min)
Delayed::Job.count.should == 1
Delayed::Job.last.handler.should include("deadline_type: team_formation")
dj2 = Delayed::Job.enqueue(ScheduledTask.new(id, "drop_one_member_topics", due_at), 1, time_in_min)
Delayed::Job.count.should == 2
Delayed::Job.last.handler.should include("deadline_type: drop_one_member_topics")
end
end
</pre>

=References=
<references/>

CSC/ECE 517 Spring 2015 E1529 GLDS

2015-04-22T17:48:25Z

Jli53: /* Tests */

E1529. Extend the Email notification feature to scheduled tasks 

=Overview=

==Introduction to Expertiza==

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities<ref>[https://github.com/expertiza/expertiza Expertiza Github]</ref>. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc). It is also a powerful tool for professor to manage courses and assignments and so on. The latest "Rails 4" branch of Expertiza, although combined with various enhancements from the past two years, is seriously broken, from data migration to key feature implementation. Part of the reason has been the design strategy and code changes by various teams.

==Email notification feature to scheduled tasks==
This is a feature that has already been partially implemented in Expertiza [https://github.com/expertiza/expertiza/pull/445 E1451] implemented both sychronous and asychoronous mailers. Sychronous Emails refer to the Emails sent immediatly after an event (e.g. when student receive a peer-review). Asychoronous Email we implemented by the Gem "delayed job” and when a task (asychronous Email) is added to the delayed queue, a count-down number of minutes needs to be specified. 

Our team aims to extend this project. This wiki page documents the problem analysis and provides a guideline for future development and enhancement.

__TOC__

=Scope=
==Project Scope==
E1451. Create Mailers for All Email Messages [https://github.com/expertiza/expertiza/pull/445 github] [http://wiki.expertiza.ncsu.edu/index.php/CSC/ECE_517_Fall_2014/OSS_E1451_las wiki] [http://expertiza.ncsu.edu/submitted_content/download/28122?current_folder%5Bname%5D=%2Flocal%2Frails%2Fexpertiza%2Freleases%2F20140702225848%2Fpg_data%2Fefg%2Fcsc517%2Ff14%2F%2F18&download=E1451_Report.pdf report] (Merged in [https://docs.google.com/a/ncsu.edu/document/d/1aypHb5UOe-3nPfruNeh2HZjeT-wfv6f-ZsZg2jDMNkQ/edit E1483])

Extending this project, the new system should be capable of
*If one task is added to the delayed job queue, the asychronous Email should be updated or deleted automatically.
*Add UI to visualize for the task in delayed job queue, instructors should be able to view tasks related to the assignments they have created.
*Keep log of the scheduled tasks when they are scheduled and done, record events in the same log as project [https://github.com/expertiza/expertiza/pull/462 E1478].
*[optional] support more scheduled task:
**instructors are able to schedule the time to drop all the outstanding reviews (reviews which has not been started)
**instructors are able to schedule a specific time to send Emails to all the assignment participants who are still not in any team to find or form one.
**(new) instructor should be able to schedule a time to drop all the topics which are held by 1 person teams.
*create tests to make sure the test coverage increases.
==Files Involved==
Mailers:
*delayed_mailer.rb

Models:
*assignment_form.rb
*due_date.rb
*delayed_job.rb(new created)
*scheduled_task.rb(new created)

Views:
*_due_dates.html.erb
*_assignments_actions.html.erb
* scheduled_tasks.erb(new created)

Controllers:
*assignments_controller.rb

==Gems Related==
*gem 'delayed_job_active_record'

[https://github.com/collectiveidea/delayed_job Delayed:Job] encapsulates the common pattern of asynchronously executing longer tasks in the background<ref> [https://github.com/collectiveidea/delayed_job Delayed_job Gem]</ref>. It allows to support multiple backends for storing the job queue. By using 'delayed_job_active_record' gem, we can use delayed_job with Active Record. This Active Record backend requires a job table.

After running rails generate delayed_job:active_record and rake db:migrate, a "delayed_jobs" table is created in our database. This gem integrates well with many [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS] backend such as MySQL. Using this gem, we can store all scheduled tasks queue into the "delayed_jobs" table.

*gem 'paper_trail'
PaperTrail allows to track changes of models' data, which is good for versioning. You can see how a model looked at any stage in its lifecycle, revert it to any version, and even undelete it after it's been destroyed<ref>[https://github.com/airblade/paper_trail Paper_trail Gem]</ref>. Using this gem, we can keep log of the scheduled tasks.

=Problem Analysis=

== Time Issues==

Initially, when we want to verify the email function, we found many time issues in this system. That blocks our work about email notification. Some related problems are explained and analyzed in this section.

===Wrong displayed time===

Firstly, when we set a due time to test the mail features, we found the display of time is incorrect.

In the “Assignment Edit”->“Due dates”, when we modify the “Date & time” of the deadline, the displayed time will be 4 hours ahead of the time we saved. 

[[File:Wrong display of time.png‎ |frame|center|Set due time]]

[[File:Wrong display of time 2.png |frame|center|After we click the save button, we can see that all the time are 4 hours ahead of the set time]]

[[File:database_deadline.png |frame|center|The deadline time is stored correct in the database]]

After several tries, we found that every time when we click "save", the saved time is 4 hours earlier then the last saved time. However, the time in the database is alway correct as the time we save. After we analyze, we found the problem may lay in the line of 68 of <code>views/assignment/edit/_due_dates.html.erb</code> file.

<pre>due_at = new Date(due_at.substr(0, 16)).format('yyyy/mm/dd HH:MM');</pre>

When we declare a Data object, this Data() function will perform a time zone conversion automatically. Yet Rails’ default timezone stored in database is UTC. So the displayed time(local time, which is EDT) and time in database is different.

===Different time zone===

In the previous version, when current time is compared with the time stored in database, they may apply to different time zones so that the result of comparison may be wrong. 
When we delay a deadline of an assignment, for example, we set the deadline of metareview from2015/03/28 16:00 to 2015/04/04 20:00 and set the reminder hr to 16 hours.

[[File:Delayassign.png |frame|center|Delay a time]]

After click "save", the run time showed database is about 8:00 am. Since 20-16=4, the correct run time is 4:00 am.

[[File:delaydatabase.png |frame|center|Time Stored in Database]]

The reason why there is a four-hour time difference is generated from the file <code>application_form.rb</code>, method <code> find_min_from_now(due_at)</code>, and line 142 <code>time_in_min=((due_at - curr_time).to_i/60)</code>. <code> due_at </code> is the system time for Rails (UTC), while <code> curr_time </code> is the local time which is EDT. The two time zones have four-hour time difference. 

===New deadline replace the old one===
This time, we add a new delay in Review section, we delay the deadline from 2015/03/22 21:00 to 2015/03/30 21:00, and set the remind hr to 8 hours.

[[File:delayagain.png |frame|center|Delay a new deadline type]]

However, the delayed_jobs database form is still the same, which means in one assignment there is only one reminder can work. 
As a result, we conclude that only one due_time record associated with different period exists in the database:
*In Expertiza, one assignment has several period, such as submission, review, metareview. Administrates are able to set and postpone due dates for each period separately.
*In the previous version, when the instructor postpone the review deadline and then postpone the submit deadline, the submit deadline’s modification will replace the the review deadline’s modification in database.
*In this case, if both of them need Email reminder, there will be no Email about the former modified deadline.
*After our analysis, we found the due time object is identified with assignment_id, instead of deadline type id.

==UI issues==
In the previous version, there is no UI to display the reminders of assignments. There is no way for instructors to view or delete their delayed tasks related to an assignment. We are going to add a button under Assignment->edit, and add a view to display all delayed jobs derived from the delayed_jobs table in our database.

=System Design=
==Fix Time Issues==
===Unified time zone===
We convert current time to the same time zone as the deadline stored in database. Then the result of comparison will be right so that it can be used for further usage.
In <code>app/models/assignment_form.rb</code>, we modified <code>curr_time=DateTime.now.to_s(:db)</code> to <code>curr_time=DateTime.now.in_time_zone(zone='UTC').to_s(:db)</code> in the <code>find_min_from_now</code> method, to make sure when calculating the minutes from now, the time zone is right. 
Also, to make sure the right display of time, when log in as a administrator, go to Profile and choose the Preferred Time Zone to be "(GMT-05:00) Eastern Time (US&Canada)".

===Separate deadline of each topic period===
In each Assignment, each deadline type (E.g review, submit, metareview) should has its own Email reminder time in the database. New postponed deadline of one type can only replace the same deadline type in the same assignment id category. This bug has been fixed by TA.

==Add UI to visualize for scheduled tasks==
All the scheduled tasks are in the <code>delayed_jobs</code> table in database, so the system will read from that table to show all the tasks‘ information. A new page is created to show all of those scheduled tasks and there is also a delete button for instructor to delete any task. Instructor can view this page via a <code>view delayed jobs</code> button in <code> assignment->edit </code>. 
The code in <code>app/models/assignment_form.rb</code> add the scheduled tasks into <code>delayed_jobs</code> table. 
<pre>
if diff>0
dj=DelayedJob.enqueue(ScheduledTask.new(@assignment.id, deadline_type, due_date.due_at.to_s(:db)),
1, diff.minutes.from_now)
change_item_type(dj.id)
due_date.update_attribute(:delayed_job_id, dj.id)

# If the deadline type is review, add a delayed job to drop outstanding review
if deadline_type == "review"
dj = DelayedJob.enqueue(ScheduledTask.new(@assignment.id, "drop_outstanding_reviews", due_date.due_at.to_s(:db)),
1, diff.minutes.from_now)
change_item_type(dj.id)
end

# If the deadline type is team_formation, add a delayed job to drop one member team
if deadline_type == "team_formation"
dj = DelayedJob.enqueue(ScheduledTask.new(@assignment.id, "drop_one_member_topics", due_date.due_at.to_s(:db)),
1, diff.minutes.from_now)
change_item_type(dj.id)
end
end
</pre>
After adding to the delayed_jobs, the database will store each task's assignment's id, deadline type, due date, task run time etc. 

[[File:delayedjobs.png |frame|center|the delayed jobs table in database]] 
We create a file <code>scheduled_tasks.erb</code> in the path: <code>/views/assignments</code> to show the form. In this file, we use a <code>@scheduled_jobs = DelayedJob.all </code> to read all datas from the "delayed_jobs" table. 
<pre>
<% @assignment = Assignment.find(params[:id]) %>
<h1>Scheduled tasks for <%= @assignment.name %> assignment</h1>
<% if flash[:notice] %>
<div class="flash_note"><%= flash_message :notice %></div>
<% end %>
<% @scheduled_jobs = DelayedJob.all %>
<table class="general">
<th width="25%">Deadline type #</th>
<th width="25%">Run time</th>
<th width="25%">Due date</th>
<th width="25 %">Action</th>
<th width="25 %">Delete</th>
<% i=1 %>
<% for delayed_job in @scheduled_jobs %>
<tr>
<% if delayed_job.handler.include? "assignment_id: #{@assignment.id}"%>
<% handler = delayed_job.handler.split()%>
<td><%= handler[5] %></td>
<td><%= delayed_job.run_at %></td>
<td><%= handler[7][1..-1] + ":" + handler[8][0..-2]%></td>
<% if handler[5] == "submission" %>
<td><%= " "%></td>
<%end%>
<% if handler[5] == "review" %>
<td><%= " "%></td>
<%end%>
<% if handler[5] == "metareview" %>
<td><%= " "%></td>
<%end%>
<% if handler[5] == "team_formation" %>
<td><%= "send email to ask students to form teams"%></td>
<%end%>
<% if handler[5] == "drop_outstanding_reviews" %>
<td><%= "drop outstanding reviews and send emails to those students"%></td>
<%end%>
<% if handler[5] == "drop_one_member_topics" %>
<td><%= "drop one member team topics and send emails to those students"%></td>
<%end%>
<td><%= link_to image_tag('delete_icon.png', :title => 'Delete'),
{:controller => 'assignments', :action => 'delete_scheduled_task',
:id => @assignment.id, :delayed_job_id => delayed_job.id}%></td>
<% end %>
</tr>
<% i=i+1 %>
<% end %>
</table>
<% session[:return_to] = request.url %>
 
<a href="javascript:history.back()">Back</a>
</pre> 
The following two pictures show our UI works. 
[[File:viewdelayedjobs.png |frame|center|add a button to display all scheduled tasks]] 
[[File:showscheduledtask.png|frame|center|The UI to show all the scheduled tasks]] 

==Keep log of the scheduled tasks==
According to the project [https://github.com/expertiza/expertiza/pull/462 E1478], there is a paper_trail<ref name = "Paper_trail Gem"> https://github.com/airblade/paper_trail]</ref> gem which can keep log of the models' data. What we need to do is let it also keep track of our scheduled task data. 
Since the gem need to work with <code>ActiveRecord 3+</code>, while <code>assignment_form</code> doesn't. So we created a new file named <code>delayed_job.rb</code> in <code>models</code> folder, add <code>has_paper_trail</code> in it. Then it is like: 
<pre>
class DelayedJob < Delayed::Job
has_paper_trail
end
</pre>
When the <code>delayed_jobs</code> table changes, a <code>Delayed::Backend::ActiveRecord::Job</code> record is automatically created in the log. In <code>assignment_form.rb</code>, we define a method to change the item type displayed in the log.
<pre>
def change_item_type(delayed_job_id)
log = Version.where(item_type: "Delayed::Backend::ActiveRecord::Job", item_id: delayed_job_id).first
log.update_attribute(:item_type, "ScheduledTask") #Change the item type in the log
end
</pre>
Then we call it in <code>add_to_delayed_queue</code> method of the same file. Every time when the <code>delayed_jobs</code> table has added or deleted or updated data, the log can keep track of them. The following picture shows what the log is after creating scheduled tasks. You can see a "Search log" under the "logout" button. 
[[File:scheduledtasklog.png|frame|center|four scheduled tasks are added in log]] 

==support more schedule tasks==

In our system, we would have four scheduled time: submission, review, metareview and team_formation. When due time comes, the system takes corresponding actions. These scheduled actions are called scheduled tasks.

[[File:Support more scheduled tasks.png|frame|center|Support more scheduled tasks]]

===Drop outstanding reviews===
In this task, instructors should be able to schedule a time to drop all the outstanding reviews, which means the reviews which has not been started. 

Firstly, we create a new deadline type called "drop_outstanding_reviews". When we set the review’s due date, add an item into “delayed job” queue at the same time( refer to "Add UI to visualize for scheduled tasks").
When the review is due, it will automatically call a method to find all the outstanding reviews (reviews which have not been started) in the database then delete them. 
There are two tables in the database to store the information about the reviews: <code>responses</code> and <code>response_maps </code>. 
<code>responses</code> is used to store all the submitted reviews while <code>response_maps</code> stores all the requested reviews, which means if one review has began it will not stored in <code>responses</code> table. Thus, we just need to find the review data in <code>response_maps</code> while not in <code>responses</code> for one assignment and delete them in database. 
We add a method in <code>/models/scheduled_task.rb</code> named <code>drop_outstanding_reviews</code> to drop those reviews. 
<pre>
def drop_outstanding_reviews
reviews = ResponseMap.where(reviewed_object_id: self.assignment_id)
for review in reviews
review_has_began = Response.where(map_id: review.id)
if review_has_began.size.zero?
review_to_drop = ResponseMap.where(id: review.id)
review_to_drop.first.destroy
end
end
end
</pre>
Then, add the following code in <code>perform</code> method of the same file to drop one specified assignment's outstanding reviews at the due time. 
<pre>
if(self.deadline_type == "drop_outstanding_reviews")
drop_outstanding_reviews
end
</pre>

===Send team formation Emails===
In this task, the instructors are able to schedule a specific time to send Emails to all the assignment participants who are still not in any team to find or form one.
We use a previously existed deadline type called "team_formation" and enable to set a team_formation's due date and a reminder under "Assignment->edit->due date". Then add an item into “delayed job” at the same time(refer to "Add UI to visualize for scheduled tasks"). When “delayed job” is triggered, it will automatically call a method to find all the assignment participants who are still not in any team in the database, and send Emails to them to find teammate.
<pre>
if(self.deadline_type == "team_formation")
assignment = Assignment.find(self.assignment_id)
if(assignment.team_assignment?)
emails = get_one_member_team
email_reminder(emails, self.deadline_type)
end
end
</pre>

===Drop one-person topics===
In this task, the instructor should be able to schedule a time to drop all the topics which are held by 1 person teams.
We create a new deadline type called "drop_one_member_topics". When deadline type is team_formation, we add an item to the "delayed_job" queue( refer to "Add UI to visualize for scheduled tasks").
Then when time is due, the system will call a method to find all the topics which are held by 1 person teams in the database, then the professor can drop those topics.
<pre>
def drop_one_member_topics
teams = TeamsUser.all.group(:team_id).count(:team_id)
for team_id in teams.keys
if teams[team_id] == 1
topic_to_drop = SignedUpUser.where(creator_id: team_id).first
if topic_to_drop#check if the one-person-team has signed up a topic
topic_to_drop.delete
end
end
end
end
</pre>
<pre>
if(self.deadline_type == "drop_one_member_topics")
assignment = Assignment.find(self.assignment_id)
if(assignment.team_assignment?)
drop_one_member_topics
end
end
</pre>

=Tests=
In this project, our jobs involve two gems as mentioned above. They are "Delayed Job", which can insert a job into queue and execute it at a certain time, and "Paper Trail", to log actions like create, update and destroy for a model. We write rspec tests to make sure that the functionality works well. In

=References=
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T22:26:50Z

Jli53: /* Deleting redundant button */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. <code>SignUpSheetController</code> is much longer, and has many more recent mods, but some methods of <code>SignUpController</code> seem more sophisticated than <code>SignUpSheetController</code>. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names <code>new</code>, <code>create</code>, <code>edit</code>, <code>delete</code>, etc. Functionality is divided differently than in a standard controller. a. <code>def confirm_topic(creator_id, topic_id, assignment_id)</code> b. <code>def delete_signup</code> c.<code>def delete_signup_for_topic(assignment_id,topic_id)</code> d. <code>def other_confirmed_topic_for_user(assignment_id, creator_id)</code> e. <code>def signup</code> f. <code>def slotAvailable?(topic_id)</code>
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to <code>SignupController</code> and/or <code>SignupSheetController</code>. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
* Some codes does not follow the [https://docs.google.com/a/ncsu.edu/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit Global Rules].

== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>.
*<code>SignUpSheetController</code> has all seven methods in <code>SignUpController</code> with same name. we found these functions are completely achieved via <code>SignUpSheetController</code>. And after test, we prove that codes in <code>SignUpController</code> never got executed when we ran the project.

=== RESTful style implementation ===
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
...
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
...
end
</pre>

And we need to change some references to the method:
<pre>
verify method: 'post', :only => [:destroy, :create, :update],
:redirect_to => {:action => :index}

SignUpTopic.reassign_topic(@user_id,params[:assignment_id], params[:id])
redirect_to action: 'index', id: params[:assignment_id]

signup_team(@assignment.id, @user_id, params[:id])
redirect_to action: 'index', id: params[:assignment_id]
</pre>
For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
...
<% end %>
</pre>

the origin popup menu is as following picture, there is a<code>edit signup sheet </code>: 
[[File:originPopup.jpg]] 
The new popup menu is: 
[[File:new_popup.png]] 
After modifying, the other assignment functions all works well. 
[[File:AssignTopic.png]]

=== Renaming controller ===
According to the controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a controller should be a singular noun. However, here <code>SignUp</code> in camel case is a verb. We should modify it to a noun written as <code>Signup</code>. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name <code>sign_up_sheet_controller</code> is revised into <code>signup_sheet_controller</code> automatically. 
Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T22:25:55Z

Jli53: /* Renaming controller */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. <code>SignUpSheetController</code> is much longer, and has many more recent mods, but some methods of <code>SignUpController</code> seem more sophisticated than <code>SignUpSheetController</code>. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names <code>new</code>, <code>create</code>, <code>edit</code>, <code>delete</code>, etc. Functionality is divided differently than in a standard controller. a. <code>def confirm_topic(creator_id, topic_id, assignment_id)</code> b. <code>def delete_signup</code> c.<code>def delete_signup_for_topic(assignment_id,topic_id)</code> d. <code>def other_confirmed_topic_for_user(assignment_id, creator_id)</code> e. <code>def signup</code> f. <code>def slotAvailable?(topic_id)</code>
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to <code>SignupController</code> and/or <code>SignupSheetController</code>. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
* Some codes does not follow the [https://docs.google.com/a/ncsu.edu/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit Global Rules].

== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>.
*<code>SignUpSheetController</code> has all seven methods in <code>SignUpController</code> with same name. we found these functions are completely achieved via <code>SignUpSheetController</code>. And after test, we prove that codes in <code>SignUpController</code> never got executed when we ran the project.

=== RESTful style implementation ===
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
...
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
...
end
</pre>

And we need to change some references to the method:
<pre>
verify method: 'post', :only => [:destroy, :create, :update],
:redirect_to => {:action => :index}

SignUpTopic.reassign_topic(@user_id,params[:assignment_id], params[:id])
redirect_to action: 'index', id: params[:assignment_id]

signup_team(@assignment.id, @user_id, params[:id])
redirect_to action: 'index', id: params[:assignment_id]
</pre>
For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
...
<% end %>
</pre>

the origin popup menu is as following picture, there is a <code>: 
[[File:originPopup.jpg]] 
The new popup menu is: 
[[File:new_popup.png]] 
After modifying, the other assignment functions all works well. 
[[File:AssignTopic.png]]

>=== Renaming controller ===
According to the controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a controller should be a singular noun. However, here <code>SignUp</code> in camel case is a verb. We should modify it to a noun written as <code>Signup</code>. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name <code>sign_up_sheet_controller</code> is revised into <code>signup_sheet_controller</code> automatically. 
Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T22:06:29Z

Jli53: /* RESTful style implementation */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. <code>SignUpSheetController</code> is much longer, and has many more recent mods, but some methods of <code>SignUpController</code> seem more sophisticated than <code>SignUpSheetController</code>. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names <code>new</code>, <code>create</code>, <code>edit</code>, <code>delete</code>, etc. Functionality is divided differently than in a standard controller. a. <code>def confirm_topic(creator_id, topic_id, assignment_id)</code> b. <code>def delete_signup</code> c.<code>def delete_signup_for_topic(assignment_id,topic_id)</code> d. <code>def other_confirmed_topic_for_user(assignment_id, creator_id)</code> e. <code>def signup</code> f. <code>def slotAvailable?(topic_id)</code>
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to <code>SignupController</code> and/or <code>SignupSheetController</code>. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
* Some codes does not follow the [https://docs.google.com/a/ncsu.edu/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit Global Rules].

== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>.
*<code>SignUpSheetController</code> has all seven methods in <code>SignUpController</code> with same name. we found these functions are completely achieved via <code>SignUpSheetController</code>. And after test, we prove that codes in <code>SignUpController</code> never got executed when we ran the project.

=== RESTful style implementation ===
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
...
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
...
end
</pre>

And we need to change some references to the method:
<pre>
verify method: 'post', :only => [:destroy, :create, :update],
:redirect_to => {:action => :index}

SignUpTopic.reassign_topic(@user_id,params[:assignment_id], params[:id])
redirect_to action: 'index', id: params[:assignment_id]

signup_team(@assignment.id, @user_id, params[:id])
redirect_to action: 'index', id: params[:assignment_id]
</pre>
For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
...
<% end %>
</pre>
the origin popup menu is as following picture, there is a <code>: 
[[File:originPopup.jpg]] 
The new popup menu is: 
[[File:Example.jpg]] 
After modifying, the other assignment functions all works well. 
[[File:AssignTopic.png]]

=== Renaming controller ===
According to the controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a controller should be a singular noun. However, here <code>SignUp</code> in camel case is a verb. We should modify it to a noun written as <code>Signup</code>. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name <code>sign_up_sheet_controller</code> is revised into <code>signup_sheet_controller</code> automatically. 
Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T22:04:43Z

Jli53: /* RESTful style implementation */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. <code>SignUpSheetController</code> is much longer, and has many more recent mods, but some methods of <code>SignUpController</code> seem more sophisticated than <code>SignUpSheetController</code>. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names <code>new</code>, <code>create</code>, <code>edit</code>, <code>delete</code>, etc. Functionality is divided differently than in a standard controller. a. <code>def confirm_topic(creator_id, topic_id, assignment_id)</code> b. <code>def delete_signup</code> c.<code>def delete_signup_for_topic(assignment_id,topic_id)</code> d. <code>def other_confirmed_topic_for_user(assignment_id, creator_id)</code> e. <code>def signup</code> f. <code>def slotAvailable?(topic_id)</code>
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to <code>SignupController</code> and/or <code>SignupSheetController</code>. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
* Some codes does not follow the [https://docs.google.com/a/ncsu.edu/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit Global Rules].

== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>.
*<code>SignUpSheetController</code> has all seven methods in <code>SignUpController</code> with same name. we found these functions are completely achieved via <code>SignUpSheetController</code>. And after test, we prove that codes in <code>SignUpController</code> never got executed when we ran the project.

=== RESTful style implementation ===
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
...
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
...
end
</pre>

And we need to change some references to the method:
<pre>
verify method: 'post', :only => [:destroy, :create, :update],
:redirect_to => {:action => :index}

SignUpTopic.reassign_topic(@user_id,params[:assignment_id], params[:id])
redirect_to action: 'index', id: params[:assignment_id]
</pre>
For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
...
<% end %>
</pre>
the origin popup menu is as following picture, there is a <code>: 
[[File:originPopup.jpg]] 
The new popup menu is: 
[[File:Example.jpg]] 
After modifying, the other assignment functions all works well. 
[[File:AssignTopic.png]]

=== Renaming controller ===
According to the controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a controller should be a singular noun. However, here <code>SignUp</code> in camel case is a verb. We should modify it to a noun written as <code>Signup</code>. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name <code>sign_up_sheet_controller</code> is revised into <code>signup_sheet_controller</code> automatically. 
Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T22:04:14Z

Jli53: /* RESTful style implementation */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. <code>SignUpSheetController</code> is much longer, and has many more recent mods, but some methods of <code>SignUpController</code> seem more sophisticated than <code>SignUpSheetController</code>. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names <code>new</code>, <code>create</code>, <code>edit</code>, <code>delete</code>, etc. Functionality is divided differently than in a standard controller. a. <code>def confirm_topic(creator_id, topic_id, assignment_id)</code> b. <code>def delete_signup</code> c.<code>def delete_signup_for_topic(assignment_id,topic_id)</code> d. <code>def other_confirmed_topic_for_user(assignment_id, creator_id)</code> e. <code>def signup</code> f. <code>def slotAvailable?(topic_id)</code>
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to <code>SignupController</code> and/or <code>SignupSheetController</code>. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
* Some codes does not follow the [https://docs.google.com/a/ncsu.edu/document/d/1qQD7fcypFk77nq7Jx7ZNyCNpLyt1oXKaq5G-W7zkV3k/edit Global Rules].

== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>.
*<code>SignUpSheetController</code> has all seven methods in <code>SignUpController</code> with same name. we found these functions are completely achieved via <code>SignUpSheetController</code>. And after test, we prove that codes in <code>SignUpController</code> never got executed when we ran the project.

=== RESTful style implementation ===
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
...
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
...
end
</pre>

And we need to change some references to the method:
<pre>
verify method: 'post', :only => [:destroy, :create, :update],
:redirect_to => {:action => :index}

SignUpTopic.reassign_topic(@user_id,params[:assignment_id], params[:id])
redirect_to action: 'index', id: params[:assignment_id]
</pre>
For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
...
<% end %>
</pre>
the origin popup menu is as following picture, there is a <code>: 
[[File:originPopup.jpg]] 
The new popup menu is: 
[[File:Example.jpg]] 
After modifying, the other assignment functions all works well. 
[[File:AssignTopic.png]]

=== Renaming controller ===
According to the controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a controller should be a singular noun. However, here <code>SignUp</code> in camel case is a verb. We should modify it to a noun written as <code>Signup</code>. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name <code>sign_up_sheet_controller</code> is revised into <code>signup_sheet_controller</code> automatically. 
Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T21:39:50Z

Jli53: /* Following global rules */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. <code>SignUpSheetController</code> is much longer, and has many more recent mods, but some methods of <code>SignUpController</code> seem more sophisticated than <code>SignUpSheetController</code>. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names <code>new</code>, <code>create</code>, <code>edit</code>, <code>delete</code>, etc. Functionality is divided differently than in a standard controller. a. <code>def confirm_topic(creator_id, topic_id, assignment_id)</code> b. <code>def delete_signup</code> c.<code>def delete_signup_for_topic(assignment_id,topic_id)</code> d. <code>def other_confirmed_topic_for_user(assignment_id, creator_id)</code> e. <code>def signup</code> f. <code>def slotAvailable?(topic_id)</code>
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to <code>SignupController</code> and/or <code>SignupSheetController</code>. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
* Some codes does not follow the Global Rules.

== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>
*
*

=== RESTful style implementation ===
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
...
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
...
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"),
:controller => 'lottery', :action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>
the origin popup menu is:
[[File:originPopup.jpg]]

=== Renaming controller ===
According to the controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a controller should be a singular noun. However, here <code>SignUp</code> in camel case is a verb. We should modify it to a noun written as <code>Signup</code>. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name <code>sign_up_sheet_controller</code> is revised into <code>signup_sheet_controller</code> automatically. 
Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T21:39:06Z

Jli53: /* What's wrong with it */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. <code>SignUpSheetController</code> is much longer, and has many more recent mods, but some methods of <code>SignUpController</code> seem more sophisticated than <code>SignUpSheetController</code>. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names <code>new</code>, <code>create</code>, <code>edit</code>, <code>delete</code>, etc. Functionality is divided differently than in a standard controller. a. <code>def confirm_topic(creator_id, topic_id, assignment_id)</code> b. <code>def delete_signup</code> c.<code>def delete_signup_for_topic(assignment_id,topic_id)</code> d. <code>def other_confirmed_topic_for_user(assignment_id, creator_id)</code> e. <code>def signup</code> f. <code>def slotAvailable?(topic_id)</code>
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to <code>SignupController</code> and/or <code>SignupSheetController</code>. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
* Some codes does not follow the Global Rules.

== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>
*
*

=== RESTful style implementation ===
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
...
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
...
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"),
:controller => 'lottery', :action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>
the origin popup menu is:
[[File:originPopup.jpg]]

=== Renaming controller ===
According to the controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a controller should be a singular noun. However, here <code>SignUp</code> in camel case is a verb. We should modify it to a noun written as <code>Signup</code>. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name <code>sign_up_sheet_controller</code> is revised into <code>signup_sheet_controller</code> automatically. 
Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
----
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T21:32:22Z

Jli53: /* Breaking down long methods */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. <code>SignUpSheetController</code> is much longer, and has many more recent mods, but some methods of <code>SignUpController</code> seem more sophisticated than <code>SignUpSheetController</code>. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names <code>new</code>, <code>create</code>, <code>edit</code>, <code>delete</code>, etc. Functionality is divided differently than in a standard controller. a. <code>def confirm_topic(creator_id, topic_id, assignment_id)</code> b. <code>def delete_signup</code> c.<code>def delete_signup_for_topic(assignment_id,topic_id)</code> d. <code>def other_confirmed_topic_for_user(assignment_id, creator_id)</code> e. <code>def signup</code> f. <code>def slotAvailable?(topic_id)</code>
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to <code>SignupController</code> and/or <code>SignupSheetController</code>. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)

== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>
*
*

=== RESTful style implementation ===
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
...
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
...
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"),
:controller => 'lottery', :action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>
the origin popup menu is:
[[File:originPopup.jpg]]

=== Renaming controller ===
According to the controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a controller should be a singular noun. However, here <code>SignUp</code> in camel case is a verb. We should modify it to a noun written as <code>Signup</code>. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name<code>sign_up_sheet_controller</code> is revised into <signup_sheet_controller> automatically. Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
----
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T21:26:04Z

Jli53: /* Breaking down long methods */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>
*
*

=== RESTful style implementation ===
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
...
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
...
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + params[:id].to_s)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"),
:controller => 'lottery', :action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>
the origin popup menu is:
[[File:originPopup.jpg]]

=== Renaming controller ===
According to the controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a controller should be a singular noun. However, here <code>SignUp</code> in camel case is a verb. We should modify it to a noun written as <code>Signup</code>. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name<code>sign_up_sheet_controller</code> is revised into <signup_sheet_controller> automatically. Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
----
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T21:22:57Z

Jli53: /* RESTful style implementation */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>
*
*

=== RESTful style implementation ===
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
...
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
...
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"),
:controller => 'lottery', :action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>
the origin popup menu is:
[[File:Example.jpg]]

=== Renaming controller ===
According to the controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a controller should be a singular noun. However, here <code>SignUp</code> in camel case is a verb. We should modify it to a noun written as <code>Signup</code>. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name<code>sign_up_sheet_controller</code> is revised into <signup_sheet_controller> automatically. Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
----
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T21:18:23Z

Jli53: /* Removing unused controller */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>
*
*

=== RESTful style implementation ===
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"),
:controller => 'lottery', :action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>

=== Renaming controller ===
According to the Controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a Controller should be a singular noun. However, here SignUp in camel case is a verb. We should modify it to a noun written as Signup. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name<code>sign_up_sheet_controller</code> is revised into <signup_sheet_controller> automatically. Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
----
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T21:17:20Z

Jli53: /* RESTful style implementation */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.
The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>
*
*

=== RESTful style implementation ===
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"),
:controller => 'lottery', :action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>

=== Renaming controller ===
According to the Controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a Controller should be a singular noun. However, here SignUp in camel case is a verb. We should modify it to a noun written as Signup. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name<code>sign_up_sheet_controller</code> is revised into <signup_sheet_controller> automatically. Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
----
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T21:15:35Z

Jli53: /* Following global rules */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.
The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>
*
*

=== RESTful style implementation ===
----
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"),
:controller => 'lottery', :action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>

=== Renaming controller ===
According to the Controller name convention<ref>http://guides.rubyonrails.org/action_controller_overview.html</ref>, a Controller should be a singular noun. However, here SignUp in camel case is a verb. We should modify it to a noun written as Signup. As a result, we rename all class name <code>SignUpSheetController</code> to <code>SignupSheetController</code>. Then the controller name<code>sign_up_sheet_controller</code> is revised into <signup_sheet_controller> automatically. Here we also make sure every reference for this controller has been changed to match the new controller name. For example, in <code>views/signup_sheet/_action.html.erb</code> file, we must make sure this render path is correct as follows:
<pre>
<%= render :partial => '/signup_sheet/all_actions', :locals => {:i=>i, :topic=>topic} %>
</pre>

=== Following global rules ===
----
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T21:15:12Z

Jli53: /* Following global rules */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.
The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>
*
*

=== RESTful style implementation ===
----
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"),
:controller => 'lottery', :action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>

=== Renaming controller ===
=== Following global rules ===
----
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered',:id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T21:14:41Z

Jli53: /* Following global rules */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.
The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>
*
*

=== RESTful style implementation ===
----
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"),
:controller => 'lottery', :action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>

=== Renaming controller ===
=== Following global rules ===
----
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are some of what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T21:14:19Z

Jli53: /* Following global rules */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
After various analysis and test, we found <code>SignUpController</code> is never used. So we remove it. The reasons are listed as follows:
* There is no code about <code>SignUpController</code> in <code>route.rb</code> file.
The Rails router recognizes URLs and dispatches them to a controller's action. It can also generate paths and URLs, avoiding the need to hardcode strings in your views<ref>http://guides.rubyonrails.org/routing.html#the-purpose-of-the-rails-router</ref>. Rails default routing is resource routing, which allows us to declare all the common routes for a resourceful controller. In our <code>route.rb</code>, we found a matching resourceful route for <code>SignUpSheetController</code>, which asks the router to map it to the <code>SignUpSheetController</code> action.

<pre>
resources :signup_sheet
</pre>

This route creates several different routes in the application, all mapping to the <code>SignUpSheetController</code> controller.
Here are some examples:

{| class="wikitable"
|-
! style="width:13%;"|HTTP Verb
! style="width:33%;"|Controller#Action
! style="width:43%;"|Used For
|- style="vertical-align:top;"
| GET
| sigh_up_sheet#signup
| This function lets the user choose a particular topic.
|-
| GET
| sigh_up_sheet#delete_signup
| This function is used to delete a previous signup
|-
| GET
| sigh_up_sheet#view_publishing_rights
| The function is to make sure the publishing rights for a user
|}
However, there is not a matching route for <code>SignUpController</code>
*
*

=== RESTful style implementation ===
----
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in<code> sign_up_topic.rb</code>
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring: 
In <code>signup_sheet_controller.rb</code>:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in <code>sign_up_topic.rb</code>
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change. 
We delete the following lines in <code>app/views/tree_display/actions/_assignments_actions.html.erb</code>
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"),
:controller => 'lottery', :action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action =>
'add_signup_topics', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>

=== Renaming controller ===
=== Following global rules ===
----
According to Global Rules, there are some codes that need some improvements to make it follow the rules correctly. Here are what we have done:

* change <code>users_team.size == 0</code> to <code>users_team.zero?</code>
<pre>
change:
if users_team.size == 0
to:
if users_team.zero?
or:
if users_team.empty?
</pre>

* Use <code>key: 'value'</code>, not <code>:key => 'value'</code>
<pre>
change:
redirect_to :action => 'add_signup_topics_staggered', :id => assignment_id
to:
redirect_to action: 'add_signup_topics_staggered', id: assignment_id
</pre>

* Use <code>if (var)</code> instead of <code>if (var == true)</code>
<pre>
change:
(assignment.staggered_deadline == true)?
to:
(assignment.staggered_deadline)?
</pre>

== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:50:54Z

Jli53: /* RESTful style implementation */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
=== RESTful style implementation ===
----
The purpose of the <code>list</code> method in the <code>SignupSheet controller</code> is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as <code>index</code>. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: <code>list</code>
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method: <code>index</code>
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, <code>create</code> function creates topics, which is one of the administrator’s functions. However <code>signup</code> creates a record that includes information for topic and student, which happens when student clicks <code>signup</code> button. We can see that <code>create</code> and <code>signup</code> are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring: 
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring: 
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change.
We delete the following lines in app/views/tree_display/actions/_assignments_actions.html.erb
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"), :controller => 'lottery',
:action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered',
:id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>

=== Renaming controller ===
=== Following global rules ===
== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:48:44Z

Jli53: /* Breaking down long methods */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
=== RESTful style implementation ===
----
The purpose of the list method in the SignupSheet controller is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as index. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: list
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method: index
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, create function creates topics, which is one of the administrator’s functions. However signup creates a record that includes information for topic and student, which happens when student clicks signup button. We can see that create and signup are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring: 
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring: 
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring: 
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring: 
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions <code>update_topic_info</code> and <code>check_after_create</code> from <code>create</code>. And we call these two functions in <code>create</code> method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: <code>update_topic_info</code>, <code>check_after_create</code>, <code>create</code>
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method <code>update_topic_info</code> updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function <code>create</code> because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method <code>check_after_create</code> check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from <code>create</code> function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In <code>create</code> method, the two separated methods were called. By this way, function <code>create</code> will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change.
We delete the following lines in app/views/tree_display/actions/_assignments_actions.html.erb
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"), :controller => 'lottery',
:action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered',
:id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id},
{:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>

=== Renaming controller ===
=== Following global rules ===
== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:38:54Z

Jli53: /* Breaking down long methods */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
=== RESTful style implementation ===
----
The purpose of the list method in the SignupSheet controller is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as index. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: list
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method: index
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, create function creates topics, which is one of the administrator’s functions. However signup creates a record that includes information for topic and student, which happens when student clicks signup button. We can see that create and signup are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions “update_topic_info” and “check_after_create” from “create”. And we call these two functions in “create” method instead of executing these codes directly.

Before Refactoring:
 Method: <code>create</code>
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: update_topic_info, check_after_create, create
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method update_topic_info updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function create because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method check_after_create check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from create function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In create method, the two separated methods were called. By this way, function create will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a redundant button since there already has such a function in Assignment "Edit" menu. What's more it's more reasonable to put this function in "Edit" Assignment because signup sheet is a part of the assignment. So we removed this button. Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change.
We delete the following lines in app/views/tree_display/actions/_assignments_actions.html.erb
<pre>
<% if signup_topic %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/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('/assets/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 %>
<% if @assignment.is_intelligent %>
<%= link_to image_tag('/assets/tree_view/run-lottery.png', :title => 'Assign teams intelligently', :onClick => "showIntelligentAssignmentDialog()"), :controller => 'lottery', :action => 'run_intelligent_bid', :id => @assignment.id %>
<% end %>
<script type="text/javascript">
function showIntelligentAssignmentDialog() {
jQuery( "#intelligent_assignment_dialog" ).dialog({ closeText: "hide", modal: true, resizable: false, width: 500 });
}
</script>
<div id="intelligent_assignment_dialog" title="Running intelligent assignment" style="display: none;">
Intelligent Assignment is running. Please wait for the action to be completed.
</div>
<% else %>
<% if @assignment.staggered_deadline == true %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action => 'add_signup_topics_staggered', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% else %>
<%= link_to image_tag('/assets/tree_view/add-signup-sheet-24.png', :title => 'Add signup sheet'), {:controller => 'sign_up_sheet', :action => 'add_signup_topics', :id => node.node_object_id}, {:title => 'Add signup sheet'} %>
<% end %>
<% end %>
</pre>

=== Renaming controller ===
=== Following global rules ===
== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:35:37Z

Jli53: /* Breaking down long methods */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
=== RESTful style implementation ===
----
The purpose of the list method in the SignupSheet controller is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as index. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: list
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method: index
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, create function creates topics, which is one of the administrator’s functions. However signup creates a record that includes information for topic and student, which happens when student clicks signup button. We can see that create and signup are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions “update_topic_info” and “check_after_create” from “create”. And we call these two functions in “create” method instead of executing these codes directly.

Before Refactoring:
 Method: create
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method: update_topic_info, check_after_create, create
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method update_topic_info updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function create because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method check_after_create check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from create function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In create method, the two separated methods were called. By this way, function create will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a since there already has such a function in Assignment "Edit" menu.
app/views/tree_display/actions/_assignments_actions.html.erb
Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change.

=== Renaming controller ===
=== Following global rules ===
== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:31:24Z

Jli53: /* RESTful style implementation */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
=== RESTful style implementation ===
----
The purpose of the list method in the SignupSheet controller is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as index. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: list
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method: index
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, create function creates topics, which is one of the administrator’s functions. However signup creates a record that includes information for topic and student, which happens when student clicks signup button. We can see that create and signup are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions “update_topic_info” and “check_after_create” from “create”. And we call these two functions in “create” method instead of executing these codes directly.

Before Refactoring :
 Method : create
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method : update_topic_info, check_after_create, create
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method update_topic_info updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function create because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method check_after_create check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from create function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In create method, the two separated methods were called. By this way, function create will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a since there already has such a function in Assignment "Edit" menu.
app/views/tree_display/actions/_assignments_actions.html.erb
Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change.

=== Renaming controller ===
=== Following global rules ===
== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:31:03Z

Jli53: /* RESTful style implementation */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
=== RESTful style implementation ===
----
The purpose of the list method in the SignupSheet controller is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as index. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
Method: list
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
Method: index
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, create function creates topics, which is one of the administrator’s functions. However signup creates a record that includes information for topic and student, which happens when student clicks signup button. We can see that create and signup are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions “update_topic_info” and “check_after_create” from “create”. And we call these two functions in “create” method instead of executing these codes directly.

Before Refactoring :
 Method : create
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method : update_topic_info, check_after_create, create
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method update_topic_info updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function create because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method check_after_create check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from create function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In create method, the two separated methods were called. By this way, function create will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a since there already has such a function in Assignment "Edit" menu.
app/views/tree_display/actions/_assignments_actions.html.erb
Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change.

=== Renaming controller ===
=== Following global rules ===
== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:30:29Z

Jli53: /* RESTful style implementation */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
=== RESTful style implementation ===
----
The purpose of the list method in the SignupSheet controller is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as index. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method: list
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method: index
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, create function creates topics, which is one of the administrator’s functions. However signup creates a record that includes information for topic and student, which happens when student clicks signup button. We can see that create and signup are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions “update_topic_info” and “check_after_create” from “create”. And we call these two functions in “create” method instead of executing these codes directly.

Before Refactoring :
 Method : create
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method : update_topic_info, check_after_create, create
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method update_topic_info updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function create because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method check_after_create check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from create function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In create method, the two separated methods were called. By this way, function create will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a since there already has such a function in Assignment "Edit" menu.
app/views/tree_display/actions/_assignments_actions.html.erb
Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change.

=== Renaming controller ===
=== Following global rules ===
== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:29:59Z

Jli53: /* RESTful style implementation */

== E1509. Refactoring SignUpController and SignUpSheetController ==

This page talks about an open source project based on Expertiza. As a part of contribution to Expertiza, this project aims to refactor SignUpController and SignUpSheetControllers.

=== Introduction to Expertiza ===

[http://expertiza.ncsu.edu/ Expertiza] is a web application developed by Ruby on Rails framework. It serves as a peer review system for professors and students at NC State and some other colleges and universities. Students can submit different assignments and peer-review reusable learning objects (articles, code, web sites, etc)<ref>https://github.com/expertiza/expertiza</ref>. The Expertiza project is supported by the National Science Foundation. And it is an open source application and the source code can be cloned on [https://github.com/expertiza/expertiza Github] .

== Problem Statement ==

===Classes involved===
<pre>
* sign_up_sheet.rb
* sign_up_topic.rb
* assignments_controller.rb
* response.rb
* and possibly other model classes
</pre>
===What it does===

Lists topics available for an assignment, checks whether a user is signed up for a topic, allows users to sign up for topics.

===What's wrong with it===
* These two controllers seem to do almost the same thing. They have many of the same methods. SignUpSheetController is much longer, and has many more recent mods, but some methods of SignUpController seem more sophisticated than SignUpSheetController. So, your first job is to figure out if both controllers are being used. If not, remove the unused controller. Or, move the functions to a single controller if that makes sense to do.
* Neither controller is at all RESTful; i.e.., its method names aren’t the standard names new, create, edit, delete, etc. Functionality is divided differently than in a standard controller.
a. def confirm_topic(creator_id, topic_id, assignment_id) 
b. def delete_signup 
c. def delete_signup_for_topic(assignment_id,topic_id) 
d. def other_confirmed_topic_for_user(assignment_id, creator_id) 
e. def signup 
f. def slotAvailable?(topic_id)
* Functionality that should be in models is incorporated into the controller.
* Some methods are too long and appear to do more than one thing
* This class interfaces with assignments_controller so that a list of topics can be displayed when one is editing an assignment. Please be careful that your changes do not affect the functionality on the Topics tab of editing an assignment.
* Rename the controller(s) to SignupController and/or SignupSheetController. (“Sign up”, which gets written as SignUp in camel case, is a verb, whereas “Signup” is a noun.)
== Modification We Made ==
=== Removing unused controller ===
=== RESTful style implementation ===
----
The purpose of the list method in the SignupSheet controller is to list all the topics in the specific assignments. According to RESTful rules, a method that returns a list of all available objects should be named as index. Therefore, we renamed the list method to the index method in the controller and in all the files that had references to the list method of the signup_sheet_controller.

Before Refactoring:
 Method : list
<pre>
def list
@assignment_id = params[:id]
@sign_up_topics = SignUpTopic.where( ['assignment_id = ?', params[:id]]).all
@slots_filled = SignUpTopic.find_slots_filled(params[:id])
@slots_waitlisted = SignUpTopic.find_slots_waitlisted(params[:id])
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])

if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignUpSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

After Refactoring:
 Method : index
<pre>
def index
@assignment_id = params[:id]
@sign_up_topics =SignUpTopic.find_with_assignment_id( params[:id]).all
filled_and_waitlisted_topics(@assignment_id)
@show_actions = true
@priority = 0
assignment=Assignment.find(params[:id])
if assignment.due_dates.find_by_deadline_type_id(1)!= nil
unless !(assignment.staggered_deadline? and assignment.due_dates.find_by_deadline_type_id(1).due_at < Time.now )
@show_actions = false
end
users_team = SignedUpUser.find_team_users(params[:id],(session[:user].id))
if users_team.size == 0
@selected_topics = nil
else
@selected_topics = SignupSheetController.other_confirmed_topic_for_user(params[:id], users_team[0].t_id)
end
SignUpTopic.remove_team(users_team, @assignment_id)
end
end
</pre>

For some others, it is not good to combine some functions with the standard ones. For example, create function creates topics, which is one of the administrator’s functions. However signup creates a record that includes information for topic and student, which happens when student clicks signup button. We can see that create and signup are designed for different role and different usage so it is not a good idea to combine them together.

=== Moving inappropriate functionality from controller to model ===
----
The controller connects the model with the view. In Rails, controllers are implemented as ActionController classes. The controller knows how to process the data that comes from the model and how to pass it onto the view. The controller should not include any database related actions (such as modifying data before it gets saved inside the database). This should be handled in the proper model. So we remove all the database related functionality in the signup_sheet_controller to related models.
The following files were modified:
<pre>
app/controllers/signup_sheet_controller.rb
app/models/deadline_type.rb
app/models/due_date.rb
app/models/participant.rb
app/models/sign_up_topic.rb
app/models/signed_up_user.rb
app/models/topic_deadline.rb
app/models/topic_dependency.rb
</pre>
Here are two examples on how these files changed. 
1. replace "where" in the controller with a new method in related model. 
Before Refactoring
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>

After Refactoring
In signup_sheet_controller.rb:
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
#if the topic already exists then update
if topic
update_topic_info(topic)
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_with_name_and_assignment_id(name, aid)
SignUpTopic.where(topic_name: name, assignment_id: aid)
end
</pre>
2. replace "find_by_sql" in the controller with a new method in related model. 
Before Refactoring
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.where(assignment_id: params[:id])
#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)
unless @topics.nil?
</pre>

After Refactoring
In signup_sheet_controller.rb:
<pre>
def set_duedate_info
@review_rounds = Assignment.find(params[:id]).get_review_rounds
@topics = SignUpTopic.find_with_assignment_id( params[:id])
#Use this until you figure out how to initialize this array
@duedates = SignUpTopic.find_topic_id_with_assignment_id(params[:id].to_s)
unless @topics.nil?
</pre>
Also add a related method in sign_up_topic.rb
<pre>
def find_topic_id_with_assignment_id(aid)
SignUpTopic.find_by_sql("SELECT s.id as topic_id FROM sign_up_topics s WHERE s.assignment_id = " + aid)
end
</pre>

=== Breaking down long methods ===
----
We’ve find that lots of methods do more than one thing so we separate a long function into several concise functions and call them in the original function. Here is an example:

There are some preparation works and check works before or after the actual create operation. So we separate two functions “update_topic_info” and “check_after_create” from “create”. And we call these two functions in “create” method instead of executing these codes directly.

Before Refactoring :
 Method : create
<pre>
def create
topic = SignUpTopic.where(topic_name: params[:topic][:topic_name], assignment_id: params[:id]).first
if topic != nil
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_by_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render :action => 'new', :id => params[:id]
end
end
end
</pre>

After Refactoring
 Method : update_topic_info, check_after_create, create
<pre>
def update_topic_info(topic)
topic.topic_identifier = params[:topic][:topic_identifier]
if SignedUpUser.find_with_topic_id(topic.id).nil? || topic.max_choosers == params[:topic][:max_choosers]
topic.max_choosers = params[:topic][:max_choosers]
else
if topic.max_choosers.to_i < params[:topic][:max_choosers].to_i
topic.update_waitlisted_users(params[:topic][:max_choosers])
topic.max_choosers = params[:topic][:max_choosers]
else
flash[:error] = 'Value of maximum choosers can only be increased! No change has been made to max choosers.'
end
end
end
</pre>
The method update_topic_info updates topics' some attributes according to received parameters, such as permitted max number of choosers and waitlisted users. This method is separated from function create because it doesn't really do any creation works.
<pre>
def check_after_create
if @assignment.is_microtask?
@sign_up_topic.micropayment = params[:topic][:micropayment]
end
if @assignment.staggered_deadline?
topic_set = Array.new
topic = @sign_up_topic.id
end
end
</pre>
The method check_after_create check if the assignment is a microtask and if it applies to staggered deadline. If these two conditions are met, then execute corresponding actions. These steps should be separated from create function because it doesn't actually do works related with creation.
<pre>
def create
topic = SignUpTopic.find_with_name_and_assignment_id(params[:topic][:topic_name], params[:id]).first
if topic
update_topic_info(topic)
topic.category = params[:topic][:category]
topic.save
redirect_to_sign_up(params[:id])
else
set_values_for_new_topic
check_after_create
if @sign_up_topic.save
undo_link("Topic: \"#{@sign_up_topic.topic_name}\" has been created successfully. ")
redirect_to edit_assignment_path(@sign_up_topic.assignment_id) + "#tabs-5"
else
render action: 'new', id: params[:id]
end
end
end
</pre>
In create method, the two separated methods were called. By this way, function create will be much shorter and some works do not belong to it can be finished by other methods.

=== Deleting redundant button ===
----
When we move the mouse on the Assignment, there is a "Edit signup sheet" button in the popup menu. It is a since there already has such a function in Assignment "Edit" menu.
app/views/tree_display/actions/_assignments_actions.html.erb
Sometimes after making some changes, the display topics function didn’t work due to some reasons. We’ve fixed those bugs and make sure it still works after our last change.

=== Renaming controller ===
=== Following global rules ===
== References ==
<references/>

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:21:46Z

Jli53: /* Breaking down long methods */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:09:26Z

Jli53: /* Breaking down long methods */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:02:59Z

Jli53: /* Breaking down long methods */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:02:44Z

Jli53: /* Breaking down long methods */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T20:01:41Z

Jli53: /* Breaking down long methods */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T19:57:52Z

Jli53: /* Breaking down long methods */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T19:53:26Z

Jli53: /* Breaking down long methods */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T19:48:20Z

Jli53: /* RESTful style implementation */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T19:45:02Z

Jli53: /* RESTful style implementation */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T19:44:24Z

Jli53: /* RESTful style implementation */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T19:42:23Z

Jli53: /* RESTful style implementation */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T19:38:59Z

Jli53: /* RESTful style implementation */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T19:38:32Z

Jli53: /* RESTful style implementation */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T19:32:34Z

Jli53: /* RESTful style implementation */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T19:32:12Z

Jli53: /* RESTful style implementation */

CSC/ECE 517 Spring 2015/oss E1509 lds

2015-03-21T19:22:39Z

Jli53:

CSC/ECE 517 Spring 2015/ch1b 10 GL

2015-02-19T04:12:05Z

Jli53: /* Why using encrypted cookies */

Encrypted Cookies 

== Introduction ==
===Background===
A [http://en.wikipedia.org/wiki/HTTP_cookie cookie], sometimes called HTTP cookie<ref>http://en.wikipedia.org/wiki/HTTP_cookie</ref>, web cookie or browser cookie, is some data stored in a user’s web browser while visiting that website. Cookie is sent from web server and browser sends it back when the user loads the website, in order to notify the website of the user’s previous activity. Cookies were designed for web server to remember some user’s information or to record user’s browsing activity. (including clicking certain button, logging in, or recording which pages were visited by the user before) The most common example of this functionality is the shopping cart feature of any e-commerce site. When you visit one page of a catalog and select some items, the session cookie remembers your selection so your shopping cart will have the items you selected when you are ready to check out. Without session cookies, if you click “CHECKOUT”
, the new page does not recognize your past activities on prior pages and your shopping cart will always be empty<ref>http://www.allaboutcookies.org/</ref>.

In [http://rubyonrails.org/ Rails], we may get in touch with cookies when we learn session, which can be regarded as one of cookie’s usage because cookie-based session store is dramatically faster than the alternatives. Rails cookie based session storage was introduced as the default in 2007, version 2.0.0. In Rails 2 and Rails 3, the value of the cookie is a base64 encoded serialized string with an added signature. Session data is thus almost clear text. In Rails 4, the value of the cookie is an encrypted string. But if you have access to the source code of the application you can use the built-in infrastructure to decode the session.

===Why using encrypted cookies===
There are some other methods that sometimes are considered to replace encrypted cookies<ref>http://pothibo.com/2013/9/sessions-and-cookies-in-ruby-on-rails</ref>. Session data can be stored in server’s database. However this will cost more time and space when requesting session. Using cookies will dramatically increase the execution speed.
As for unencrypted cookie, its content can be seen without any restriction, which means anyone can see the content of cookies’ content. So it is absolutely unsafe to carry sensitive content in cookies. However, with encrypted cookies, it is possible that cookie can carry some sensitive data because the secure encryption algorithm.
And you probably are used to key-derivation encryption([https://github.com/codahale/bcrypt-ruby bcrypt], [http://en.wikipedia.org/wiki/PBKDF2 pbkdf2], etc). But these are not as useful as in passwords because they cannot be decrypted! However cookies need to be decrypted when they are received. So instead of a key-derivation function, Rails uses a cipher(by default [http://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES-256]) to encrypt and decrypt data.

==How it works==
====In Rails before 4.0====
=====Getting start=====
Firstly, let's create a Rails application in 3.2, then by default, you will see a file at <code>config/initializers/session_store.rb</code><ref>http://big-elephants.com/2014-01/handling-rails-4-sessions-with-go/</ref>. The contents of this file is something like:
<pre>Testcookies::Application.config.session_store :cookie_store, key: '_testcookies_session'</pre>
The <code>:cookie_store</code> in this line means to use cookie to store session information. And the <code>key: '_testcookies_session'</code> is telling us to use _testcookies_session as the key to store cookie data. A single site can have cookies under different key.

And you can add following code to controller to create a session:
<pre>session[:username] = 'csc517'</pre>

Then by visiting the action that executes above code, then you can see cookies for <code>localhost:3000</code> in Chrome Inspect Element:

[[File:Screenshot_2015-02-17_23.31.35.png]]

=====Deciphering content of the cookie=====
As you can see I have only one cookie with key <code>_testcookies_session</code>, and the cookie has following data:

<code>Value: BAh7CEkiD3Nlc3Npb25faWQGOgZFVEkiJWIwMjY1Mzk0NTM3NDE1YjNkOTYyOGY1NzlmODRiNmY1BjsAVEkiDXVzZXJuYW1lBjsARkki
C2NzYzUxNwY7AFRJIhBfY3NyZl90b2tlbgY7AEZJIjFYdWZNZFVVWFpYNUdYSDc1a3hybGdCS21xUW5td25majBGVmRmMWtpcVk4PQY7AEY%3D
'''--fa4da3b8f5b19e25a3d4a973f94e2e0f1524b7d6'''</code>

The content is [http://ruby-doc.org//stdlib-2.1.2/libdoc/uri/rdoc/URI/Escape.html escaped] and [http://en.wikipedia.org/wiki/Base64 Base64] encoded data(the first two lines), followed by [http://ruby-doc.org/stdlib-2.0/libdoc/digest/rdoc/Digest.html digest] of data(the third line), which is used to make sure the content is original without modification by attackers. With lots of methods decoding Base64 codes, we are able to get the data that is stored in cookie. Let's open the rails console and try to decipher this message:
<code>content = BAh7CEkiD3Nlc3Npb25faWQGOgZFVEkiJWIwMjY1Mzk0NTM3NDE1YjNkOTYyOGY1NzlmODRiNmY1BjsAVEkiDXVzZXJuYW1lBjsARkki
C2NzYzUxNwY7AFRJIhBfY3NyZl90b2tlbgY7AEZJIjFYdWZNZFVVWFpYNUdYSDc1a3hybGdCS21xUW5td25majBGVmRmMWtpcVk4PQY7AEY%3D
--fa4da3b8f5b19e25a3d4a973f94e2e0f1524b7d6</code>

When the content is written to cookie it is escaped automatically. So first we need to unescape it by doing:
>> content = URI.unescape(content)
"BAh7CEkiD3Nlc3Npb25faWQGOgZFVEkiJWIwMjY1Mzk0NTM3NDE1YjNkOTYyOGY1NzlmODRiNmY1BjsAVEkiDXVzZXJuYW1lBjsARkki
C2NzYzUxNwY7AFRJIhBfY3NyZl90b2tlbgY7AEZJIjFYdWZNZFVVWFpYNUdYSDc1a3hybGdCS21xUW5td25majBGVmRmMWtpcVk4PQY7AEY=
--fa4da3b8f5b19e25a3d4a973f94e2e0f1524b7d6"

Then the data before "--" is the real data, and after the "--" is the digest. So let's do this:
>> data, digest = unescaped_content.split('--')
["BAh7CEkiD3Nlc3Npb25faWQGOgZFVEkiJWIwMjY1Mzk0NTM3NDE1YjNkOTYyOGY1NzlmODRiNmY1BjsAVEkiDXVzZXJuYW1lBjsARkki
C2NzYzUxNwY7AFRJIhBfY3NyZl90b2tlbgY7AEZJIjFYdWZNZFVVWFpYNUdYSDc1a3hybGdCS21xUW5td25majBGVmRmMWtpcVk4PQY7AEY=",
"fa4da3b8f5b19e25a3d4a973f94e2e0f1524b7d6"]

As the data is base64 encoded, we can use this command to decode the information:
>> Marshal.load(::Base64.decode64(data))
{"session_id"=>"b0265394537415b3d9628f579f84b6f5", "username"=>"csc517", "_csrf_token"=>"XufMdUUXZX5GXH75kxrlgBKmqQnmwnfj0FVdf1kiqY8="}

So we are able to see the data stored in the cookie: <code>"username"=>"csc517"</code>. However we can’t tamper with the cookie because if we change the cookie data then the digest will not match. In order to create the digest, rails makes of use of <code>config/initializer/secret_token.rb</code>:

Testcookies::Application.config.secret_token = '998a88d908feae524a1f4091b3034e742bcb7863d978dc5ccc7af80f26b7129788b2c6550356c89eb452ed4f088008463239014614d0a80ac2cc0baa4de82341'

Use this token to create digest:
>>token = "998a88d908feae524a1f4091b3034e742bcb7863d978dc5ccc7af80f26b7129788b2c6550356c89eb452ed4f088008463239014614d0a80ac2cc0baa4de82341"
>>OpenSSL::HMAC.hexdigest(OpenSSL::Digest.const_get('SHA1').new, token, data)
"fa4da3b8f5b19e25a3d4a973f94e2e0f1524b7d6"

We can see that any changes to the data will lead to a different digest:
>>data[0] = 'A'
>>OpenSSL::HMAC.hexdigest(OpenSSL::Digest.const_get('SHA1').new, token, data)
"8bc1b0f49eb382b650992114264a807832496f94"

=====Using cookie with more option=====
In the previous example we used session to store and retrieve data from cookie. We can directly use cookie and that gives us a little bit more control. We can add these code to create a cookie:
cookies[:username] = 'csc517'

Then we can see the cookies in the browser:
[[File:Screenshot 2015-02-18 01.43.00.png]]

Now there are to keys in the cookie. The first is same as before and the new one is created by the code above. One thing to notice is that the data stored for key username is not Base64encoded and it also does not have the digest. It means this type of cookie data can be tampered with by the user and the Rails application will not be able to detect that the data has been tampered with. And there are some options you can use when setting a cookies:
{| class="wikitable"
|-
! Option
! Description

|-
| value
| The cookie's value, you can also assign a list of values, such as an array.
|-
| path
| The application path for which this cookie applies -- the cookie won't be available for other paths. The default is the root of the application.
|-
| domain
| The domain for which this cookie applies; the cookie won't be available for other domains.
|-
| expires
| Sets the time when the cookie expires. Use a Rails Time object.
|-
| secure
| Indicates whether the cookie is secure; the default is false. Note: secure cookies are only sent to secure(HTTPS) servers.
|}
=====Signed cookies=====
Writing cookies to the response via the <code>cookies.signed</code> has generates signed representations of cookies to prevent tampering of those cookies' values by the end user. If a signed cookie was tampered with, an <code>ActiveSupport::MessageVerifier::InvalidSignature</code> exception will be raised.
cookies.signed[:aother_username] = 'csc517'
Then the cookies in browser become this:

[[File:Screenshot 2015-02-18 02.03.14.png]]

The value of <code>another_username</code> has a digest in it, we can use that to detect whether the information has been tampered.

=====Conclusion=====
Session, by default, uses signed cookies which prevents any kind of tampering of data, but the data is still visible to users. It means we can’t store sensitive information in session.It would be nice if the session data is stored in encrypted format. And in the Rails 4, the cookie is encrypted by default.
====In Rails 4====
If we generate a Rails application in Rails 4 then,by default, we will see a file at <code>config/initializers/session_store.rb</code>. The contents of this file is something like this:
Rails.application.config.session_store :cookie_store, key: '_testcookies4_session'
This means we use cookie to store session by default. And unlike Rails 3, now we don't have the file <code>config/initializers/secret_token.rb</code>. Instead, we have <code>config/secrets.yml</code><ref>http://blog.bigbinary.com/2013/03/19/cookies-on-rails.html</ref>, and it has these content:
development:
secret_key_base: a760133dad846d239461e2575efa7ac44c68400ded807b58a81fa4517f87b402b76750d710a402b3a90a4b063bd2235fcea8a49186553c01a70db2fb5d4786ff
test:
secret_key_base: 0131c94a859126b01285f0c744e0e9759ca9aa854da3b21799e7b2d1c555f982bc31a2e7e6e1d2327cfd735587528d1fac3cc129da8cd68e6bea9cb1e6c4e5b4
# Do not keep production secrets in the repository,
# instead read values from the environment.
production:
secret_key_base: <%= ENV["SECRET_KEY_BASE"] %>

For each environment, the rails application has a different <code>secret_key_base</code>. Notice that in Rails 3.2.x the key was <code>secret_token</code>, now is <code>secret_key_base</code>. The differences are if you only have secret_token set, your cookies will be signed, but not encrypted. This means a user cannot alter their <code>username</code> without knowing your app's secret key, but can easily read their <code>username</code>. This was the default for Rails 3 apps. If you have secret_key_base set, your cookies will be encrypted. This goes a step further than signed cookies in that encrypted cookies cannot be altered or read by users. This is the default starting in Rails 4.

Let's put this code into a controller:
session[:username] = 'csc517'
Then by visiting the action that executes above code, then you can see cookies for localhost:3000 in browser:
[[File:Screenshot 2015-02-18 02.29.10.png]]

Cookie has following data:
value = RjcxbnNGWVU1MnRXMWhnZ3ViOE1ObFN4SWNBaFZVaWJCUVVuWDJ0QlBxdDFpWEpBL0hxNWtRM0RpMjJYS1ROMEVkbjEyZ0piV3AxamoyVFNqUGhqTVY3engwalZFa0xFcTFwZ085cDJ
wN3Q2dFp2MzlHMDVQRzM0M1RhWE9nYVVEaUJrTGFoV1paenZTMmc2WVRtandzczZCTkgzUjhGTWwweWtsM1Y3RlhjeTFMOEI0R0o5eml3ZGo3UTZQTmVOLS1PSW91Nms0YkROdUdtZWh3WE9lMDdRPT0%3D
--fa205eafee14ec48d829b606cf27151e56da6c8e

Then open <code>rails console</code> to do the following operations:
>> content = "RjcxbnNGWVU1MnRXMWhnZ3ViOE1ObFN4SWNBaFZVaWJCUVVuWDJ0QlBxdDFpWEpBL0hxNWtRM0RpMjJYS1ROMEVkbjEyZ0piV3AxamoyVFNqUGhqTVY3engwalZFa0xFcTFwZ085cDJ
wN3Q2dFp2MzlHMDVQRzM0M1RhWE9nYVVEaUJrTGFoV1paenZTMmc2WVRtandzczZCTkgzUjhGTWwweWtsM1Y3RlhjeTFMOEI0R0o5eml3ZGo3UTZQTmVOLS1PSW91Nms0YkROdUdtZWh3WE9lMDdRPT0%3D
--fa205eafee14ec48d829b606cf27151e56da6c8e"
>> content = URI.unescape(content)
>> secret_key_base = 'a760133dad846d239461e2575efa7ac44c68400ded807b58a81fa4517f87b402b76750d710a402b3a90a4b063bd2235fcea8a49186553c01a70db2fb5d4786ff'
>> key_generator = ActiveSupport::KeyGenerator.new(secret_key_base, iterations: 1000)
>> key_generator = ActiveSupport::CachingKeyGenerator.new(key_generator)
>> secret = key_generator.generate_key('encrypted cookie')
>> sign_secret = key_generator.generate_key('signed encrypted cookie')
>> encryptor = ActiveSupport::MessageEncryptor.new(secret, sign_secret)
>> data = encryptor.decrypt_and_verify(content)
>> puts data
=> csc517

As you can see we need the <code>secret_key_base</code> to make sense out of cookie data. So in Rails 4 the session data will be encrypted ,by default.

==Attention==
Usually cookie has limit size which is 4K. A CookieOverflow exception is raised if you attempt to store more than 4K of data<ref>http://api.rubyonrails.org/classes/ActionDispatch/Session/CookieStore.html</ref>.
If you are upgrading an existing Rails 3 app, you should leave your existing secret_token in place and simply add the new secret_key_base. Note that you should wait to set secret_key_base until you have 100% of your userbase on Rails 4 and are reasonably sure you will not need to rollback to Rails 3. This is because cookies signed based on the new secret_key_base in Rails 4 are not backwards compatible with Rails 3. You are free to leave your existing secret_token in place, not set the new secret_key_base, and ignore the deprecation warnings until you are reasonably sure that your upgrade is otherwise complete. Additionally, you should take care to make sure you are not relying on the ability to decode signed cookies generated by your app in external applications or JavaScript before upgrading. Note that changing the secret key will invalidate all existing sessions!
And successful encryption and signing are based on administrators’ secure operation. For example, if attackers finally have the access to secret_token or encryption key, then it is possible that they can see or modify the cookie data, then pretend to be a legal user to accomplish various operations, which is disastrous for Rails security.

==Conclusion==
Cookies are used to store some small data that can notify web server of the user’s previous activity. It can be executed very quickly and will not cost much space. Encrypted cookies make sure cookies’ data will not be seen by any unauthorized users so that information security gets protected. It uses AES-256 to encrypt data by default. Using encrypted cookies sometimes will not be better if some secret keys cannot be protected properly. With access to these keys, attacker can easily see the content in cookie even modify it. So we need to pay attention to obey rules when using encrypted cookies.

==References==
<references/>