https://wiki.expertiza.ncsu.edu/api.php?action=feedcontributions&feedformat=atom&user=Sayenga 2026-05-16T09:09:20Z User contributions MediaWiki 1.41.0 https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=82340 2013-11-01T17:13:31Z

<p>Sayenga: </p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. <br /> #Some part of the code which had common functionality were removed and the function calls were also redirected accordingly to the specific views.<br /> <br /> === '''Issues'''===<br /> *'''Refactoring issues'''<br /> #Since we had two controllers for the signup sheet, there were many functions which had nested calls and needed to be taken care.<br /> ##For example, slotAvailble?() was called from both controller and the sign_up_topic model.<br /> #As waitlist was created as a singleton class with no table structure it was difficult to make use of attributes of other classes in it as attributes can be inherited or used only if they have associativity at schema level.<br /> #By defining the functions in the models, we had to take care of the dependencies of the instance variables defined and used in the controller and interaction between several models had to be taken care. <br /> #Controllers have the flexibility to directly make use of the parameters from the specific views whereas defining them in models had to carefully set and passed. Since some of the parameters were used in multiple views, it needed to be updated in several places.<br /> #Some of the methods that were modularised were conflicting as they were modified to class methods from being an instance method.<br /> <br /> *'''Redundant Test issues'''<br /> #Since the code has been developed over the years and refactored by multiple developers, there were several redundant tests and identifying them was a huge task.<br /> #The rspec environment variable along with the spec_helper had to be freshly created for the test framework suite to be recognized.<br /> <br /> *'''Deployment issues'''<br /> #Merging of branches from the local to the remote repository at the right level was initially being an overhead.<br /> #This was overcome by cloning a specific branch using: git clone -b &lt;branch_name&gt; &lt;remote_url&gt;.<br /> #Earlier commits do not have a proper commit message to refer.<br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup,mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below.<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes that we have made as a part of our project.<br /> <br /> === '''Testing''' ===<br /> <br /> Testing was done using rspec as most of our work involved moving from the controller class and as rspec allows to create a single http request for each test case.<br /> <br /> ==== '''Set up environment for Testing''' ====<br /> #Go to Run -&gt; Edit Configuraions -&gt;RSpec -&gt; Select All tests in folder and Test file name mask: **/*_spec.rb<br /> #Check the run the script in context of the bundle<br /> #Configuration -&gt; Working directory must be pointed to the root of the application. Apply the changes<br /> #Run rspec:install form Rails Generator to create a rspec_helper.rb which will have the RAILS_ENV(= 'test')<br /> #rake db:migrate<br /> #rake spec<br /> #run all tests in spec.<br /> <br /> <br /> ==== '''Sample Test Case''' ====<br /> <br /> describe &quot;GET show&quot; do<br /> it &quot;assigns the requested signup_topic as @signup_topic&quot; do<br /> signup_topic = SignupTopic.create! valid_attributes<br /> get :show, {:id =&gt; signup_topic.to_param}, valid_session<br /> assigns(:signup_topic).should eq(signup_topic)<br /> end<br /> end<br /> <br /> describe &quot;GET new&quot; do<br /> it &quot;assigns a new signup_topic as @signup_topic&quot; do<br /> get :new, {}, valid_session<br /> assigns(:signup_topic).should be_a_new(SignupTopic)<br /> end<br /> end<br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81191 2013-10-30T19:30:45Z

<p>Sayenga: /* Issues */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. <br /> #Some part of the code which had common functionality were removed and the function calls were also redirected accordingly to the specific views.<br /> <br /> === '''Issues'''===<br /> *'''Refactoring issues'''<br /> #Since we had two controllers for the signup sheet, there were many functions which had nested calls and needed to be taken care.<br /> ##For example, slotAvailble?() was called from both controller and the sign_up_topic model.<br /> #As waitlist was created as a singleton class with no table structure it was difficult to make use of attributes of other classes in it as attributes can be inherited or used only if they have associativity at schema level.<br /> #By defining the functions in the models, we had to take care of the dependencies of the instance variables defined and used in the controller and interaction between several models had to be taken care. <br /> #Controllers have the flexibility to directly make use of the parameters from the specific views whereas defining them in models had to carefully set and passed. Since some of the parameters were used in multiple views, it needed to be updated in several places.<br /> #Some of the methods that were modularised were conflicting as they were modified to class methods from being an instance method.<br /> <br /> *'''Redundant Test issues'''<br /> #Since the code has been developed over the years and refactored by multiple developers, there were several redundant tests and identifying them was a huge task.<br /> #The rspec environment variable along with the spec_helper had to be freshly created for the test framework suite to be recognized.<br /> <br /> *'''Deployment issues'''<br /> #Merging of branches from the local to the remote repository at the right level was initially being an overhead.<br /> #This was overcome by cloning a specific branch using: git clone -b &lt;branch_name&gt; &lt;remote_url&gt;.<br /> #Earlier commits do not have a proper commit message to refer.<br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81184 2013-10-30T19:28:18Z

<p>Sayenga: /* Issues */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. <br /> #Some part of the code which had common functionality were removed and the function calls were also redirected accordingly to the specific views.<br /> <br /> === '''Issues'''===<br /> *'''Refactoring issues'''<br /> #Since we had two controllers for the signup sheet, there were many functions which had nested calls and needed to be taken care.<br /> ##For example, slotAvailble?() was called from both controller and the sign_up_topic model.<br /> #As waitlist was created as a singleton class with no table structure it was difficult to make use of attributes of other classes in it as attributes can be inherited or used only if they have associativity at schema level.<br /> #By defining the functions in the models, we had to take care of the dependencies of the instance variables defined and used in the controller and interaction between several models had to be taken care. <br /> #Controllers have the flexibility to directly make use of the parameters from the specific views whereas defining them in models had to carefully set and passed. Since some of the parameters were used in multiple views, it needed to be updated in several places.<br /> #Some of the methods that were modularised were conflicting as they were modified to class methods from being an instance method.<br /> <br /> *'''Redundant Test issues'''<br /> #Since the code has been developed over the years and refactored by multiple developers, there were several redundant tests and identifying them was a huge task.<br /> <br /> *'''Deployment issues'''<br /> #Merging of branches from the local to the remote repository at the right level was initially being an overhead.<br /> #This was overcome by cloning a specific branch using: git clone -b &lt;branch_name&gt; &lt;remote_url&gt;.<br /> #Earlier commits do not have a proper commit message to refer.<br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81183 2013-10-30T19:26:59Z

