CSC/ECE 517 Fall 2013/ch2 0e808 nsv: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(95 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= E808: Refactor and test Participant, AssignmentParticipant, & CourseParticipant =
= E808: Refactor and test Participant, AssignmentParticipant, & CourseParticipant =
The requirements provided for the Open Source System project of Expertiza were as follows : <br>
'''Classes''': <br>
''participant.rb'' (197 lines)<br>
''assignment_participant.rb'' (476 lines)<br>
''course_participant.rb'' (90 lines)<br>


Code Deployment or [http://en.wikipedia.org/wiki/Software_deployment Software Deployment] and [http://en.wikipedia.org/wiki/Release_management Release management] with [http://en.wikipedia.org/wiki/Ruby_on_Rails Ruby on Rails] can be done using various tools such as [http://en.wikipedia.org/wiki/Capistrano Capistrano], [http://en.wikipedia.org/wiki/Heroku Heroku], AppFog, OpenShift, AWS, Cloud 66, Vlad, etc. These automated tools are frameworks used to write and execute commands in parallel remote machines and thus ease the process of deployment and management of various applications.
'''What they do''': <br>
These classes keep track of a user who is participating in an assignment or a course. participant.rb is the superclass, and the other two are the subclasses.
 
'''What is needed''': <br>
The methods are complex; there are a lot of them (assignment_particpant has 44) and there is a lot of duplicated code. assignment_participant contains code for detecting cycles of high grades (which can indicate collusion in reviews). It would be better moved to another class.


__TOC__
__TOC__
Line 7: Line 16:
= Introduction =
= Introduction =


The Deploying process involves different stages like development, testing, release management and sign-off by project teams.
A cursory analysis of the code of the three model classes showed the existence of code duplication. In a lot of the cases the [http://en.wikipedia.org/wiki/Don%27t_Repeat_Yourself Don't Repeat Yourself] (DRY) principle was violated.


The following diagram illustrates the deployment process of an application.
In keeping with the [http://en.wikipedia.org/wiki/Agile_software_development Agile] methodology, which involves having regular discussions with all stakeholders, the design check for the project was performed with a meeting with the Instructor.
This helped set a direction to the way ahead for the project. The process followed in detail is explained in the following sections.


[[File:Deployment Process.jpg|frame|center|<ref>http://technet.microsoft.com/en-us/library/cc465178.aspx</ref>]]
= Project Design and Approach =


Since the Agile Method of software development was adopted for this project, the first basic principle was accepting the fact that not all the requirements would be known at the onset, but instead would change with time. Also the primary purpose of the project was to get acquainted with the techniques needed to understand a huge application already in place and coded by others. <br>
With this in mind, there was the freedom to propose an array of changes and then through trial and error perceive their feasibility and impact on the application.<br>
During the first design check with the Instructor, all the methods in the three models were parsed through and the existing issues were identified. What was also discussed was functionality that could be improved upon or new features that could be added but only if these improved the overall quality of the code or made better design sense.<br>
The result of this meeting was a spreadsheet with all model methods, their functions and proposed changes.
This spreadsheet was the used as the baseline for the entire project
Following through with getting timely feedback from all stakeholders, this proposal was discussed with the Instructor and modified as per comments received.
With the first set of requirements ready, the code could now be worked upon.<br>
With the goal being refactoring and testing of the models, before any code changes could be made the existing tests needed to be verified to run successfully. Unit tests deal with models. Therefore the test files participant_test.rb,  assignment_participant_test.rb and course_participant_test.rb were run , but found to have bugs. These were fixed (explained in detail in sections below). The only test that still failed was in assignment_participant_test.rb and dealt with the publishing rights functionality which is not yet working in the expertiza project. Hence this test's failure was expected behavior and thus ignored.
Certain basic guidelines followed for improving the code design were :
# Re-use code as much as possible
# Make the code DRY and remove code duplication
# Remove redundant or unnecessary methods
# Redesign the code to make it more object oriented
# Due to the hierarchy structure of the models, common functionality between the models needed to be moved to the base class
# Specialized methods not relevant to the super-class should be moved to the sub-class it applies to
# Any deprecated code must be modified in accordance with the new norms to ensure smooth running of code in future versions of Rails<ref>http://stackoverflow.com/questions/15098961/findfirst-and-findall-are-deprecated</ref>
# Rename methods to conform better with Ruby naming conventions
# Improve the readability of the code


The deployment flow has three stages: development and testing, release management and stakeholders and project teams.  
= UML Class Diagram =
A subset of the [http://en.wikipedia.org/wiki/Unified_Modeling_Language UML] class diagram including only the related classes for this project can be drawn as shown below. [[File:UML_E808.png | UML class diagram]]


After the final release of the code in development and testing stage, the master plan is prepared for deployment of components and sites based on the sign-offs provided by the project teams, stakeholders and customers. Then, the stabilization of the deployment is calculated based on some metrics. Once the deployment is stabilized, it is reviewed and the process of deployment is complete. The final sign-off is given by the stakeholders.
Participant is the superclass for subclasses AssignmentParticipant and CourseParticipant. In the database to actually distinguish between these a type attribute is used which can take values as 'AssignmentParticipant' or 'CourseParticipant' while a participant that does not belong to either an assignment nor a course cannot exist in the system as he just becomes a user and not a participant.<br>
A participant has a user i.e. only a user can become a participant.<br>
An AssignmentParticipant has an assignment and a CourseParticipant has a course. This relationship is defined by the parent_id attribute of a participant.


==Code Deployment==
=Participant model: participant.rb=


Code deployment is a procedure where the application is transferred onto a production server, so that it is made available for all the other users. It is the part of release management process which involves several activities. These activities are inter-dependent and need to be completed in a specific order for successful code deployment.  
The Participant model class being the base class should only contain code or methods that are relevant or needed by both the subclasses. But instead , it was cluttered with methods that would be better placed in one of the child classes as they are relevant to only that subclass. Such methods were moved to the respective sub-classes. Also certain functionalities that were common between both subclasses were repeated in both leading to code repetition. Such methods were moved to Participant class and will be dealt with in the later sections of this article. Several methods in Participant model required renaming and refactoring to ensure that the change is reflected in the entire project. The names were changed to follow method naming convention. Deprecated code was removed and re-coded to ensure that the code worked in future versions of Rails as well.  
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| able_to_submit
| It has been commented out.
| Method not called or used anywhere. Also the method just returned the value of the attribute submit_allowed which is already taken care of by attr_accessors.
|-
|''''' 2 '''''
| force_delete
| The deprecated code in this method has been changed.
| To ensure the code works in future versions of Rails.
|-
|''''' 3 '''''
| get_average_question_score
| Renamed to average_question_score and refactored.
| To conform to method naming convention.
|-
|''''' 4 '''''
| get_average_score
| Renamed to average_score and refactored also moved to the model assignment_participant.rb. Removed empty parentheses from declaration
| The new name is more in keeping with method naming conventions. Removal of empty parentheses helps with poetry mode of code. The method was moved because calculation of average score is only relevant to AssignmentParticipant and not to CourseParticipant.
|-
|''''' 5 '''''
| get_current_stage
| Moved to the model - assignment_participants.rb
| The method was moved because getting current stage of an assignment is only relevant to AssignmentParticipant and not to CourseParticipant.
|-
|''''' 6 '''''
| get_stage_deadline
| Moved to model - assignment_participant.rb
|Just like get_current_stage, this method too is only relevant to AssignmentParticipant and not to CourseParticipant.
|-
|''''' 7 '''''
| get_topic_string
| Renamed to topic_string and refactored.
|To follow method naming convention
|-
|''''' 8 '''''
| review_response_maps
| Moved to model - assignment_participant.rb
| Reviews are made only on assignments and hence ReviewResponseMaps would only exist for between the participants of an assignment. Thus this method would be better placed in AssignmentParticipant.
|}


'''Code Deployment Activities'''
After changes were made, the existing tests ran successfully.


The various deployment activities include <ref>http://en.wikipedia.org/wiki/Software_deployment</ref>
=AssignmentParticipant model: assignment_participant.rb=
* Release : Gathering all system components in preparation for deployment
* Install and activate : Installing the application components and getting them in the 'ready' state
* Deactivate : Shutting down components that are out-dated or that may interfere with updating others
* Adapt : Making changes to application to accommodate changes in environment
* Update : Having a newer release installed in place of the old one
* Built-in : There are components built-into some tools for complete/semi-automating updates
* Version tracking : These systems help the user to know if newer versions of a software are available and if yes, help install them
* Uninstall : Opposite of installation and involves complete removal of software and its dependencies from the environment
* Retire : This involves making a software obsolete and is the end of software life cycle


The general guidelines for the deployment process remain the same but there are variations in the specific requirements with each software system.
Several methods in AssignmentParticipant model class required renaming and refactoring to ensure that the change is reflected in the entire project. The names were changed to follow method naming conventions in Ruby. Deprecated code was removed and re-coded to ensure that the code worked in future version of Rails as well. Duplicate codes were commented out. Methods that are more general in the sub classes were moved to the parent class. Some methods that calculate the collusion in reviews between students were moved to a newly created model class called CollusionCycle in file collusion_cycle.rb .


==Release Management==
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
|get_course_string
|Renamed to course_string and refactored
|To follow method naming convention
|-
|''''' 2 '''''
|get_cycle_deviation_score
|Moved to collusion_cycle.rb model class
|Related methods that calculate collusion in reviews have been moved to the newly created collusion_cycle.rb model class
|-
|''''' 3 '''''
|get_cycle_similarity_score
|Moved to collusion_cycle.rb model class
|Related methods that calculate collusion in reviews have been moved to the newly created collusion_cycle.rb model class
|-
|''''' 4 '''''
|get_feedback
|Renamed to feedback and refactored
|To follow method naming convention
|-
|''''' 5 '''''
|get_files
|Renamed to files_in_directory  and refactored
|To follow method naming convention
|-
|''''' 6 '''''
|get_four_node_cycles
|Moved to collusion_cycle.rb model class
|Related methods that calculate collusion in reviews have been moved to the newly created collusion_cycle.rb model class
|-
|''''' 7 '''''
|fullname
|Moved to parent model class – participant.rb
|General methods of the subclass are moved to Parent class
|-
|''''' 8 '''''
|get_metareviews
|Renamed to metareviews and refactored
|To follow method naming convention
|-
|''''' 9 '''''
|name
|Commented the method 
|The method is already in parent model class – participant.rb and can be used in this subclass through inheritance
|-
|''''' 10 '''''
|name
|Commented the method 
|The method is already in parent model class – participant.rb and can be used in this subclass through inheritance. Also it is a duplicate method in patricipant.rb
|-
|''''' 11 '''''
|get_review_score
|Renamed to review_score and refactored. Deprecated code has been removed and replaced with correct code.
|To follow method naming convention and ensure the code works in future versions.
|-
|''''' 12 '''''
|get_reviewees
|Renamed to reviewees and refactored. Deprecated code has been removed and replaced with correct code.
|To follow method naming convention and ensure the code works in future versions.
|-
|''''' 13 '''''
|get_reviewers
|Renamed to reviewers and refactored . Deprecated code has been commented and replaced with correct code.
|To follow method naming convention and ensure the code works in future versions.
|-
|''''' 14 '''''
|get_reviews
|Renamed to reviews and refactored
|To follow method naming convention
|-
|''''' 15 '''''
|get_reviews_by_reviewer
|Renamed to reviews_by_reviewer and refactored
|To follow method naming convention
|-
|''''' 16 '''''
|get_reviews_by_reviewer
|Commented the method
|To remove duplicated method in this class
|-
|''''' 17 '''''
|get_scores
|Renamed to scores and refactored
|To follow method naming convention
|-
|''''' 18 '''''
|get_submitted_files
|Renamed to submitted_files and refactored
|To follow method naming convention
|-
|''''' 19 '''''
|get_teammate_reviews
|Renamed to teammate_reviews and refactored
|To follow method naming convention
|-
|''''' 20 '''''
|get_three_node_cycles
|Moved to collusion_cycle.rb model class
|Related methods that calculate collusion in reviews have been moved to the newly created collusion_cycle.rb model class
|-
|''''' 21 '''''
|get_topic_string
|Method has been Commented
|It is already present in model super class – participant.rb
|-
|''''' 22 '''''
|get_two_node_cycles
|Moved to collusion_cycle.rb model class
|Related methods that calculate collusion in reviews have been moved to the newly created collusion_cycle.rb model class
|-
|''''' 23 '''''
|get_wiki_submissions
|Renamed to wiki_submissions and refactored
|To follow method naming convention
|}


<ref>http://searchitchannel.techtarget.com/definition/release-management</ref>
After changes were made, the existing tests ran successfully.
Release management is a software process which takes care of the development, testing, deployment and support stages of software releases. The start of release management happens in the development phase, where it requests for new features or changes in the existing application. When the request is accepted, a new release is planned and designed. This design is built and then enters the testing phase, where the release is tested until it is accepted. After the release is accepted as a candidate, it enters the deployment phase where it is implemented. Once deployed, the release is made available and sent to support phase for collection of bug reports. Once the support phase is done, the bugs and other issues lead to requests for changes and the cycle is then repeated.


= Automating Code Deployment and Release Management =
=CourseParticipant model:course_participant.rb =
<ref>http://www.urbancode.com/html/solutions/deployment-automation.html</ref>
Automation of a process is required when the manual process is more error prone. Also, for large real world applications, the manual process is very complex and time consuming. Incomplete documentation hampers a manual process further. Deployment also has to be done in many environments and involves varied steps to be followed in a specific order. Manual process needs repetition of same procedure to each and every environment which leads to many errors and the process becomes costly.
In web applications each new release has to be deployed to and tested in development, testing and production environments.The number of software releases in web applications  are more and hence the need to automate release management is also greater.


Automation of deployment delivers applications faster and with fewer errors. The defined software deployment process can be applied across all environments consistently every time. With various automated application deployment platforms now readily available, manual deployments have become a thing of the past.
The CourseParticipant model has methods like get_path and self.get_export_fields which were present in both assignment_participant.rb and course_participant.rb. Since they had dynamic usages, they could not be deleted from the two subclasses and placed in participant.rb.
{| class="wikitable"
|-
! style="width:5%;"|Sr. No.
! style="width:13%;"|Method Name
! style="width:33%;"|Changes Made
! style="width:43%;"|Reason For Change
|- style="vertical-align:top;"
|''''' 1 '''''
| get_course_string
| Renamed to course_string and refactored
| To follow method naming convention.
|-
|}


Lets take a look at the various Deployment Automation tools available to Ruby on Rails applications. For the purposes of this article the process of manual deployment of a Ruby on Rails application is out of scope.
= Changes to yaml files <ref>http://stackoverflow.com/questions/19442688/when-i-run-rails-server-it-is-showing-error-about-database-yml</ref>=


= Deployment Automation tools =
{| class="wikitable"
 
|-
Some of the automated tools that are widely used for the process of deployment with Ruby on Rails are
! style="width:5%;"|Sr. No.
 
! style="width:13%;"|Method Name
* Capistrano
! style="width:33%;"|Changes Made
* Heroku
! style="width:43%;"|Reason For Change
* Vlad
|- style="vertical-align:top;"
* AppFog
|''''' 1 '''''
* AWS Elastic Beanstalk
|invitation.yml
* OpenShift
|The indentation was corrected.  
* Cloud 66
|Improper Indentation in invitation.yml was throwing errors.  
 
|-
== Capistrano ==
|''''' 2 '''''
 
|users.yml
[[File:Capistrano.jpg|frame|right|<ref>http://www.capistranorb.com/</ref>|Capistrano Logo]]
|1.The symbol ‘:password’ was renamed to :crypted_password’ 
 
2.‘fullname :last,first’ was added inside ‘student1:
Capistrano is a Ruby tool which helps deploy an application to the server. Capistrano allows deploying to multiple machines at a time. It has many advanced options which help to deploy different kinds of applications. It also supports the scripting and execution of tasks.
|1.Attribute name is crypted_password in user.rb
 
2.Fixture was missing definition of fullname which required for the tests.
Capistrano can be used to:
|-
 
|}
* Deploy applications onto many machines simultaneously.
* Automate the audits
* Automate the common tasks of a team.
 
Capistrano can be made a part of a larger software by integrating it with another Ruby software.
 
 
<ref>http://www.capistranorb.com/documentation/getting-started/installation/</ref>  
'''General Usage'''
 
The following commands will clone Capistrano, build the gem and install it locally.
<pre>
$ gem install capistrano --pre --trust-policy HighSecurity
</pre>
 
Or grab the bleeding edge head from:
<pre>
$ git clone -b v3 https://github.com/capistrano/capistrano.git
$ cd capistrano
$ gem build *.gemspec
$ gem install *.gem
</pre>
'''Signed Rubygems'''
 
As Capistrano is a signed gem, you should always be careful to use the --trust-policy flag when installing Gems, or since Bundler 1.3 you should use the same flag:
<pre>
$ gem install capistrano --pre --trust-policy HighSecurity
$ bundle install --trust-policy HighSecurity
</pre>
If you get a message that looks like:
<pre>
ERROR:  While executing gem ... (Gem::Security::Exception)
unsigned gems are not allowed by the High Security policy
</pre>
 
Then please complain to your Gem author, and have them start signing their Gems.
 
'''Usage in a Rails project'''
 
Add the following lines to the Gemfile to the :development group ideally.
 
<pre>
group :development do
  gem 'capistrano-rails', '~> 0.0.7'
end
</pre>
 
== Heroku ==
 
[[File:Heroku.jpg|frame|right|<ref>https://www.heroku.com/</ref>|Heroku Logo]]
 
Heroku is a cloud [http://en.wikipedia.org/wiki/Platform_as_a_service Platform as a Service] (PaaS) which supports several programming languages. PaaS is a service model of Cloud computing wherein the provider offers resources like servers, software, database, etc. to the developer. Heroku helps manage environment-specific configurations separately from the source code, which provides greater security.
Heroku is not just a deployment environment but it also impacts the development process. There are several principles of the development of application on Heroku.<br>
• Applications and Codebases : Most of the development of the application is done on application’s codebase which is stored in a [http://en.wikipedia.org/wiki/Version_control_system Version Control System (VCS)] <br>
• Dependencies : All the application dependencies such as plugins should be declared explicitly<br>
• Configuration : Configuration of an application is all that varies in different deploys<br>
 
 
'''Getting Started with Heroku'''
 
1. To get started with Heroku, go to https://id.heroku.com/signup/devcenter, signup for a Heroku account.
 
2. Then, download and install the Heroku toolbelt at https://toolbelt.heroku.com/ for your development system. You can also use Heroku command line instead of the online Heroku application.
 
3. After installing one of them, login using the email address and password used when creating the Heroku account:
 
<ref>https://github.com/heroku/heroku</ref>
<pre>
$ heroku login
Enter your Heroku credentials.
Email: adam@example.com
Password:
Could not find an existing public key.
Would you like to generate one? [Yn]
Generating new SSH public key.
Uploading SSH public key /Users/adam/.ssh/id_rsa.pub
</pre>
 
'''Deploying Applications'''
 
Heroku uses [http://en.wikipedia.org/wiki/Git_(software) git] primarily to deploy the applications. When an application is created on Heroku, it associates the new git which is remote with the local git repository.
 
As a result, deploying code is just the familiar git push, but to the heroku remote instead:
 
<ref>https://devcenter.heroku.com/articles/how-heroku-works#deploying-applications</ref>
<pre>
$ git push heroku master
</pre>
 
== Vlad ==
 
[[File:Vlad.png|frame|right|<ref>http://rubyhitsquad.com/Vlad_the_Deployer.html</ref>|Vlad Logo]]
 
Vlad is another automated deployment tool which is simple to use. It integrates with rake and uses standard tools like SSH, rsync etc.
 
The main features of Vlad include
* It uses very few dependencies which are simple.
* It can execute commands on more than one server.
* It syncs files to one or more servers.
* It matches local and remote tasks.
* It runs tests very fast.
 
'''Getting started with Vlad'''<ref>http://docs.seattlerb.org/vlad/doco/getting_started_txt.html</ref>


Create a deploy file, usually in “config/deploy.rb”:
= Testing <ref> http://guides.rubyonrails.org/testing.html </ref>=
<pre>
set :application, "project"
set :domain, "example.com"
set :deploy_to, "/path/to/install"
set :repository, 'http://svn.example.com/project/branches/stable/'
</pre>
This defaults to using ‘svn export’ from repository, and a single server for app, db, and www.


If you want a multi-config environment, change your config like so:
===course_participant_test.rb===
<pre>
set :application, "project"
set :repository, 'http://svn.example.com/project/branches/stable/'


task :beta do
Changed the following line :  
  set :domain,    "beta.example.com"
  set :deploy_to, "/path/to/install-beta"
end
 
task :dev do
  set :domain,    "dev.example.com"
  set :deploy_to, "/path/to/install-dev"
end
 
task :prod do
  set :domain,    "example.com"
  set :deploy_to, "/path/to/install"
end
</pre>


Add the following to your Rakefile:
<pre>
<pre>
begin
CourseParticipant.import(['luke','Luke Skywalker','luke@gmail.com','darthvader'],{:user=>users(:superadmin)},courses(:course_e_commerce).id)</pre>
  require 'vlad'
to
  Vlad.load
rescue LoadError
  # do nothing
end
</pre>
Vlad.load has a lot of flexibility.
 
You can install vlad via:
 
<pre>% rake vlad:invoke COMMAND='sudo gem install vlad -y'</pre>
 
Initial Launch
<pre>Run rake vlad:setup vlad:update vlad:migrate vlad:start</pre>
 
 
<ref>http://docs.seattlerb.org/vlad/index.html</ref>
'''Running Vlad'''
 
* Using rake
<pre>
<pre>
task :shazam! do
CourseParticipant.import(['luke','Skywalker,Luke','luke@gmail.com','darthvader'],{:user=>users(:superadmin)},courses(:course_e_commerce).id)
  Rake::Task[:action1].invoke
  Rake::Task[:action2].invoke
end
</pre>
* Using SSH
<pre>
Host example.com
    User fluffy_bunny
</pre>
</pre>
This was done to follow the syntax of fullname i.e.last_name,first_name which is a requirement of the application.


== AppFog ==  
===Rspec tests===


[[File:AppFog.jpg|frame|right|<ref>https://www.appfog.com/</ref>|AppFog Logo]]
participant_spec.rb<br>
created to check basic functionality of paticipant.rb


AppFog is a PaaS built on Cloud Foundry which is another PaaS platform for deploying applications.  
It checks for:<br>
1.Associations with other tables.<br>
2.Entry and update of records.


Features of AppFog are
= Changes in routes.rb <ref>http://guides.rubyonrails.org/routing.html</ref>=
* It launches and runs fast.
* It does not require configuring servers or installing frameworks.
* It is compatible with code management systems like git, svn etc.


'''Installing AppFog'''<ref>http://blog.appfog.com/getting-started-with-appfogs-command-line/</ref>
The following missing routes were added to the file routes.rb to make the program flow smoothly.  


‘af‘ command line tool is written in Ruby for installation.
Routes for submit_hyperlink and remove_hyperlink were added to the submitted_content controller as :


Download and install [http://rubyinstaller.org/ Ruby Installer] for Windows. The installer already includes RubyGems.
resources :submitted_content do
    collection do
      get :view
      get :edit
    ''' post :submit_hyperlink'''
    ''' get :remove_hyperlink'''
    end
  end


Be sure you use the Ruby-enabled command prompt window when you later install and use af. You access this command prompt from the Windows Start menu (All Programs > Ruby > Start Command Prompt with Ruby).
Routes for the get and post methods of the export_file controller were added :


Finally, update RubyGems from the Ruby Command Prompt:
resources :export_file do
<pre>
    collection do
$ gem update --system
      get :start
$ gem install af
      '''get :export'''
</pre>
      '''post :export'''
Login with:
    end
<pre>
  end
$ af login
</pre>
Finally from within your source code directory:
<pre>
$ af update hello-node
</pre>
 
'''Getting Started with AppFog'''
<pre>
target [url]                                      Reports current target or sets a new target
login [email] [--email, --password]                Login
info                                              System and account information
</pre>


== AWS Elastic Beanstalk==
Routes for cancel, accept and decline were added to the invitation controller :


[[File:AWSLogo.jpg|frame|right|<ref>https://aws.amazon.com</ref>|AWS Logo]]
  resources :invitation do
    collection do
      '''get :cancel'''
      '''get :accept'''
      '''get :decline'''
    end
  end


Amazon Wen Services(AWS) offers [http://en.wikipedia.org/wiki/Infrastructure_as_a_service#Infrastructure_as_a_service_.28IaaS.29 Infrastructure as a Service] (IaaS) and provides a complete set of resources for the development of a web application in minutes. AWS Elastic Beanstalk is a deployment tool of the AWS cloud.
=Scope for future work=


With AWS Elastic Beanstalk, applications can be quickly deployed and managed in the AWS cloud without worrying about the infrastructure that runs those applications. AWS Elastic Beanstalk reduces management complexity without restricting choice or control. Once the application is uploaded AWS Elastic Beanstalk automatically handles the details of capacity provisioning, load balancing, scaling, and application health monitoring. AWS Elastic Beanstalk uses highly reliable and scalable services.
* The tests related to ‘publishing_rights’ method in assignment_participant_test.rb still fail, but this is expected as this feature of publishing_rights has not yet been implemented in Expertiza.
* The delete hyperlink method needs to be fixed as currently this feature is bugged in the running Expertiza.
* A test for cycle_collusion.rb proposed as:
class CycleCollusionTest < ActiveSupport::TestCase
fixtures :response_maps, :users , :assignments
          test "collusion" do
          r = ResponseMap.new
          r.reviewee_id= response_maps(:response_maps0)  //his work was reviewed by user1
          r.reviewer_id= response_maps(:response_maps1) //he reviewed user0's work
          r.reviewee_id1=response_maps(:response_maps1)  //his work was reviewed by user0
          r.reviewer_id1=response_maps(:response_maps0)  //he reviewed user1's work
          !assert_equal r.reviewee_id, r.reviewer_id1
          end


'''AWS CLI'''
Could not be tested effectively as cycle_collusion is not used anywhere in the code except in assignment_participant.rb where the methods now belonging to cycle_collusion class were originally present.
 
*The feature of sending an email when a user gets registered for an assignment i.e.becomes an assignment participant needs to be implemented.
AWS Elastic Beanstalk uses a command line tool Eb, which helps you to deploy your application easily.
 
'''Getting Started with Eb'''<ref>http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/command-reference-get-started.html</ref>
 
To get started with the beanstalk CLI, you will need to download the command line tools at the [http://aws.amazon.com/code/6752709412171743 AWS Sample Code & Libraries] website.
 
Step 1: Initialize Your Git Repository
 
Eb is a command line interface that enables you to deploy applications quickly and more easily using Git. Eb is available as part of the Elastic Beanstalk command line tools package.
 
1. To install eb,install the following software onto your local computer:
 
* Git 1.6.6 or later. To download Git, go to http://git-scm.com/.
* PowerShell 2.0.
 
2. Initialize your Git repository.
<pre>
git init
</pre>
 
Step 2: Configuring AWS Elastic Beanstalk
 
1. From your directory where you created your local repository, type the following command.
<pre>
eb init
</pre>
 
2. When you are prompted for the access key ID, type your access key ID.
<pre>
Enter your AWS Access Key ID (current value is "AKIAIOSFODNN7EXAMPLE"):
</pre>
 
3. When you are prompted for the secret access key, type your secret access key.
<pre>
Enter your AWS Secret Access Key (current value is "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"):
</pre>
 
4. When you are prompted for the AWS Elastic Beanstalk application name, type the name of the application.
<pre>
Enter an AWS Elastic Beanstalk application name (auto-generated value is "windows"):
</pre>
Note:
If you have a space in your application name, make sure you do not use quotes.
 
5. When you are prompted for the AWS Elastic Beanstalk environment name, type the name of the environment. AWS Elastic Beanstalk automatically creates an environment name based on your application name. If you want to accept the default, press Enter.
<pre>
Enter an AWS Elastic Beanstalk environment name (current value is "HelloWorld-env"):
</pre>
 
6. When you are prompted to create an Amazon RDS DB instance, type y or n. For this example, we'll type y.
<pre>
Create an RDS DB Instance? [y/n]:
</pre>
 
7. When you are prompted to enter your RDS user master password, type your password containing from 8 to 16 printable ASCII characters (excluding /, \, and @).
<pre>
Enter an RDS DB master password:
Retype password to confirm:
</pre>
 
You can now get started with the AWS Elastic Beanstalk.
 
== OpenShift ==
 
[[File:OpenShift.png|frame|right|<ref>https://en.wikipedia.org</ref>|OpenShift Logo]]
 
Another free and open source PaaS for deploying applications is OpenShift created by [[http://en.wikipedia.org/wiki/RedHat RedHat]].
 
'''Considerations'''
* Databases
 
To use the application outside the OpenShift environment one needs to change the variables as the application is configured to use database in production mode in OpenShift.
 
* Assets
 
The assets are precompiled everytime application is pushed to OpenShift.
 
* Security
 
Security related variables are to be unique across the application.
<ref>https://github.com/openshift/rails-example</ref>
'''Installation'''
 
1. Create an account at http://openshift.redhat.com/
 
2. Create a rails application
<pre>rhc app create -a railsapp -t ruby-1.9</pre>
3. Add mysql support to your application
<pre>rhc cartridge add -a railsapp -c mysql-5.1</pre>
4. Add this upstream Rails quickstart repository
<pre>cd railsapp
git remote add upstream -m master git://github.com/openshift/rails-example.git
git pull -s recursive -X theirs upstream master</pre>
5. Push your new code
<pre>git push</pre>
 
== Cloud 66 ==
 
[[File:Cloud 66.jpg|frame|right|<ref>https://www.cloud66.com/</ref>|Cloud66 Logo]]
 
Cloud 66 combines the convenience of Platform-as-a-Service (PaaS) and the flexibility and control of Infrastructure-as-a-Service (IaaS). This platform allows easy deployment of application, so there is no overhead of configuring or monitoring the servers.
 
'''Cloud 66 Command line Toolbelt'''
 
Toolbelt is an open source released to deploy the application.
 
<ref>http://blog.cloud66.com/</ref>
 
'''Getting Started with Cloud 66'''
 
1. Go to the [https://www.cloud66.com/users/sign_up sign up] page and create a Cloud 66 account.
 
2. Go to Cloud 66 Dashboard and [https://www.cloud66.com/help/first_stack build your first stack].
 
'''Installation'''
 
Installation of toolbelt uses the following command
 
<pre>
Gem install c66
</pre>
 
This automatically searches the newest version and installs it.
 
= Model Class : assignment_participant.rb =
This class is a subclass of the model class named 'participant'.Several methods in this model class required refactoring. The names were changed to follow method naming convention. Deprecated code was removed and re-coded as needed. Duplicated methods were commented. Some of the methods were moved to the parent class while some other were moved to a new class.
 
{| class="wikitable"
|-
! style="width:9%;"|S. No
! style="width:13%;"|Method Name
! style="width:13%;"|Change Made
! style="width:13%;"|Reason For Change
|''''' 1 '''''
|get_course_string
|}
 
= Comparison between Capistrano/Vlad/Heroku/AppFog/OpenShift/Cloud66/AWS Beanstalk =
 
With so many automated tools available for Code Deployment and Release Management, the decision on which to use for a particular Ruby on rails application depends on various parameters to be considered.
Some comparative features of the different tools are as follows :
 
{| class="wikitable"
|-
! style="width:9%;"|Criteria for Comparision
! style="width:13%;"|Capistrano
! style="width:13%;"| Vlad
! style="width:13%;"| Heroku
! style="width:13%;"| AppFog
! style="width:13%;"| OpenShift
! style="width:13%;"| Cloud66
! style="width:13%;"| AWS Beanstalk
|- style="vertical-align:top;"
|'''''Getting started with the tool'''''
|It is a framework that allows one to execute commands on a remote server using tools like ssh.
|Vlad deployment is similar to Capistrano, but less complex.
|Heroku’s offers a plan with first dyno free i.e. 512 MB that can be paired with Postgres starter DB to start an application with 0 initial cost
|AppFog’s initial plan offers 2GB of RAM free which is enough for small to medium traffic applications. By managing options provided for DB, queue server, application server, etc all part of the intial package, this is an excellent option to try out an application
|OpenShift is an open source platform and its free plan for starters has 3 gears for free wherein each gear consists of some RAM and disk space.
|Free plan provides one server for deployment.
|Provides an initial free tier. Without free tier no additional cost for Beanstalk. One only needs to pay for the AWS resources used.
|-
|'''''Scaling Memory'''''
|Memory increase would require additional servers/unused space in existing ones.
|Memory increase depends on additional servers available/unused space in existing ones.
|Memory increased in terms of dyno each of size 512 MB.
|Can configure any size for memory allocation
| -
| -
|Can automatically up/down scale the application by adjusting the default auto scaling settings.
|-
|'''''Scaling – Cost and Ease'''''
|While this provides greater flexibility as user is in control of the servers, it also causes additional overhead in terms of user needing to work both on Rails application and web server deployment.
|It can be integrated with Rake without any hindrances.
|Can dynamically scale up and down an application and pay as per hourly usages. Each additional dyno costs $35/mo
|Scaling takes up some time and need to pay for a month at the minimum. Scaling up to 4GB increases cost to $100/mo
| -
|Scaling using Cloud66 is relatively easy and hassle free.
|Scaling is fast and easy.
|-
|'''''Special features'''''
|For sensitive applications where handing over the control to a third party for deployment is not feasible, Capistrano is the way to go.
|It also provides support for tools like rsync and ssh.
|Lacks support for cross region deployment i.e. can’t select location of server where application gets deployed
|Supports cross region deployment i.e. if users of application primarily in Asia, can choose a server in Asia to deploy application, thus making the site faster.
| -
| -
|Provides complete flexibility and control of the resources to the user including the chance to take over control of some or all.
|-
|'''''Database support'''''
|Provides support for DB related to rails applications
|Provides support for DB related to rails applications
|It features serious production DB like RDBMS, Postgres, etc. and many Addons such as MongoDB, ClearDB, etc.
|Features free shared databases such as MongoDB, MySQL, Postgres but for other production DB’s need to use Addons
|Databases featured are MySQL, MongoDB and Postgres
| -
|Supports DB like Amazon SimpleDB, Amazon RDS, Amazon DynamoDB.
|-
|'''''Deployment strategy'''''
|Capistrano provides commands to be executed for automated deployment. It supports git.
|It is much easier to deploy using Vlad as compared to Capistrano.
|Deployment as easy as ‘git push’
|Deployment does not support git. It uses the af tool for deployment.
| -
|Since Cloud66 provides the platform in terms of Application Stack Management as a Service, it uses the infrastructure of AWS, Virtual Private Server, etc. for actual deployment. But the user doesn’t have to worry about configuration or monitoring of the servers. Hence provides easy deployment.
|Deployment options include Git, AWS management console, etc.
|-
|'''''Community Support availability'''''
| As it has been in use for a long time there is a huge community support available for Capistrano.
| -
|Heroku also provides a huge community support given the fact that there are a lot of Heroku users.
|Community is limited.
|RedHat being a reputed provider for open source solutions, the OpenShift community is gradually increasing and receiving support from a considerable community of users.
|Limited community support currently
|Has community forums and documentation.
|}


= Conclusion =
= Conclusion =


Comparison and contrast between various deployment automated tools such as Capistrano, Heroku, Vlad, AppFog, OpenShift, Cloud66, AWS Beanstalk shows that each has its own pros and cons.  
*Renaming and refactoring was performed as per requirements and to follow conventions for the appropriate methods in participant.rb, assignment_participant.rb and course_participant.rb.
For instance, in a client based application where handing over the control of the application to a third party such as the deployment tool provider is impossible, AWS Beanstalk would be the obvious choice for the developer.
*Bugs in existing tests of model classes’ participant.rb, assignment_participant.rb and course_participant.rb (that were initially not running) were fixed and made to run without errors.  
On the other hand, a novice Rails application developer might find all he needs in the starter plan of Heroku with the added bonus of a huge support community available to him for troubleshooting as he stumbles his way across the development of the application.
*All tests in participant.rb, assignment_participant.rb and course_participant.rb- (except those related to publishing_rights due to absence of its functionality) ran successfully after changes were made to the three model files.
One may also choose the tool that provides the specific database support for your application. In case of large scale corporations where budgets are not that limited, the increasing costs with up-scaling of some tools would not be an obstacle.
Thus, various considerations about the application such as scalability requirement, security concerns, cost, availability of own resources such as servers etc., will help determine which tool is the most suitable for that application.


= References =
= References =
Line 522: Line 360:
= See Also =
= See Also =


* Rails Solutions: Ruby on Rails Made Easy by Justin Williams
* OSS - E808 project VCL link http://152.7.99.84:3000/ (may be disabled after a month)
* http://guides.beanstalkapp.com/deployments/best-practices.html
* OSS - E808 project on GitHub https://github.com/npari/expertiza_oss808
* http://www.urbancode.com/anthill3-help-3.7/html/SettingUpDeploymentProcess.html
* Expertiza project documentation can be found at http://wikis.lib.ncsu.edu/index.php/Expertiza
* http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=UseFMSGateway_3.html
* The working Expertiza site is accessible at link http://expertiza.ncsu.edu/
* http://pic.dhe.ibm.com/infocenter/tivihelp/v26r1/index.jsp?topic=%2Fcom.ibm.dtm.doc%2Fdeploysoftware%2Fc_deploysw_process.html
* Expertiza on GitHub https://github.com/expertiza/expertiza

Latest revision as of 04:03, 31 October 2013

E808: Refactor and test Participant, AssignmentParticipant, & CourseParticipant

The requirements provided for the Open Source System project of Expertiza were as follows :
Classes:
participant.rb (197 lines)
assignment_participant.rb (476 lines)
course_participant.rb (90 lines)

What they do:
These classes keep track of a user who is participating in an assignment or a course. participant.rb is the superclass, and the other two are the subclasses.

What is needed:
The methods are complex; there are a lot of them (assignment_particpant has 44) and there is a lot of duplicated code. assignment_participant contains code for detecting cycles of high grades (which can indicate collusion in reviews). It would be better moved to another class.

Introduction

A cursory analysis of the code of the three model classes showed the existence of code duplication. In a lot of the cases the Don't Repeat Yourself (DRY) principle was violated.

In keeping with the Agile methodology, which involves having regular discussions with all stakeholders, the design check for the project was performed with a meeting with the Instructor. This helped set a direction to the way ahead for the project. The process followed in detail is explained in the following sections.

Project Design and Approach

Since the Agile Method of software development was adopted for this project, the first basic principle was accepting the fact that not all the requirements would be known at the onset, but instead would change with time. Also the primary purpose of the project was to get acquainted with the techniques needed to understand a huge application already in place and coded by others.
With this in mind, there was the freedom to propose an array of changes and then through trial and error perceive their feasibility and impact on the application.
During the first design check with the Instructor, all the methods in the three models were parsed through and the existing issues were identified. What was also discussed was functionality that could be improved upon or new features that could be added but only if these improved the overall quality of the code or made better design sense.
The result of this meeting was a spreadsheet with all model methods, their functions and proposed changes. This spreadsheet was the used as the baseline for the entire project Following through with getting timely feedback from all stakeholders, this proposal was discussed with the Instructor and modified as per comments received. With the first set of requirements ready, the code could now be worked upon.
With the goal being refactoring and testing of the models, before any code changes could be made the existing tests needed to be verified to run successfully. Unit tests deal with models. Therefore the test files participant_test.rb, assignment_participant_test.rb and course_participant_test.rb were run , but found to have bugs. These were fixed (explained in detail in sections below). The only test that still failed was in assignment_participant_test.rb and dealt with the publishing rights functionality which is not yet working in the expertiza project. Hence this test's failure was expected behavior and thus ignored. Certain basic guidelines followed for improving the code design were :

  1. Re-use code as much as possible
  2. Make the code DRY and remove code duplication
  3. Remove redundant or unnecessary methods
  4. Redesign the code to make it more object oriented
  5. Due to the hierarchy structure of the models, common functionality between the models needed to be moved to the base class
  6. Specialized methods not relevant to the super-class should be moved to the sub-class it applies to
  7. Any deprecated code must be modified in accordance with the new norms to ensure smooth running of code in future versions of Rails<ref>http://stackoverflow.com/questions/15098961/findfirst-and-findall-are-deprecated</ref>
  8. Rename methods to conform better with Ruby naming conventions
  9. Improve the readability of the code

UML Class Diagram

A subset of the UML class diagram including only the related classes for this project can be drawn as shown below. UML class diagram

Participant is the superclass for subclasses AssignmentParticipant and CourseParticipant. In the database to actually distinguish between these a type attribute is used which can take values as 'AssignmentParticipant' or 'CourseParticipant' while a participant that does not belong to either an assignment nor a course cannot exist in the system as he just becomes a user and not a participant.
A participant has a user i.e. only a user can become a participant.
An AssignmentParticipant has an assignment and a CourseParticipant has a course. This relationship is defined by the parent_id attribute of a participant.

Participant model: participant.rb

The Participant model class being the base class should only contain code or methods that are relevant or needed by both the subclasses. But instead , it was cluttered with methods that would be better placed in one of the child classes as they are relevant to only that subclass. Such methods were moved to the respective sub-classes. Also certain functionalities that were common between both subclasses were repeated in both leading to code repetition. Such methods were moved to Participant class and will be dealt with in the later sections of this article. Several methods in Participant model required renaming and refactoring to ensure that the change is reflected in the entire project. The names were changed to follow method naming convention. Deprecated code was removed and re-coded to ensure that the code worked in future versions of Rails as well.

Sr. No. Method Name Changes Made Reason For Change
1 able_to_submit It has been commented out. Method not called or used anywhere. Also the method just returned the value of the attribute submit_allowed which is already taken care of by attr_accessors.
2 force_delete The deprecated code in this method has been changed. To ensure the code works in future versions of Rails.
3 get_average_question_score Renamed to average_question_score and refactored. To conform to method naming convention.
4 get_average_score Renamed to average_score and refactored also moved to the model assignment_participant.rb. Removed empty parentheses from declaration The new name is more in keeping with method naming conventions. Removal of empty parentheses helps with poetry mode of code. The method was moved because calculation of average score is only relevant to AssignmentParticipant and not to CourseParticipant.
5 get_current_stage Moved to the model - assignment_participants.rb The method was moved because getting current stage of an assignment is only relevant to AssignmentParticipant and not to CourseParticipant.
6 get_stage_deadline Moved to model - assignment_participant.rb Just like get_current_stage, this method too is only relevant to AssignmentParticipant and not to CourseParticipant.
7 get_topic_string Renamed to topic_string and refactored. To follow method naming convention
8 review_response_maps Moved to model - assignment_participant.rb Reviews are made only on assignments and hence ReviewResponseMaps would only exist for between the participants of an assignment. Thus this method would be better placed in AssignmentParticipant.

After changes were made, the existing tests ran successfully.

AssignmentParticipant model: assignment_participant.rb

Several methods in AssignmentParticipant model class required renaming and refactoring to ensure that the change is reflected in the entire project. The names were changed to follow method naming conventions in Ruby. Deprecated code was removed and re-coded to ensure that the code worked in future version of Rails as well. Duplicate codes were commented out. Methods that are more general in the sub classes were moved to the parent class. Some methods that calculate the collusion in reviews between students were moved to a newly created model class called CollusionCycle in file collusion_cycle.rb .

Sr. No. Method Name Changes Made Reason For Change
1 get_course_string Renamed to course_string and refactored To follow method naming convention
2 get_cycle_deviation_score Moved to collusion_cycle.rb model class Related methods that calculate collusion in reviews have been moved to the newly created collusion_cycle.rb model class
3 get_cycle_similarity_score Moved to collusion_cycle.rb model class Related methods that calculate collusion in reviews have been moved to the newly created collusion_cycle.rb model class
4 get_feedback Renamed to feedback and refactored To follow method naming convention
5 get_files Renamed to files_in_directory and refactored To follow method naming convention
6 get_four_node_cycles Moved to collusion_cycle.rb model class Related methods that calculate collusion in reviews have been moved to the newly created collusion_cycle.rb model class
7 fullname Moved to parent model class – participant.rb General methods of the subclass are moved to Parent class
8 get_metareviews Renamed to metareviews and refactored To follow method naming convention
9 name Commented the method The method is already in parent model class – participant.rb and can be used in this subclass through inheritance
10 name Commented the method The method is already in parent model class – participant.rb and can be used in this subclass through inheritance. Also it is a duplicate method in patricipant.rb
11 get_review_score Renamed to review_score and refactored. Deprecated code has been removed and replaced with correct code. To follow method naming convention and ensure the code works in future versions.
12 get_reviewees Renamed to reviewees and refactored. Deprecated code has been removed and replaced with correct code. To follow method naming convention and ensure the code works in future versions.
13 get_reviewers Renamed to reviewers and refactored . Deprecated code has been commented and replaced with correct code. To follow method naming convention and ensure the code works in future versions.
14 get_reviews Renamed to reviews and refactored To follow method naming convention
15 get_reviews_by_reviewer Renamed to reviews_by_reviewer and refactored To follow method naming convention
16 get_reviews_by_reviewer Commented the method To remove duplicated method in this class
17 get_scores Renamed to scores and refactored To follow method naming convention
18 get_submitted_files Renamed to submitted_files and refactored To follow method naming convention
19 get_teammate_reviews Renamed to teammate_reviews and refactored To follow method naming convention
20 get_three_node_cycles Moved to collusion_cycle.rb model class Related methods that calculate collusion in reviews have been moved to the newly created collusion_cycle.rb model class
21 get_topic_string Method has been Commented It is already present in model super class – participant.rb
22 get_two_node_cycles Moved to collusion_cycle.rb model class Related methods that calculate collusion in reviews have been moved to the newly created collusion_cycle.rb model class
23 get_wiki_submissions Renamed to wiki_submissions and refactored To follow method naming convention

After changes were made, the existing tests ran successfully.

CourseParticipant model:course_participant.rb

The CourseParticipant model has methods like get_path and self.get_export_fields which were present in both assignment_participant.rb and course_participant.rb. Since they had dynamic usages, they could not be deleted from the two subclasses and placed in participant.rb.

Sr. No. Method Name Changes Made Reason For Change
1 get_course_string Renamed to course_string and refactored To follow method naming convention.

Changes to yaml files <ref>http://stackoverflow.com/questions/19442688/when-i-run-rails-server-it-is-showing-error-about-database-yml</ref>

Sr. No. Method Name Changes Made Reason For Change
1 invitation.yml The indentation was corrected. Improper Indentation in invitation.yml was throwing errors.
2 users.yml 1.The symbol ‘:password’ was renamed to ‘:crypted_password’

2.‘fullname :last,first’ was added inside ‘student1:’

1.Attribute name is crypted_password in user.rb

2.Fixture was missing definition of fullname which required for the tests.

Testing <ref> http://guides.rubyonrails.org/testing.html </ref>

course_participant_test.rb

Changed the following line :

CourseParticipant.import(['luke','Luke Skywalker','luke@gmail.com','darthvader'],{:user=>users(:superadmin)},courses(:course_e_commerce).id)

to

CourseParticipant.import(['luke','Skywalker,Luke','luke@gmail.com','darthvader'],{:user=>users(:superadmin)},courses(:course_e_commerce).id)

This was done to follow the syntax of fullname i.e.last_name,first_name which is a requirement of the application.

Rspec tests

participant_spec.rb
created to check basic functionality of paticipant.rb

It checks for:
1.Associations with other tables.
2.Entry and update of records.

Changes in routes.rb <ref>http://guides.rubyonrails.org/routing.html</ref>

The following missing routes were added to the file routes.rb to make the program flow smoothly.

Routes for submit_hyperlink and remove_hyperlink were added to the submitted_content controller as :

resources :submitted_content do
   collection do
     get :view
     get :edit
     post :submit_hyperlink
     get :remove_hyperlink
   end
 end

Routes for the get and post methods of the export_file controller were added :

resources :export_file do
   collection do
     get :start
     get :export
     post :export
   end
 end

Routes for cancel, accept and decline were added to the invitation controller :

 resources :invitation do
   collection do
     get :cancel
     get :accept
     get :decline
   end
 end

Scope for future work

  • The tests related to ‘publishing_rights’ method in assignment_participant_test.rb still fail, but this is expected as this feature of publishing_rights has not yet been implemented in Expertiza.
  • The delete hyperlink method needs to be fixed as currently this feature is bugged in the running Expertiza.
  • A test for cycle_collusion.rb proposed as:
class CycleCollusionTest < ActiveSupport::TestCase
	fixtures :response_maps, :users , :assignments
          test "collusion" do
          r = ResponseMap.new
          r.reviewee_id= response_maps(:response_maps0)  //his work was reviewed by user1
          r.reviewer_id= response_maps(:response_maps1) //he reviewed user0's work
          r.reviewee_id1=response_maps(:response_maps1)  //his work was reviewed by user0 
          r.reviewer_id1=response_maps(:response_maps0)  //he reviewed user1's work
          !assert_equal r.reviewee_id, r.reviewer_id1
          end

Could not be tested effectively as cycle_collusion is not used anywhere in the code except in assignment_participant.rb where the methods now belonging to cycle_collusion class were originally present.

  • The feature of sending an email when a user gets registered for an assignment i.e.becomes an assignment participant needs to be implemented.

Conclusion

  • Renaming and refactoring was performed as per requirements and to follow conventions for the appropriate methods in participant.rb, assignment_participant.rb and course_participant.rb.
  • Bugs in existing tests of model classes’ participant.rb, assignment_participant.rb and course_participant.rb (that were initially not running) were fixed and made to run without errors.
  • All tests in participant.rb, assignment_participant.rb and course_participant.rb- (except those related to publishing_rights due to absence of its functionality) ran successfully after changes were made to the three model files.

References

<references/>

See Also