<p>Sayenga: /* Issues */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. <br /> #Some part of the code which had common functionality were removed and the function calls were also redirected accordingly to the specific views.<br /> <br /> === '''Issues'''===<br /> *'''Refactoring issues'''<br /> #Since we had two controllers for the signup sheet, there were many functions which had nested calls and needed to be taken care.<br /> ##For example, slotAvailble?() was called from both controller and the sign_up_topic model.<br /> #As waitlist was created as a singleton class with no table structure it was difficult to make use of attributes of other classes in it as attributes can be inherited or used only if they have associativity at schema level.<br /> #By defining the functions in the models, we had to take care of the dependencies of the instance variables defined and used in the controller and interaction between several models had to be taken care. <br /> #Controllers have the flexibility to directly make use of the parameters from the specific views whereas defining them in models had to carefully set and passed. Since some of the parameters were used in multiple views, it needed to be updated in several places.<br /> #Some of the methods that were modularised were conflicting as they were modified to class methods from being an instance method.<br /> <br /> *'''Redundant Test issues'''<br /> #Since the code has been developed over the years and refactored by multiple developers, there were several redundant tests and identifying them was a huge task.<br /> <br /> *'''Deployment issues'''<br /> #Merging of branches from the local to the remote repository at the right level was initially being an overhead creating multiple levels.<br /> #This was overcome by cloning a specific branch using: git clone -b &lt;branch_name&gt; &lt;remote_url&gt;<br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81181 2013-10-30T19:26:49Z

<p>Sayenga: /* Issues */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. <br /> #Some part of the code which had common functionality were removed and the function calls were also redirected accordingly to the specific views.<br /> <br /> === '''Issues'''===<br /> *'''Refactoring issues'''<br /> #Since we had two controllers for the signup sheet, there were many functions which had nested calls and needed to be taken care.<br /> ##For example slotAvailble?() was called from both controller and the sign_up_topic model.<br /> #As waitlist was created as a singleton class with no table structure it was difficult to make use of attributes of other classes in it as attributes can be inherited or used only if they have associativity at schema level.<br /> #By defining the functions in the models, we had to take care of the dependencies of the instance variables defined and used in the controller and interaction between several models had to be taken care. <br /> #Controllers have the flexibility to directly make use of the parameters from the specific views whereas defining them in models had to carefully set and passed. Since some of the parameters were used in multiple views, it needed to be updated in several places.<br /> #Some of the methods that were modularised were conflicting as they were modified to class methods from being an instance method.<br /> <br /> *'''Redundant Test issues'''<br /> #Since the code has been developed over the years and refactored by multiple developers, there were several redundant tests and identifying them was a huge task.<br /> <br /> *'''Deployment issues'''<br /> #Merging of branches from the local to the remote repository at the right level was initially being an overhead creating multiple levels.<br /> #This was overcome by cloning a specific branch using: git clone -b &lt;branch_name&gt; &lt;remote_url&gt;<br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81179 2013-10-30T19:26:34Z

<p>Sayenga: /* Issues */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. <br /> #Some part of the code which had common functionality were removed and the function calls were also redirected accordingly to the specific views.<br /> <br /> === '''Issues'''===<br /> *'''Refactoring issues'''<br /> #Since we had two controllers for the signup sheet, there were many functions which had nested calls and needed to be taken care.<br /> **For example slotAvailble?() was called from both controller and the sign_up_topic model.<br /> #As waitlist was created as a singleton class with no table structure it was difficult to make use of attributes of other classes in it as attributes can be inherited or used only if they have associativity at schema level.<br /> #By defining the functions in the models, we had to take care of the dependencies of the instance variables defined and used in the controller and interaction between several models had to be taken care. <br /> #Controllers have the flexibility to directly make use of the parameters from the specific views whereas defining them in models had to carefully set and passed. Since some of the parameters were used in multiple views, it needed to be updated in several places.<br /> #Some of the methods that were modularised were conflicting as they were modified to class methods from being an instance method.<br /> <br /> *'''Redundant Test issues'''<br /> #Since the code has been developed over the years and refactored by multiple developers, there were several redundant tests and identifying them was a huge task.<br /> <br /> *'''Deployment issues'''<br /> #Merging of branches from the local to the remote repository at the right level was initially being an overhead creating multiple levels.<br /> #This was overcome by cloning a specific branch using: git clone -b &lt;branch_name&gt; &lt;remote_url&gt;<br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81177 2013-10-30T19:26:04Z

<p>Sayenga: /* Issues */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. <br /> #Some part of the code which had common functionality were removed and the function calls were also redirected accordingly to the specific views.<br /> <br /> === '''Issues'''===<br /> *'''Refactoring issues'''<br /> #Since we had two controllers for the signup sheet, there were many functions which had nested calls and needed to be taken care.<br /> For example slotAvailble?() was called from both controller and the sign_up_topic model.<br /> #As waitlist was created as a singleton class with no table structure it was difficult to make use of attributes of other classes in it as attributes can be inherited or used only if they have associativity at schema level.<br /> #By defining the functions in the models, we had to take care of the dependencies of the instance variables defined and used in the controller and interaction between several models had to be taken care. <br /> #Controllers have the flexibility to directly make use of the parameters from the specific views whereas defining them in models had to carefully set and passed. Since some of the parameters were used in multiple views, it needed to be updated in several places.<br /> #Some of the methods that were modularised were conflicting as they were modified to class methods from being an instance method.<br /> <br /> *'''Redundant Test issues'''<br /> #Since the code has been developed over the years and refactored by multiple developers, there were several redundant tests and identifying them was a huge task.<br /> <br /> *'''Deployment issues'''<br /> #Merging of branches from the local to the remote repository at the right level was initially being an overhead creating multiple levels.<br /> #This was overcome by cloning a specific branch using: git clone -b &lt;branch_name&gt; &lt;remote_url&gt;<br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81176 2013-10-30T19:25:56Z

<p>Sayenga: /* Issues */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. <br /> #Some part of the code which had common functionality were removed and the function calls were also redirected accordingly to the specific views.<br /> <br /> === '''Issues'''===<br /> *'''Refactoring issues'''<br /> #Since we had two controllers for the signup sheet, there were many functions which had nested calls and needed to be taken care.<br /> For example slotAvailble?() was called from both controller and the sign_up_topic model.<br /> #As waitlist was created as a singleton class with no table structure it was difficult to make use of attributes of other classes in it as attributes can be inherited or used only if they have associativity at schema level.<br /> #By defining the functions in the models, we had to take care of the dependencies of the instance variables defined and used in the controller and interaction between several models had to be taken care. <br /> #Controllers have the flexibility to directly make use of the parameters from the specific views whereas defining them in models had to carefully set and passed. Since some of the parameters were used in multiple views, it needed to be updated in several places.<br /> #Some of the methods that were modularised were conflicting as they were modified to class methods from being an instance method.<br /> <br /> *'''Redundant Test issues'''<br /> #Since the code has been developed over the years and refactored by multiple developers, there were several redundant tests and identifying them was a huge task.<br /> <br /> *'''Deployment issues'''<br /> #Merging of branches from the local to the remote repository at the right level was initially being an overhead creating multiple levels.<br /> #This was overcome by cloning a specific branch using: git clone -b &lt;branch_name&gt; &lt;remote_url&gt;<br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81175 2013-10-30T19:25:40Z

<p>Sayenga: /* Issues */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. <br /> #Some part of the code which had common functionality were removed and the function calls were also redirected accordingly to the specific views.<br /> <br /> === '''Issues'''===<br /> *'''Refactoring issues'''<br /> #Since we had two controllers for the signup sheet, there were many functions which had nested calls and needed to be taken care.<br /> ##For example slotAvailble?() was called from both controller and the sign_up_topic model.<br /> #As waitlist was created as a singleton class with no table structure it was difficult to make use of attributes of other classes in it as attributes can be inherited or used only if they have associativity at schema level.<br /> #By defining the functions in the models, we had to take care of the dependencies of the instance variables defined and used in the controller and interaction between several models had to be taken care. <br /> #Controllers have the flexibility to directly make use of the parameters from the specific views whereas defining them in models had to carefully set and passed. Since some of the parameters were used in multiple views, it needed to be updated in several places.<br /> #Some of the methods that were modularised were conflicting as they were modified to class methods from being an instance method.<br /> <br /> *'''Redundant Test issues'''<br /> #Since the code has been developed over the years and refactored by multiple developers, there were several redundant tests and identifying them was a huge task.<br /> <br /> *'''Deployment issues'''<br /> #Merging of branches from the local to the remote repository at the right level was initially being an overhead creating multiple levels.<br /> #This was overcome by cloning a specific branch using: git clone -b &lt;branch_name&gt; &lt;remote_url&gt;<br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81174 2013-10-30T19:25:30Z

<p>Sayenga: /* Issues */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. <br /> #Some part of the code which had common functionality were removed and the function calls were also redirected accordingly to the specific views.<br /> <br /> === '''Issues'''===<br /> *'''Refactoring issues'''<br /> #Since we had two controllers for the signup sheet, there were many functions which had nested calls and needed to be taken care.<br /> ##For example slotAvailble?() was called from both controller and the sign_up_topic model.<br /> #As waitlist was created as a singleton class with no table structure it was difficult to make use of attributes of other classes in it as attributes can be inherited or used only if they have associativity at schema level.<br /> #By defining the functions in the models, we had to take care of the dependencies of the instance variables defined and used in the controller and interaction between several models had to be taken care. <br /> #Controllers have the flexibility to directly make use of the parameters from the specific views whereas defining them in models had to carefully set and passed. Since some of the parameters were used in multiple views, it needed to be updated in several places.<br /> #Some of the methods that were modularised were conflicting as they were modified to class methods from being an instance method.<br /> <br /> *'''redundant Test issues'''<br /> #Since the code has been developed over the years and refactored by multiple developers, there were several redundant tests and identifying them was a huge task.<br /> <br /> *'''Deployment issues'''<br /> #Merging of branches from the local to the remote repository at the right level was initially being an overhead creating multiple levels.<br /> #This was overcome by cloning a specific branch using: git clone -b &lt;branch_name&gt; &lt;remote_url&gt;<br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81166 2013-10-30T19:21:49Z

<p>Sayenga: /* Issues */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. <br /> #Some part of the code which had common functionality were removed and the function calls were also redirected accordingly to the specific views.<br /> <br /> === '''Issues'''===<br /> *'''While Refactoring'''<br /> #Since we had two controllers for the signup sheet, there were many functions which had nested calls and needed to be taken care.<br /> For example slotAvailble?() was called from both controller and the sign_up_topic model.<br /> #As waitlist was created as a singleton class with no table structure it was difficult to make use of attributes of other classes in it as attributes can be inherited or used only if they have associativity at schema level.<br /> #By defining the functions in the models, we had to take care of the dependencies of the instance variables defined and used in the controller and interaction between several models had to be taken care. <br /> #Controllers have the flexibility to directly make use of the parameters from the specific views whereas defining them in models had to carefully set and passed. Since some of the parameters were used in multiple views, it needed to be updated in several places.<br /> #Some of the methods that were modularised were conflicting as they were modified to class methods from being an instance method.<br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81023 2013-10-30T18:35:41Z

<p>Sayenga: /* Modified Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. <br /> #Some part of the code which had common functionality were removed and the function calls were also redirected accordingly to the specific views.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81019 2013-10-30T18:35:01Z

<p>Sayenga: /* Modified Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> #The methods such as sign_up were redundantly present in both the controllers. Thus some part of the code which had common functionality were removed and the function calls were also redirected accordingly.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81018 2013-10-30T18:34:51Z

<p>Sayenga: /* Modified Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> **The methods such as sign_up were redundantly present in both the controllers. Thus some part of the code which had common functionality were removed and the function calls were also redirected accordingly.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81017 2013-10-30T18:34:43Z

<p>Sayenga: /* Modified Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''<br /> *The methods such as sign_up were redundantly present in both the controllers. Thus some part of the code which had common functionality were removed and the function calls were also redirected accordingly.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81015 2013-10-30T18:34:29Z

<p>Sayenga: /* Modified Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''*<br /> *The methods such as sign_up were redundantly present in both the controllers. Thus some part of the code which had common functionality were removed and the function calls were also redirected accordingly.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=81013 2013-10-30T18:34:14Z

<p>Sayenga: /* Initial Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> *Initially the sign_up_sheet_controller had huge methods with no comments and multiple variable decalarations.<br /> *The other major drawback with the initial design was there were redundant methods in sign_up_sheet_controller and sign_up_controller.<br /> <br /> ===='''Modified Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> *'''Removing Redundancy from sign_up_controller'''*<br /> * The methods such as sign_up were redundantly present in both the controllers. Thus some part of the code which had common functionality were removed and the function calls were also redirected accordingly.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80999 2013-10-30T18:28:32Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> ===='''Initial Design'''====<br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80990 2013-10-30T18:25:14Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> <br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80981 2013-10-30T18:22:55Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> <br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> <br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword &quot;self&quot; prepended to them.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80978 2013-10-30T18:22:40Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> <br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> <br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword ' self ' prepended to them.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80977 2013-10-30T18:22:23Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> <br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> <br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword 'self' prepended to them.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80975 2013-10-30T18:22:07Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> <br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> <br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the '''Singleton pattern''' as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword self prepended to them.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80969 2013-10-30T18:20:27Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> <br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a '''Collaborative design''' based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> <br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the singleton pattern as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword self prepended to them.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80966 2013-10-30T18:20:00Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> <br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *'''Refactoring the sign_up_sheet_controller for modularity and flexibility:'''<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a Collaborative design based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> <br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *'''Adding a waitlist model:'''<br /> #The newly formed waitlist model follows the singleton pattern as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword self prepended to them.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80961 2013-10-30T18:18:23Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> <br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *Refactoring the sign_up_sheet_controller for modularity and flexibility:<br /> #By defining functions in the desired class and making only calls to the specific controller, we have implemented a Collaborative design based on CRC modelling: <br /> ##finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> ##finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> ##defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> <br /> #This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> ##Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> ##Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *Adding a waitlist model:<br /> #The newly formed waitlist model follows the singleton pattern as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword self prepended to them.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80955 2013-10-30T18:17:24Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> <br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *Refactoring the sign_up_sheet_controller for modularity and flexibility:<br /> **By defining functions in the desired class and making only calls to the specific controller, we have implemented a Collaborative design based on CRC modelling: <br /> #finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> #finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> #defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> <br /> *This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> #Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> #Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *Adding a waitlist model:<br /> #The newly formed waitlist model follows the singleton pattern as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword self prepended to them.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80953 2013-10-30T18:17:03Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> <br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *Refactoring the sign_up_sheet_controller for modularity and flexibility:<br /> **By defining functions in the desired class and making only calls to the specific controller, we have implemented a Collaborative design based on CRC modelling: <br /> #finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> #finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> #defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> <br /> **This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> #Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> #Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *Adding a waitlist model:<br /> #The newly formed waitlist model follows the singleton pattern as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> #The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword self prepended to them.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80949 2013-10-30T18:16:18Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> <br /> The refactoring required us to modularize and push some of the functionalities in sign_up_sheet_controller.rb to sign_up_topic.rb (model) and waitlist.rb ( model).<br /> This demanded to make calls from remove_team and reassign_topic from sign_up_topic model to signup_topics method in sign_up_sheet_controller. Similarly the controller also used methods waitlist_teams and cancel_all_waitlists from the waitlist model.<br /> <br /> *Refactoring the sign_up_sheet_controller for modularity and flexibility:<br /> **By defining functions in the desired class and making only calls to the specific controller, we have implemented a Collaborative design based on CRC modelling: <br /> #finding classes/ models - sign_up_topic.rb and waitlist.rb<br /> #finding responsibilities - remove_team, reassign_topic in sign_up_topic.rb, cancel-all_waitlists, waitlist_teams in waitlist.rb<br /> #defining the collaborators - confirm_topic, delete_signup_topic, signup_topics in sign_up_sheet_controller.rb<br /> <br /> ** This has also made it more flexible for the developers as a change in the db or table design can be easily tracked. <br /> #Easily implemented in the respective models and by passing the correct type/number parameters in the controllers. <br /> #Reduces overhead of rewriting methods and keeping track of the method calls.<br /> <br /> *Adding a waitlist model:<br /> **The newly formed waitlist model follows the singleton pattern as it is an independent class and also the waitlist for a topic is a single queue or list on which multiple teams and individuals wait on.<br /> **The methods defined in waitlist model are singleton methods and thus are defined as class methods with the keyword self prepended to them.<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic_new.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams_new.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists_new.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic_new.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic_new.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics_new.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team_new.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/oss_ssp&diff=80768 2013-10-30T16:31:49Z

<p>Sayenga: /* Design */</p> <hr /> <div>== '''OSS E803 Refactoring and testing — signup_sheet model''' ==<br /> <br /> === '''Motivation''' ===<br /> <br /> The motivation of this project was to provide functionality to manage Sign Up Sheets. The intent was to improve the design of the project by modularizing the code and maintaining good naming conventions. The methods relevant to wait-listing a team were all a part of the Sign Up sheet model and controller. in order to improve the readability of the code and to have a better organization, we intended to move these methods to a separate Waitlist Model. Also, some methods had too many functionalities, a lot more than what their names suggested. To have a more elegant code, the functionalities had to be moved to relevant methods. cancel_all_waitlists and waitlist_teams methods were created in the waitlist model for this purpose. Naming conventions are considered very important for making the code more readable and understandable. Ruby is known for its 'Convention over Configuration' ideology. Thus the naming conventions had to be taken care of. In the Sign Up sheet controller, we could see the usage of Camel cases in a lot of places. We intended to replace these by the convention of Ruby where underscore is used between two words in variable names with all the alphabets in small letters.<br /> <br /> <br /> === '''Design'''===<br /> <br /> === '''Issues'''===<br /> <br /> <br /> <br /> === '''Procedure'''===<br /> <br /> ====A brief description====<br /> <br /> Our OSS project required us to do refactoring and testing of the part of Expertiza that deals with signup mainly sign_up_sheet controller. This controller manages functionalities of signup sheet for assignment. We have moved a few methods from controller to a more suitable model in order to attain the “thin controller, fat model” implementation. A major part includes the actions related to waitlist. We have put methods from sign_up_sheet controller to the waitlist model (which was earlier empty, so we created a waitlist model by adding functionalities to it)<br /> A brief description of the refactoring that we have done is given below<br /> <br /> =====Add teams to waiting list=====<br /> We have moved the functionality that adds teams to waiting list when the topic is unavailable. We have moved this functionality from confirm_topic in sign_up_sheet controller to waitlist_teams method that we have created in waitlist controller.<br /> <br /> [[File:confirm_topic.png]]<br /> <br /> This shows the method confirm_topic in sign_up_sheet controller that contains call to waitlist_teams method in waitlist controller. <br /> <br /> [[File:waitlist_teams.png]]<br /> <br /> This method has definition for waitlist_teams and is defined in waitlist model.<br /> <br /> =====Cancel waitlist=====<br /> We have moved the functionality that removes a team from the waiting list, from sign_up_topic model to waitlist model. The method name is cancel_all_waitlist.<br /> <br /> [[File:cancel_all_waitlists.png]]<br /> <br /> =====Reassign a topic=====<br /> We have moved the functionality that reassigns a topic to another team when a team holding that particular topic cancels its reservation. We have moved this functionality from delete_signup_for_topic in sign_up_sheet controller to a method named reassign_topic that we have created in sign_up_topic model. <br /> <br /> [[File:for_reassign_topic.png]]<br /> <br /> This shows the method delete_signup_for_topic in sign_up_sheet controller that contains call to reassign_topic method in sign_up_topic model.<br /> <br /> [[File:reassign_topic.png]]<br /> <br /> This method has definition for reassign_topic and is defined in sign_up_topic model.<br /> <br /> =====Remove team from topic=====<br /> We have moved the functionality that removes a team from a topic when all of the team’s members have left the team. We have moved this functionality from signup_topics in sign_up_sheet controller to a method named remove_team that we have created in sign_up_topic model. <br /> <br /> [[File:signup_topics.png]]<br /> <br /> This shows the method signup_topics in sign_up_sheet controller that contains call to remove_team method in sign_up_topic model.<br /> <br /> [[File:remove_team.png]]<br /> <br /> This method has definition for remove_team and is defined in sign_up_topic model.<br /> Rest, we have done renaming at a few places in sign_up_sheet controller.<br /> <br /> ====Snapshots====<br /> Here, we have a few snapshots that would guide one to walk-through our work and the areas wherein we did refactoring.<br /> <br /> <br /> [[File:Login_admin_new.png]]<br /> <br /> Login as an admin.<br /> <br /> <br /> [[File:manage_courses_new.png]]<br /> <br /> Go to manage-&gt;courses<br /> <br /> <br /> [[File:create_assignment_new.png]]<br /> <br /> Create an assignment by filling in the required fields and selecting the checkboxes.<br /> <br /> <br /> [[File:create_users_new.png]]<br /> <br /> Create users by filling in the required fields.<br /> <br /> <br /> [[File:add_participants_admin_new.png]]<br /> <br /> Again go to Manage courses and as shown in the snapshot above, one can see actions associated with an assignment. Click on add participants.<br /> <br /> <br /> [[File:add_participants2_admin.png]]<br /> <br /> Add a user to an assignment as a participant.<br /> <br /> <br /> [[File:participant_added.png]]<br /> <br /> The participant is added.<br /> <br /> <br /> [[File:add_signupsheet.png]]<br /> <br /> Also, through manage-&gt; courses, add signup sheet to an assignment in a similar manner as adding participants.<br /> <br /> <br /> [[File:add_topic.png]]<br /> <br /> When a signup sheet is created, add new topics to it in the similar manner<br /> <br /> <br /> [[File:topic_created.png]]<br /> <br /> Topic is successfully created. Logout of admin system<br /> <br /> <br /> [[File:login.png]] <br /> <br /> Now login as an user.<br /> <br /> <br /> [[File:top.png]]<br /> <br /> Go to the assignments on top<br /> <br /> <br /> [[File:select_one_assignment.png]]<br /> <br /> Select one assignment from the list of assignments.<br /> <br /> <br /> [[File:click_signup_sheet.png]]<br /> <br /> Select signup sheet<br /> <br /> <br /> [[File:can_view_signup_sheet.png]]<br /> <br /> One can view signup sheet and signup for the topic<br /> <br /> <br /> [[File:signing_up.png]]<br /> <br /> After signing up, here for example for topic 1234, the user has the topic and the no. of available slot shows 0<br /> <br /> <br /> [[File:shows_waiting.png]]<br /> <br /> Now, if another user tries to sign up for the same topic, he is put on waitlist.<br /> <br /> <br /> This is a brief illustration of the changes we have made as a part of our project.<br /> <br /> <br /> <br /> <br /> === '''Future Work'''===<br /> <br /> The sign up sheet controller still has many methods relevant to other entities which need to be moved to other relevant models and controllers. save_topic_dependancies and save_topic_deadlines are two methods which can be put into SignUpTopic Model or controller. show_team method which is in sign_up_sheet controller can be moved to teams_controller. We also see another controller called SignUp controller which looks like a redundant one which has methods mostly from SignUpSheet controller. And these methods don't seem to be used. So this method can be looked into carefully and discarded if possible. There is also a function called slotAvailable? in the sign up sheet controller which merely makes a call to a method slotAvailable? in the SignUpTopic model and does nothing else. This looks like an unnecesary redirection. Dependencies can be resolved and this method can be removed and calls can directly be made to the slotAvailable? method in the SignUpTopic model. Also the method update_waitlisted_users can be moved from SignUpTopic model to Wailist Model to improve the readability of the code.</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80079 2013-10-08T03:45:36Z

<p>Sayenga: /* Test-Driven Developmenthttp://www.agiledata.org/essays/tdd.html */</p> <hr /> <div>='''Agile development with Rails'''=<br /> <br /> This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> <br /> __TOC__<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''&lt;ref&gt;http://www.agiledata.org/essays/tdd.html&lt;/ref&gt;===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> '''Below is an example code for test driven development.'''<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* [http://guides.rubyonrails.org/layouts_and_rendering.html Partials] are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This [http://bundler.io/ bundler]&lt;ref&gt;http://bundler.io/&lt;/ref&gt; installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> <br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of [http://guides.rubyonrails.org/migrations.html Migration]&lt;ref&gt;http://guides.rubyonrails.org/migrations.html&lt;/ref&gt; Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as [http://coffeescript.org/ Coffeescript] can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> <br /> ===''Assets Pipeline''&lt;ref&gt;http://guides.rubyonrails.org/asset_pipeline.html&lt;/ref&gt;===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''&lt;ref&gt;http://blog.websitesframeworks.com/2013/03/web-framework-comparison-matt-raible-opinion-138/&lt;/ref&gt;==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient web framework used. GWT and GRAILS also are on par with RAILS.<br /> :* The graph depicts the five main features that any Agile Web Framework should support and these are supported by Rails thus giving both clients and developers a simple and efficient way to develop several complex web applications.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80078 2013-10-08T03:42:00Z

<p>Sayenga: /* Agile development with Rails */</p> <hr /> <div>='''Agile development with Rails'''=<br /> <br /> This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> <br /> __TOC__<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''&lt;ref&gt;http://www.agiledata.org/essays/tdd.html&lt;/ref&gt;===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* [http://guides.rubyonrails.org/layouts_and_rendering.html Partials] are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This [http://bundler.io/ bundler]&lt;ref&gt;http://bundler.io/&lt;/ref&gt; installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> <br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of [http://guides.rubyonrails.org/migrations.html Migration]&lt;ref&gt;http://guides.rubyonrails.org/migrations.html&lt;/ref&gt; Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as [http://coffeescript.org/ Coffeescript] can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> <br /> ===''Assets Pipeline''&lt;ref&gt;http://guides.rubyonrails.org/asset_pipeline.html&lt;/ref&gt;===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''&lt;ref&gt;http://blog.websitesframeworks.com/2013/03/web-framework-comparison-matt-raible-opinion-138/&lt;/ref&gt;==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient web framework used. GWT and GRAILS also are on par with RAILS.<br /> :* The graph depicts the five main features that any Agile Web Framework should support and these are supported by Rails thus giving both clients and developers a simple and efficient way to develop several complex web applications.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80075 2013-10-08T03:36:18Z

<p>Sayenga: /* Comparison of Rails with other Agile Web Frameworkshttp://blog.websitesframeworks.com/2013/03/web-framework-comparison-matt-raible-opinion-138/ */</p> <hr /> <div>== '''Agile development with Rails''' ==<br /> <br /> This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> <br /> __TOC__<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''&lt;ref&gt;http://www.agiledata.org/essays/tdd.html&lt;/ref&gt;===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* [http://guides.rubyonrails.org/layouts_and_rendering.html Partials] are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This [http://bundler.io/ bundler]&lt;ref&gt;http://bundler.io/&lt;/ref&gt; installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> <br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of [http://guides.rubyonrails.org/migrations.html Migration]&lt;ref&gt;http://guides.rubyonrails.org/migrations.html&lt;/ref&gt; Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as [http://coffeescript.org/ Coffeescript] can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> <br /> ===''Assets Pipeline''&lt;ref&gt;http://guides.rubyonrails.org/asset_pipeline.html&lt;/ref&gt;===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''&lt;ref&gt;http://blog.websitesframeworks.com/2013/03/web-framework-comparison-matt-raible-opinion-138/&lt;/ref&gt;==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient web framework used. GWT and GRAILS also are on par with RAILS.<br /> :* The graph depicts the five main features that any Agile Web Framework should support and these are supported by Rails thus giving both clients and developers a simple and efficient way to develop several complex web applications.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80074 2013-10-08T03:35:31Z

<p>Sayenga: /* Comparison of Rails with other Agile Web Frameworkshttp://blog.websitesframeworks.com/2013/03/web-framework-comparison-matt-raible-opinion-138/ */</p> <hr /> <div>== '''Agile development with Rails''' ==<br /> <br /> This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> <br /> __TOC__<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''&lt;ref&gt;http://www.agiledata.org/essays/tdd.html&lt;/ref&gt;===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* [http://guides.rubyonrails.org/layouts_and_rendering.html Partials] are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This [http://bundler.io/ bundler]&lt;ref&gt;http://bundler.io/&lt;/ref&gt; installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> <br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of [http://guides.rubyonrails.org/migrations.html Migration]&lt;ref&gt;http://guides.rubyonrails.org/migrations.html&lt;/ref&gt; Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as [http://coffeescript.org/ Coffeescript] can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> <br /> ===''Assets Pipeline''&lt;ref&gt;http://guides.rubyonrails.org/asset_pipeline.html&lt;/ref&gt;===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''&lt;ref&gt;http://blog.websitesframeworks.com/2013/03/web-framework-comparison-matt-raible-opinion-138/&lt;/ref&gt;==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient web framework used. GWT and GRAILS also are on par with RAILS.<br /> :* The graph depicts the five main things that any agile web framework should support and these are supported by rails thus giving both clients and developers a simple and efficient way to develop several complex web applications.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80068 2013-10-08T03:32:05Z

<p>Sayenga: /* Dependency Management */</p> <hr /> <div>== '''Agile development with Rails''' ==<br /> <br /> This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''&lt;ref&gt;http://www.agiledata.org/essays/tdd.html&lt;/ref&gt;===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* [http://guides.rubyonrails.org/layouts_and_rendering.html Partials] are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This [http://bundler.io/ bundler]&lt;ref&gt;http://bundler.io/&lt;/ref&gt; installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> <br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of [http://guides.rubyonrails.org/migrations.html Migration]&lt;ref&gt;http://guides.rubyonrails.org/migrations.html&lt;/ref&gt; Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as [http://coffeescript.org/ Coffeescript] can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> <br /> ===''Assets Pipeline''&lt;ref&gt;http://guides.rubyonrails.org/asset_pipeline.html&lt;/ref&gt;===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''&lt;ref&gt;http://blog.websitesframeworks.com/2013/03/web-framework-comparison-matt-raible-opinion-138/&lt;/ref&gt;==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80067 2013-10-08T03:31:24Z

<p>Sayenga: /* Dependency Management */</p> <hr /> <div>== '''Agile development with Rails''' ==<br /> <br /> This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''&lt;ref&gt;http://www.agiledata.org/essays/tdd.html&lt;/ref&gt;===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* [http://guides.rubyonrails.org/layouts_and_rendering.html Partials] are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “[http://bundler.io/ bundler]&lt;ref&gt;http://bundler.io/&lt;/ref&gt;”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> <br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of [http://guides.rubyonrails.org/migrations.html Migration]&lt;ref&gt;http://guides.rubyonrails.org/migrations.html&lt;/ref&gt; Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as [http://coffeescript.org/ Coffeescript] can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> <br /> ===''Assets Pipeline''&lt;ref&gt;http://guides.rubyonrails.org/asset_pipeline.html&lt;/ref&gt;===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''&lt;ref&gt;http://blog.websitesframeworks.com/2013/03/web-framework-comparison-matt-raible-opinion-138/&lt;/ref&gt;==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80065 2013-10-08T03:28:40Z

<p>Sayenga: /* Don’t Repeat Yourself (DRY) */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''&lt;ref&gt;http://www.agiledata.org/essays/tdd.html&lt;/ref&gt;===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* [http://guides.rubyonrails.org/layouts_and_rendering.html Partials] are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of [http://guides.rubyonrails.org/migrations.html Migration]&lt;ref&gt;http://guides.rubyonrails.org/migrations.html&lt;/ref&gt; Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as [http://coffeescript.org/ Coffeescript] can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> <br /> ===''Assets Pipeline''&lt;ref&gt;http://guides.rubyonrails.org/asset_pipeline.html&lt;/ref&gt;===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''&lt;ref&gt;http://blog.websitesframeworks.com/2013/03/web-framework-comparison-matt-raible-opinion-138/&lt;/ref&gt;==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80064 2013-10-08T03:27:52Z

<p>Sayenga: /* Comparison of Rails with other Agile Web Frameworks */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''&lt;ref&gt;http://www.agiledata.org/essays/tdd.html&lt;/ref&gt;===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of [http://guides.rubyonrails.org/migrations.html Migration]&lt;ref&gt;http://guides.rubyonrails.org/migrations.html&lt;/ref&gt; Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as [http://coffeescript.org/ Coffeescript] can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> <br /> ===''Assets Pipeline''&lt;ref&gt;http://guides.rubyonrails.org/asset_pipeline.html&lt;/ref&gt;===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''&lt;ref&gt;http://blog.websitesframeworks.com/2013/03/web-framework-comparison-matt-raible-opinion-138/&lt;/ref&gt;==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80061 2013-10-08T03:26:01Z

<p>Sayenga: /* Easy Migration */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''&lt;ref&gt;http://www.agiledata.org/essays/tdd.html&lt;/ref&gt;===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of [http://guides.rubyonrails.org/migrations.html Migration]&lt;ref&gt;http://guides.rubyonrails.org/migrations.html&lt;/ref&gt; Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as [http://coffeescript.org/ Coffeescript] can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> <br /> ===''Assets Pipeline''&lt;ref&gt;http://guides.rubyonrails.org/asset_pipeline.html&lt;/ref&gt;===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80059 2013-10-08T03:25:32Z

<p>Sayenga: /* Easy Migration */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''&lt;ref&gt;http://www.agiledata.org/essays/tdd.html&lt;/ref&gt;===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of [http://guides.rubyonrails.org/migrations.html Migration]&lt;ref&gt;http://guides.rubyonrails.org/migrations.html&lt;/ref&gt; Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as Coffeescript can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> <br /> ===''Assets Pipeline''&lt;ref&gt;http://guides.rubyonrails.org/asset_pipeline.html&lt;/ref&gt;===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80056 2013-10-08T03:24:52Z

<p>Sayenga: /* Assets Pipeline */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''&lt;ref&gt;http://www.agiledata.org/essays/tdd.html&lt;/ref&gt;===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of Migration Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as Coffeescript can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> ===''Assets Pipeline''&lt;ref&gt;http://guides.rubyonrails.org/asset_pipeline.html&lt;/ref&gt;===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80055 2013-10-08T03:24:17Z

<p>Sayenga: /* Test-Driven Development */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''&lt;ref&gt;http://www.agiledata.org/essays/tdd.html&lt;/ref&gt;===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of Migration Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as Coffeescript can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> ===''Assets Pipeline''===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80053 2013-10-08T03:23:30Z

<p>Sayenga: /* How Rails supports Agile Methodologies */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of Migration Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as Coffeescript can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> ===''Assets Pipeline''===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80052 2013-10-08T03:22:58Z

<p>Sayenga: /* Generators and Scaffolds */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''===&lt;ref&gt;http://guides.rubyonrails.org/getting_started.html&lt;/ref&gt;<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of Migration Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as Coffeescript can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> ===''Assets Pipeline''===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80050 2013-10-08T03:22:03Z

<p>Sayenga: /* Speedy and Effective Development */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript javascript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of Migration Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as Coffeescript can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> ===''Assets Pipeline''===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80049 2013-10-08T03:21:15Z

<p>Sayenga: /* Speedy and Effective Development */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, http://en.wikipedia.org/wiki/JavaScript&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of Migration Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as Coffeescript can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> ===''Assets Pipeline''===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * [http://www.yellow.com YellowPages]<br /> * [http://www.shopify.com Shopify]<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80047 2013-10-08T03:20:55Z

<p>Sayenga: /* Speedy and Effective Development */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, [http://en.wikipedia.org/wiki/JavaScript]&lt;ref&gt;http://en.wikipedia.org/wiki/JavaScript&lt;/ref&gt;, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> <br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of Migration Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as Coffeescript can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> ===''Assets Pipeline''===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * YellowPages<br /> * Shopify<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80045 2013-10-08T03:20:13Z

<p>Sayenga: /* Why Use Ruby on Rails for Agile? */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, javascript, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;=== <br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of Migration Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as Coffeescript can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> ===''Assets Pipeline''===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * [https://twitter.com Twitter]<br /> * [http://www.groupon.com Groupon]<br /> * [https://soundcloud.com SoundCloud]<br /> * [https://github.com/ GitHub]<br /> * YellowPages<br /> * Shopify<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80043 2013-10-08T03:19:26Z

<p>Sayenga: /* Why Use Ruby on Rails for Agile? */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, javascript, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''=== &lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;<br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of Migration Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as Coffeescript can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> ===''Assets Pipeline''===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * Twitter<br /> * Groupon<br /> * SoundCloud<br /> * GitHub<br /> * YellowPages<br /> * Shopify<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2013/ch1_1w39_as&diff=80042 2013-10-08T03:18:48Z

<p>Sayenga: /* Convention over Configuration */</p> <hr /> <div>This article focuses on how Rails enables ’agile development<br /> practices’ and the characteristics of Rails that support specific agile methodologies.<br /> <br /> {{TOC limit}}<br /> <br /> == '''Agile development''' ==<br /> ==='' What is Agile development? ''=== <br /> <br /> [http://en.wikipedia.org/wiki/Agile_software_development Agile development]&lt;ref&gt; http://en.wikipedia.org/wiki/Agile_software_development &lt;/ref&gt; is a methodology where requirements and solutions are developed based on [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental development] &lt;ref&gt;http://en.wikipedia.org/wiki/Iterative_and_incremental_development&lt;/ref&gt; through collaboration between self-organizing, cross-functional teams. Using agile development methodology, a high quality software can be developed by programmers in a minimal amount of time. By involving continuous planning, testing, integration, and other forms of continuous evolution of both the project and the software, it focuses on empowering people to collaborate and make decisions together quickly and effectively. Some of the process under agile development includes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle.<br /> <br /> ===''Why do we need Agile development?''===<br /> <br /> :*Visibility through active customer involvement<br /> :*Flexibility/Agility - ability to accept changes<br /> :*Quality - testing integrated throughout the lifecycle<br /> :*Speedy delivery<br /> :*Customer satisfaction - feeling of a right product<br /> <br /> [[File:agl39.jpg|center|alt=Agile development| Fig 1: Agile development]]<br /> <br /> ===''Principles of agile development'' &lt;ref&gt; http://ruby.about.com/od/rubyonrails/a/agile.htm &lt;/ref&gt; ===<br /> :*Iterative Development: Iterative development allows the clients to direct the development process in order to get the software features they want. Working software is delivered to the client at regular, short intervals. Client feedback is used to make changes to the software specifications at any stage in the development.<br /> <br /> :*Open Collaboration: Open, unrestricted communication between programmers and clients are driving force behind agile development. The programming team must work closely with the customer and also communicate freely with each other. Face to face communication is preferred over specification documents, so working in an open office with no cubicles is ideal.<br /> <br /> :*Adaptability: In agile development, changes to the software specifications are welcome even in late stages of development. Principles like Don't Repeat Yourself (DRY) are used to facilitate this. Customers gets hands-on experience with the development of the product, hence they will be able to better communicate their needs. Hence, changes in the market or company structure can be accomodated in the software at any time of the development cycle.<br /> <br /> ===''Some well known agile development methods''===<br /> <br /> Well-known agile software development methods include:<br /> :* [http://en.wikipedia.org/wiki/Specification_by_example Acceptance Test Driven Development (ATDD)]<br /> :* [http://en.wikipedia.org/wiki/Dynamic_systems_development_method Dynamic Systems Development Method (DSDM)]<br /> :* [http://en.wikipedia.org/wiki/Extreme_programming Extreme Programming (XP)]<br /> :* [http://en.wikipedia.org/wiki/Feature-driven_development Feature Driven Development (FDD)]<br /> :* [http://en.wikipedia.org/wiki/Lean_software_development Lean software development]<br /> :* [http://en.wikipedia.org/wiki/Scrum_(software_development) Scrum]<br /> :* [http://en.wikipedia.org/wiki/Story-driven_modeling Story-driven modeling]<br /> <br /> =='''Why Use Ruby on Rails for Agile?'''==<br /> ===''Speedy and Effective Development''===<br /> :* Rails provides a very fast mode to write code in a multitude of languages such as html, javascript, ruby, css, etc that are used to build a web-application by providing preconfigured environments and wire-framed models.<br /> :* Smoother pace of work, thus putting less pressure on the debugger when it comes to debugging.<br /> :* Without investing much resources, it can build business models and deliver functionalities, giving scope to customers to innovate and input faster.<br /> ===''Open Source''===<br /> :* The frequently used features and common functionalities can be implemented easily as they are available as Ruby gems.<br /> :* Provides developers the flexibility to customize and thus encouraging them to make large contributions.<br /> ===''Convention over Configuration''===&lt;ref&gt;http://en.wikipedia.org/wiki/Convention_over_configuration&lt;/ref&gt;<br /> :* By following this design paradigm, rails makes it simple for the developer as he need not specify or waste time to decide conventional aspects. <br /> :* On agreeing to implement simple and common things in a single way, it makes it easy for any new developer to work immediately on an existing project. <br /> :* This also rules out the need for explicit configuration ( except for unconventional/ customizable aspects).<br /> <br /> =='''How Rails supports Agile Methodologies'''==<br /> ===''Generators and Scaffolds''===<br /> :* The command “rails generate” uses templates to create models, controllers, views, databases, etc which helps to setup a test application.<br /> rails generate controller sample index<br /> ::The above command generates controllers sample_controller, views sample/index, assets, tests and other helpers with the route 'get' sample/index <br /> :* The scaffolding can be easily done to deploy any basic web -application, and developers can extend them to implement their functionalities. This overcomes the initial hurdle.<br /> rails generate scaffold Exam course:string score:float<br /> ::It generates all the required directories for an MVC application for a model Exam and also creates db migration CreateExams<br /> <br /> ===''Ready Setup for Multi-environment''===<br /> :* Rails application provides development, production and testing environments with built-in configurations setup and thus is a huge time saver for an application which is required to be deployed in multiple environments.<br /> :* The built-in rails web-server has the development environment as the default environment. <br /> :* Simple deployment allows developers to have face-face client meetings and thus make instantaneous changes based on the client requirements.<br /> <br /> '''Built in configuration of DB in database.yml in development environment'''<br /> development:<br /> adapter: sqlite3<br /> database: db/development.sqlite3<br /> pool: 5<br /> timeout: 5000<br /> <br /> ===''Test-Driven Development''===<br /> :* Built in mocking and stubbing frameworks are available which assists “how to write code”. This follows a red, green and refactor which is an important aspect of agile development.<br /> :* RSpec is one of the famous testing framework tools used with rails. <br /> :* Other testing tools can also be swapped in.<br /> <br /> [[File:tdd39.jpg|center|alt=Test driven development| Fig 2: TDD cycle]]<br /> <br /> Below is an example code for test driven development.<br /> <br /> describe &quot;Static pages&quot; do<br /> describe &quot;Home page&quot; do<br /> before { visit root_path }<br /> it &quot;should have the words 'Backchannel App' in it&quot; do<br /> expect(page).to have_content('Back Channel App')<br /> end<br /> end<br /> <br /> ===''Don’t Repeat Yourself (DRY)''===<br /> :* Repeated code is written in helpers and libraries, making a single destination and thus updations become simpler by updating at just one place.<br /> :* Partials are a way of rendering repeated HTML code. Rails understand a file which starts with an underscore, say, _partial.html as a partial to be included in the shared html file which renders it.<br /> '''Using partials''':<br /> :'''new.html.erb'''<br /> <br /> New Venture<br /> &lt;%= error_messages_for :venture%&gt;<br /> &lt;%= render partial: &quot;form&quot;, locals: {venture: @venture} %&gt;<br /> <br /> :'''_form.html.erb'''<br /> &lt;%= form_for(venture) do |f| %&gt; <br /> Venture name<br /> &lt;%= f.text_field :name %&gt;<br /> &lt;%= f.submit %&gt; <br /> &lt;% end %&gt;<br /> <br /> ===''Dependency Management''===<br /> :* Rails acts more than a web framework by providing the necessary utility and support tools and adding dependencies to individual projects in a jiffy using the “bundler”. <br /> :* This bundler installs all the relevant gem files and also can be updated when more dependencies are added. No need to search for packages or jars.<br /> ===''Easy Migration''===<br /> :* Rails helps you to keep easy track of database changes with the help of Migration Objects. It gives the flexibility to rollback and update.<br /> :* It also allows you to maintain various versions of database for the multi-environment. On running rake db::migrate, the desired database is migrated and deployed with the working rails server.<br /> :* New technologies such as Coffeescript can also be easily embedded by installing the relevant gems thus adapting to the changing technology.<br /> ===''Assets Pipeline''===<br /> :* The assets pipeline is a new feature embedded in rails ( which is now extracted into sprockets-rails gem), concatenates and compresses javascript and css files.<br /> :* This renders a web page with reduced number of requests from the browser as files are grouped and whitespaces are trimmed.<br /> :* Precompiled files can also be attached.<br /> <br /> =='''Comparison of Rails with other Agile Web Frameworks'''==<br /> :* This graph shows some of Rabies matrix weights to compare rails with other agile web frameworks. Among the ones compared, Rails is one of the most favourite and production efficient. GWT and GRAILS also are on par with RAILS.<br /> <br /> [[File:Stats.JPG|25 px|upright=0.85|center|frame|alt=Puzzle globe logo|center| Fig 3:Comparison of Agile Web Frameworks]]<br /> '''''Weights Explained'''''<br /> :*''Components'': Reusable components accelerate development<br /> :*''Templating'': Rating based on the number of UI templating options are available for the framework<br /> :*''Plugins and Add-ons'': Rating based on if they framework has a plugin architecture and how many plugins are available<br /> :*''Scalability'': Rating based on how much the framework relies on session state for functionality<br /> :*''REST Support'': Does the framework have the ability to produce JSON and XML instead of simply returning HTML? Can it consume JSON and XML as well?<br /> :*''Degree of Risk'': This rating is mostly for businesses. If the framework is new, there’s inherently some risk in choosing it for your applications<br /> :*''Testing'': Tools for testing allow to find errors faster<br /> <br /> =='''Future of Agile in Rails'''&lt;ref&gt; http://www.richappsconsulting.com/blog/blog-detail/agile-web-development-with-rails-an-overview/ &lt;/ref&gt;==<br /> Ruby on Rails is a framework that makes it easier to develop, deploy and maintain web applications. Soon after its initial release, Rails went from being an unfamiliar tool to being a wide-reaching phenomenon. It has become the framework of choice for the implementation of a wide range of Web 2.0 applications as it is both simple and subtle. Rails is often utilized by web developers for its suitability for short, client-driven projects. Many entrepreneurs and businesses have chosen Ruby on Rails to create their web application. Here are few well known web services that are run on Ruby on Rails:<br /> <br /> * Twitter<br /> * Groupon<br /> * SoundCloud<br /> * GitHub<br /> * YellowPages<br /> * Shopify<br /> <br /> Due to its simple nature and easy to use features as well as the speed of project completion, Rails is an ideal platform for Agile development practices. Keeping in view its accordance with the Agile Manifesto, it is not hard to predict that Rails will be the future of Agile development.<br /> <br /> =='''References'''==<br /> &lt;references/&gt;</div>

Sayenga