Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-29T03:56:39Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing class methods to instance methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Class to Instance Methods: Changing as many class methods to instance methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Class Diagram==
[[File:UML_diagram_Due_Date.png|600px|thumb|none|]]

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments had staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Class Methods to Instance Methods:====

Transforming class methods to instance methods in the DueDate class requires considering how these methods will interact with the individual state of each instance, rather than operating at the class level. This transformation ensures that methods directly utilize the properties of an individual instance of the class. Here's a structured plan for each class method identified in the provided code:

#set_flag: Currently, as a class method, this might work by accepting an identifier for a DueDate instance (such as id) to locate and update a specific record. To convert it to an instance method, remove the need for an identifier parameter, and allow the method to directly manipulate the attribute of the instance it's called on. The signature would change from set_flag(id) to just set_flag, utilizing the instance's own data.
#due_at_is_valid_datetime: This validation method might currently be designed to accept a datetime string at the class level. Converting this to an instance method involves removing the parameter and directly checking the instance's due_at attribute to see if it is a valid datetime. This aligns better with Rails conventions where validations typically operate on instance data, ensuring that each object maintains its integrity before saving or updating.
#For the <=> (spaceship operator) method, converting this from a class method to an instance method aligns with its conventional use. The spaceship operator is intended to compare two instances of the same class. As an instance method, it would naturally compare the calling instance to another instance passed as a parameter, facilitating direct and intuitive comparison of attributes like due dates within the same class.

The transformation from class methods to instance methods typically means moving from a broad, generalized operation to focusing on the specific attributes and behavior of individual instances. This change often simplifies method signatures by eliminating the need for additional parameters to identify specific instances since the method naturally operates on the instance from which it is called. For functionalities like validations or comparisons (spaceship operator), this shift enhances practicality and aligns well with object-oriented programming principles in Rails, improving code readability and maintainability.

Old Code:
<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
..
</pre>

New Code:
<pre>
def teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = self.class.current(student.assignment.due_dates)
</pre>

== Design Principles ==
====Single Responsibility Principle (SRP):====
Each method in the DueDate class was responsible for a specific task related to managing due dates.
Methods were refactored to separate concerns such as setting due dates, retrieving due dates, and performing operations on due dates.
For example, the set_duedate method focused solely on setting the due date for a task.

====Don't Repeat Yourself (DRY) Principle:====
Code duplication in the DueDate class was eliminated by extracting common functionality into helper methods or modules.
Repetitive logic, such as date calculations or formatting, was refactored to promote code reusability and maintainability.

====Encapsulation:====
Data and behavior within the DueDate class were encapsulated within appropriate instance methods and attributes to minimize dependencies.
Access to instance variables and methods was limited, promoting encapsulation and separation of concerns.

====Dependency Inversion Principle (DIP):====
The DueDate class depended on abstractions, interfaces, or higher-level modules instead of concrete implementations.
Dependency injection or inversion of control was used to decouple the class from specific date manipulation implementations, allowing for flexibility and easier testing.

== Testing ==
====Testing with Rspec:====
At our last testing iteration, we enhanced the readability, maintainability, and coverage of our DueDate model tests using RSpec. We achieved this by implementing several key strategies.

#Firstly, we organized our tests into contextual groupings using descriptive describe blocks. Each block encapsulated different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach improved the readability of our test suite by providing clear and logical groupings. Additionally, we employed helper methods within the before(:each) block to streamline setup logic. These methods handled common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we leveraged mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we mocked the required dependencies rather than relying on real database records. This approach sped up tests and isolated the behavior under test. 
#Furthermore, we paid attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we ensured the robustness of our model and handled unexpected scenarios gracefully. 
#Our test assertions were reviewed to ensure clarity and completeness. We verified that each test covered all expected outcomes and that assertions were clear and concise. For instance, in tests like copying due dates to a new assignment, we not only checked the count but also verified that due dates in the new assignment matched the originals. 
#We also focused on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we ensured that error handling scenarios were covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grew, we monitored test performance using RSpec's profiling tools and optimized slow tests as needed. Additionally, we documented our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we created a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

[[File:PR.png|600px|thumb|none|]]

==Team==
=====Mentor=====
*Kalyan Karnatı

=====Members=====
*Atharva Patil (aspatil2@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-24T03:15:21Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing class methods to instance methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Class to Instance Methods: Changing as many class methods to instance methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Class Diagram==
[[File:UML_diagram_Due_Date.png|600px|thumb|none|]]

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments had staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Class Methods to Instance Methods:====

#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

Old Code:
<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
..
</pre>

New Code:
<pre>
def teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = self.class.current(student.assignment.due_dates)
</pre>

== Design Principles ==
====Single Responsibility Principle (SRP):====
Each method in the DueDate class was responsible for a specific task related to managing due dates.
Methods were refactored to separate concerns such as setting due dates, retrieving due dates, and performing operations on due dates.
For example, the set_duedate method focused solely on setting the due date for a task.

====Don't Repeat Yourself (DRY) Principle:====
Code duplication in the DueDate class was eliminated by extracting common functionality into helper methods or modules.
Repetitive logic, such as date calculations or formatting, was refactored to promote code reusability and maintainability.

====Encapsulation:====
Data and behavior within the DueDate class were encapsulated within appropriate instance methods and attributes to minimize dependencies.
Access to instance variables and methods was limited, promoting encapsulation and separation of concerns.

====Dependency Inversion Principle (DIP):====
The DueDate class depended on abstractions, interfaces, or higher-level modules instead of concrete implementations.
Dependency injection or inversion of control was used to decouple the class from specific date manipulation implementations, allowing for flexibility and easier testing.

== Testing ==
====Testing with Rspec:====
At our last testing iteration, we enhanced the readability, maintainability, and coverage of our DueDate model tests using RSpec. We achieved this by implementing several key strategies.

#Firstly, we organized our tests into contextual groupings using descriptive describe blocks. Each block encapsulated different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach improved the readability of our test suite by providing clear and logical groupings. Additionally, we employed helper methods within the before(:each) block to streamline setup logic. These methods handled common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we leveraged mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we mocked the required dependencies rather than relying on real database records. This approach sped up tests and isolated the behavior under test. 
#Furthermore, we paid attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we ensured the robustness of our model and handled unexpected scenarios gracefully. 
#Our test assertions were reviewed to ensure clarity and completeness. We verified that each test covered all expected outcomes and that assertions were clear and concise. For instance, in tests like copying due dates to a new assignment, we not only checked the count but also verified that due dates in the new assignment matched the originals. 
#We also focused on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we ensured that error handling scenarios were covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grew, we monitored test performance using RSpec's profiling tools and optimized slow tests as needed. Additionally, we documented our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we created a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

[[File:PR.png|600px|thumb|none|]]

==Team==
=====Mentor=====
*Kalyan Karnatı

=====Members=====
*Atharva Patil (aspatil2@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-24T03:15:02Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing class methods to instance methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Class to Instance Methods: Changing as many class methods to instance methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Class Diagram==
[[File:UML_diagram_Due_Date.png|600px|thumb|none|]]

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments had staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Class Methods to Instance Methods:====

#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

Old Code:
<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
..
</pre>

New Code:
<pre>
def teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = self.class.current(student.assignment.due_dates)
</pre>

== Design Principles ==
====Single Responsibility Principle (SRP):====
Each method in the DueDate class was responsible for a specific task related to managing due dates.
Methods were refactored to separate concerns such as setting due dates, retrieving due dates, and performing operations on due dates.
For example, the set_duedate method focused solely on setting the due date for a task.

====Don't Repeat Yourself (DRY) Principle:====
Code duplication in the DueDate class was eliminated by extracting common functionality into helper methods or modules.
Repetitive logic, such as date calculations or formatting, was refactored to promote code reusability and maintainability.

====Encapsulation:====
Data and behavior within the DueDate class were encapsulated within appropriate instance methods and attributes to minimize dependencies.
Access to instance variables and methods was limited, promoting encapsulation and separation of concerns.

====Dependency Inversion Principle (DIP):====
The DueDate class depended on abstractions, interfaces, or higher-level modules instead of concrete implementations.
Dependency injection or inversion of control was used to decouple the class from specific date manipulation implementations, allowing for flexibility and easier testing.

== Testing ==
====Testing with Rspec:====
At our last testing iteration, we enhanced the readability, maintainability, and coverage of our DueDate model tests using RSpec. We achieved this by implementing several key strategies.

#Firstly, we organized our tests into contextual groupings using descriptive describe blocks. Each block encapsulated different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach improved the readability of our test suite by providing clear and logical groupings. Additionally, we employed helper methods within the before(:each) block to streamline setup logic. These methods handled common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we leveraged mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we mocked the required dependencies rather than relying on real database records. This approach sped up tests and isolated the behavior under test. 
#Furthermore, we paid attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we ensured the robustness of our model and handled unexpected scenarios gracefully. 
#Our test assertions were reviewed to ensure clarity and completeness. We verified that each test covered all expected outcomes and that assertions were clear and concise. For instance, in tests like copying due dates to a new assignment, we not only checked the count but also verified that due dates in the new assignment matched the originals. 
#We also focused on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we ensured that error handling scenarios were covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grew, we monitored test performance using RSpec's profiling tools and optimized slow tests as needed. Additionally, we documented our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we created a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

[[File:PR.png|600px|thumb|none|]]

==Team==
=====Mentor=====
*Kalyan Karnatı

=====Members=====
*Atharva Patil (aspatil2@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

File:PR.png

2024-04-24T03:14:39Z

Dukolhat:

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-21T18:12:12Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing class methods to instance methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Class to Instance Methods: Changing as many class methods to instance methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Class Diagram==
[[File:UML_diagram_Due_Date.png|600px|thumb|none|]]

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments had staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Class Methods to Instance Methods:====

#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

Old Code:
<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
..
</pre>

New Code:
<pre>
def teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = self.class.current(student.assignment.due_dates)
</pre>

== Design Principles ==
====Single Responsibility Principle (SRP):====
Each method in the DueDate class was responsible for a specific task related to managing due dates.
Methods were refactored to separate concerns such as setting due dates, retrieving due dates, and performing operations on due dates.
For example, the set_duedate method focused solely on setting the due date for a task.

====Don't Repeat Yourself (DRY) Principle:====
Code duplication in the DueDate class was eliminated by extracting common functionality into helper methods or modules.
Repetitive logic, such as date calculations or formatting, was refactored to promote code reusability and maintainability.

====Encapsulation:====
Data and behavior within the DueDate class were encapsulated within appropriate instance methods and attributes to minimize dependencies.
Access to instance variables and methods was limited, promoting encapsulation and separation of concerns.

====Dependency Inversion Principle (DIP):====
The DueDate class depended on abstractions, interfaces, or higher-level modules instead of concrete implementations.
Dependency injection or inversion of control was used to decouple the class from specific date manipulation implementations, allowing for flexibility and easier testing.

== Testing ==
====Testing with Rspec:====
At our last testing iteration, we enhanced the readability, maintainability, and coverage of our DueDate model tests using RSpec. We achieved this by implementing several key strategies.

#Firstly, we organized our tests into contextual groupings using descriptive describe blocks. Each block encapsulated different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach improved the readability of our test suite by providing clear and logical groupings. Additionally, we employed helper methods within the before(:each) block to streamline setup logic. These methods handled common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we leveraged mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we mocked the required dependencies rather than relying on real database records. This approach sped up tests and isolated the behavior under test. 
#Furthermore, we paid attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we ensured the robustness of our model and handled unexpected scenarios gracefully. 
#Our test assertions were reviewed to ensure clarity and completeness. We verified that each test covered all expected outcomes and that assertions were clear and concise. For instance, in tests like copying due dates to a new assignment, we not only checked the count but also verified that due dates in the new assignment matched the originals. 
#We also focused on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we ensured that error handling scenarios were covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grew, we monitored test performance using RSpec's profiling tools and optimized slow tests as needed. Additionally, we documented our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we created a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

==Team==
=====Mentor=====
*Kalyan Karnatı

=====Members=====
*Atharva Patil (aspatil2@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-21T18:11:54Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing class methods to instance methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Class to Instance Methods: Changing as many class methods to instance methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Class Diagram==
[[File:UML_diagram_Due_Date.png|1000px|thumb|none|]]

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments had staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Class Methods to Instance Methods:====

#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

Old Code:
<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
..
</pre>

New Code:
<pre>
def teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = self.class.current(student.assignment.due_dates)
</pre>

== Design Principles ==
====Single Responsibility Principle (SRP):====
Each method in the DueDate class was responsible for a specific task related to managing due dates.
Methods were refactored to separate concerns such as setting due dates, retrieving due dates, and performing operations on due dates.
For example, the set_duedate method focused solely on setting the due date for a task.

====Don't Repeat Yourself (DRY) Principle:====
Code duplication in the DueDate class was eliminated by extracting common functionality into helper methods or modules.
Repetitive logic, such as date calculations or formatting, was refactored to promote code reusability and maintainability.

====Encapsulation:====
Data and behavior within the DueDate class were encapsulated within appropriate instance methods and attributes to minimize dependencies.
Access to instance variables and methods was limited, promoting encapsulation and separation of concerns.

====Dependency Inversion Principle (DIP):====
The DueDate class depended on abstractions, interfaces, or higher-level modules instead of concrete implementations.
Dependency injection or inversion of control was used to decouple the class from specific date manipulation implementations, allowing for flexibility and easier testing.

== Testing ==
====Testing with Rspec:====
At our last testing iteration, we enhanced the readability, maintainability, and coverage of our DueDate model tests using RSpec. We achieved this by implementing several key strategies.

#Firstly, we organized our tests into contextual groupings using descriptive describe blocks. Each block encapsulated different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach improved the readability of our test suite by providing clear and logical groupings. Additionally, we employed helper methods within the before(:each) block to streamline setup logic. These methods handled common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we leveraged mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we mocked the required dependencies rather than relying on real database records. This approach sped up tests and isolated the behavior under test. 
#Furthermore, we paid attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we ensured the robustness of our model and handled unexpected scenarios gracefully. 
#Our test assertions were reviewed to ensure clarity and completeness. We verified that each test covered all expected outcomes and that assertions were clear and concise. For instance, in tests like copying due dates to a new assignment, we not only checked the count but also verified that due dates in the new assignment matched the originals. 
#We also focused on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we ensured that error handling scenarios were covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grew, we monitored test performance using RSpec's profiling tools and optimized slow tests as needed. Additionally, we documented our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we created a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

==Team==
=====Mentor=====
*Kalyan Karnatı

=====Members=====
*Atharva Patil (aspatil2@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

File:UML diagram Due Date.png

2024-04-21T18:11:04Z

Dukolhat:

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-19T21:30:32Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing class methods to instance methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Class to Instance Methods: Changing as many class methods to instance methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments had staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Class Methods to Instance Methods:====

#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

Old Code:
<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
..
</pre>

New Code:
<pre>
def teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = self.class.current(student.assignment.due_dates)
</pre>

== Design Principles ==
====Single Responsibility Principle (SRP):====
Each method in the DueDate class was responsible for a specific task related to managing due dates.
Methods were refactored to separate concerns such as setting due dates, retrieving due dates, and performing operations on due dates.
For example, the set_duedate method focused solely on setting the due date for a task.

====Don't Repeat Yourself (DRY) Principle:====
Code duplication in the DueDate class was eliminated by extracting common functionality into helper methods or modules.
Repetitive logic, such as date calculations or formatting, was refactored to promote code reusability and maintainability.

====Encapsulation:====
Data and behavior within the DueDate class were encapsulated within appropriate instance methods and attributes to minimize dependencies.
Access to instance variables and methods was limited, promoting encapsulation and separation of concerns.

====Dependency Inversion Principle (DIP):====
The DueDate class depended on abstractions, interfaces, or higher-level modules instead of concrete implementations.
Dependency injection or inversion of control was used to decouple the class from specific date manipulation implementations, allowing for flexibility and easier testing.

== Testing ==
====Testing with Rspec:====
At our last testing iteration, we enhanced the readability, maintainability, and coverage of our DueDate model tests using RSpec. We achieved this by implementing several key strategies.

#Firstly, we organized our tests into contextual groupings using descriptive describe blocks. Each block encapsulated different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach improved the readability of our test suite by providing clear and logical groupings. Additionally, we employed helper methods within the before(:each) block to streamline setup logic. These methods handled common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we leveraged mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we mocked the required dependencies rather than relying on real database records. This approach sped up tests and isolated the behavior under test. 
#Furthermore, we paid attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we ensured the robustness of our model and handled unexpected scenarios gracefully. 
#Our test assertions were reviewed to ensure clarity and completeness. We verified that each test covered all expected outcomes and that assertions were clear and concise. For instance, in tests like copying due dates to a new assignment, we not only checked the count but also verified that due dates in the new assignment matched the originals. 
#We also focused on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we ensured that error handling scenarios were covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grew, we monitored test performance using RSpec's profiling tools and optimized slow tests as needed. Additionally, we documented our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we created a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

==Team==
=====Mentor=====
*Kalyan Karnatı

=====Members=====
*Atharva Patil (aspatil2@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-19T21:30:03Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing class methods to instance methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Class to Instance Methods: Changing as many class methods to instance methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments had staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Class Methods to Instance Methods:====

#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

OLD CODE:
<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
..
</pre>

NEW CODE:
<pre>
def teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = self.class.current(student.assignment.due_dates)
</pre>

== Design Principles ==
====Single Responsibility Principle (SRP):====
Each method in the DueDate class was responsible for a specific task related to managing due dates.
Methods were refactored to separate concerns such as setting due dates, retrieving due dates, and performing operations on due dates.
For example, the set_duedate method focused solely on setting the due date for a task.

====Don't Repeat Yourself (DRY) Principle:====
Code duplication in the DueDate class was eliminated by extracting common functionality into helper methods or modules.
Repetitive logic, such as date calculations or formatting, was refactored to promote code reusability and maintainability.

====Encapsulation:====
Data and behavior within the DueDate class were encapsulated within appropriate instance methods and attributes to minimize dependencies.
Access to instance variables and methods was limited, promoting encapsulation and separation of concerns.

====Dependency Inversion Principle (DIP):====
The DueDate class depended on abstractions, interfaces, or higher-level modules instead of concrete implementations.
Dependency injection or inversion of control was used to decouple the class from specific date manipulation implementations, allowing for flexibility and easier testing.

== Testing ==
====Testing with Rspec:====
At our last testing iteration, we enhanced the readability, maintainability, and coverage of our DueDate model tests using RSpec. We achieved this by implementing several key strategies.

#Firstly, we organized our tests into contextual groupings using descriptive describe blocks. Each block encapsulated different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach improved the readability of our test suite by providing clear and logical groupings. Additionally, we employed helper methods within the before(:each) block to streamline setup logic. These methods handled common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we leveraged mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we mocked the required dependencies rather than relying on real database records. This approach sped up tests and isolated the behavior under test. 
#Furthermore, we paid attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we ensured the robustness of our model and handled unexpected scenarios gracefully. 
#Our test assertions were reviewed to ensure clarity and completeness. We verified that each test covered all expected outcomes and that assertions were clear and concise. For instance, in tests like copying due dates to a new assignment, we not only checked the count but also verified that due dates in the new assignment matched the originals. 
#We also focused on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we ensured that error handling scenarios were covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grew, we monitored test performance using RSpec's profiling tools and optimized slow tests as needed. Additionally, we documented our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we created a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

==Team==
=====Mentor=====
*Kalyan Karnatı

=====Members=====
*Atharva Patil (aspatil2@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-19T21:28:49Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing class methods to instance methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Class to Instance Methods: Changing as many class methods to instance methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments had staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Class Methods to Instance Methods:====

#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

== Design Principles ==
====Single Responsibility Principle (SRP):====
Each method in the DueDate class was responsible for a specific task related to managing due dates.
Methods were refactored to separate concerns such as setting due dates, retrieving due dates, and performing operations on due dates.
For example, the set_duedate method focused solely on setting the due date for a task.

====Don't Repeat Yourself (DRY) Principle:====
Code duplication in the DueDate class was eliminated by extracting common functionality into helper methods or modules.
Repetitive logic, such as date calculations or formatting, was refactored to promote code reusability and maintainability.

====Encapsulation:====
Data and behavior within the DueDate class were encapsulated within appropriate instance methods and attributes to minimize dependencies.
Access to instance variables and methods was limited, promoting encapsulation and separation of concerns.

====Dependency Inversion Principle (DIP):====
The DueDate class depended on abstractions, interfaces, or higher-level modules instead of concrete implementations.
Dependency injection or inversion of control was used to decouple the class from specific date manipulation implementations, allowing for flexibility and easier testing.

== Testing ==
====Testing with Rspec:====
At our last testing iteration, we enhanced the readability, maintainability, and coverage of our DueDate model tests using RSpec. We achieved this by implementing several key strategies.

#Firstly, we organized our tests into contextual groupings using descriptive describe blocks. Each block encapsulated different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach improved the readability of our test suite by providing clear and logical groupings. Additionally, we employed helper methods within the before(:each) block to streamline setup logic. These methods handled common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we leveraged mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we mocked the required dependencies rather than relying on real database records. This approach sped up tests and isolated the behavior under test. 
#Furthermore, we paid attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we ensured the robustness of our model and handled unexpected scenarios gracefully. 
#Our test assertions were reviewed to ensure clarity and completeness. We verified that each test covered all expected outcomes and that assertions were clear and concise. For instance, in tests like copying due dates to a new assignment, we not only checked the count but also verified that due dates in the new assignment matched the originals. 
#We also focused on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we ensured that error handling scenarios were covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grew, we monitored test performance using RSpec's profiling tools and optimized slow tests as needed. Additionally, we documented our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we created a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

==Team==
=====Mentor=====
*Kalyan Karnatı

=====Members=====
*Atharva Patil (aspatil2@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-19T19:54:54Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing class methods to instance methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Class to Instance Methods: Changing as many class methods to instance methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments had staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Class Methods to Instance Methods:====

#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

== Design Principles ==
====Single Responsibility Principle (SRP):====
Each method in the DueDate class will be responsible for a specific task related to managing due dates.
Methods will be refactored to separate concerns such as setting due dates, retrieving due dates, and performing operations on due dates.
For example, the set_duedate method will focus solely on setting the due date for a task.

====Don't Repeat Yourself (DRY) Principle:====
Code duplication in the DueDate class will be eliminated by extracting common functionality into helper methods or modules.
Repetitive logic, such as date calculations or formatting, will be refactored to promote code reusability and maintainability.

====Encapsulation:====
Data and behavior within the DueDate class will be encapsulated within appropriate instance methods and attributes to minimize dependencies.
Access to instance variables and methods will be limited, promoting encapsulation and separation of concerns.

====Dependency Inversion Principle (DIP):====
The DueDate class will depend on abstractions, interfaces, or higher-level modules instead of concrete implementations.
Dependency injection or inversion of control will be used to decouple the class from specific date manipulation implementations, allowing for flexibility and easier testing.

== Testing ==
====Testing with Rspec:====
At our next testing iteration, we plan to enhance the readability, maintainability, and coverage of our DueDate model tests using RSpec. We aim to achieve this by implementing several key strategies.

#Firstly, we'll organize our tests into contextual groupings using descriptive describe blocks. Each block will encapsulate different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach will improve the readability of our test suite by providing clear and logical groupings. Additionally, we'll employ helper methods within the before(:each) block to streamline setup logic. These methods will handle common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we'll leverage mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we'll mock the required dependencies rather than relying on real database records. This approach speeds up tests and isolates the behavior under test. 
#Furthermore, we'll pay attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we'll ensure the robustness of our model and handle unexpected scenarios gracefully. 
#Our test assertions will be reviewed to ensure clarity and completeness. We'll verify that each test covers all expected outcomes and that assertions are clear and concise. For instance, in tests like copying due dates to a new assignment, we'll not only check the count but also verify that due dates in the new assignment match the originals. 
#We'll also focus on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we'll ensure that error handling scenarios are covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grows, we'll monitor test performance using RSpec's profiling tools and optimize slow tests as needed. Additionally, we'll document our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we aim to create a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

==Team==
=====Mentor=====
*Kalyan Karnatı

=====Members=====
*Atharva Patil (aspatil2@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-19T15:08:47Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing class methods to instance methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Class to Instance Methods: Changing as many class methods to instance methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative will encompass specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we'll embark on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we'll include comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we'll focus on enhancing variable and method names. In the done_in_assignment_round method, we'll rename variables like due_dates to assignment_due_dates for clarity. Additionally, we'll rename the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions will be another key aspect. For example, in the done_in_assignment_round method, we'll extract the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts will involve reviewing database queries for efficiency. In the get_next_due_date method, we'll optimize the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements will include refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we'll provide more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices will be ensured throughout the refactoring process. We'll leverage Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we'll utilize ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we'll implement thorough unit tests using frameworks like RSpec or Minitest. For instance, we'll write tests to verify the behavior of the set_flag method and ensure it correctly updates the flag attribute. 
#Lastly, we'll document our progress and collaborate effectively using version control systems like Git. Code reviews will provide valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase.By undertaking these specific actions, we aim to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Class Methods to Instance Methods:====

#Our refactoring initiative encompassed specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we embarked on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we included comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we focused on enhancing variable and method names. In the done_in_assignment_round method, we renamed variables like due_dates to assignment_due_dates for clarity. Additionally, we renamed the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions was another key aspect. For example, in the done_in_assignment_round method, we extracted the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts involved reviewing database queries for efficiency. In the get_next_due_date method, we optimized the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements included refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we provided more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices was ensured throughout the refactoring process. We leveraged Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we utilized ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we implemented thorough unit tests using frameworks like RSpec or Minitest. For instance, we wrote tests to verify the behavior of the set_flag method and ensured it correctly updated the flag attribute. 
#Lastly, we documented our progress and collaborated effectively using version control systems like Git. Code reviews provided valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase. By undertaking these specific actions, we aimed to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

== Design Principles ==
====Single Responsibility Principle (SRP):====
Each method in the DueDate class will be responsible for a specific task related to managing due dates.
Methods will be refactored to separate concerns such as setting due dates, retrieving due dates, and performing operations on due dates.
For example, the set_duedate method will focus solely on setting the due date for a task.

====Don't Repeat Yourself (DRY) Principle:====
Code duplication in the DueDate class will be eliminated by extracting common functionality into helper methods or modules.
Repetitive logic, such as date calculations or formatting, will be refactored to promote code reusability and maintainability.

====Encapsulation:====
Data and behavior within the DueDate class will be encapsulated within appropriate instance methods and attributes to minimize dependencies.
Access to instance variables and methods will be limited, promoting encapsulation and separation of concerns.

====Dependency Inversion Principle (DIP):====
The DueDate class will depend on abstractions, interfaces, or higher-level modules instead of concrete implementations.
Dependency injection or inversion of control will be used to decouple the class from specific date manipulation implementations, allowing for flexibility and easier testing.

== Testing ==
====Testing with Rspec:====
At our next testing iteration, we plan to enhance the readability, maintainability, and coverage of our DueDate model tests using RSpec. We aim to achieve this by implementing several key strategies.

#Firstly, we'll organize our tests into contextual groupings using descriptive describe blocks. Each block will encapsulate different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach will improve the readability of our test suite by providing clear and logical groupings. Additionally, we'll employ helper methods within the before(:each) block to streamline setup logic. These methods will handle common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we'll leverage mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we'll mock the required dependencies rather than relying on real database records. This approach speeds up tests and isolates the behavior under test. 
#Furthermore, we'll pay attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we'll ensure the robustness of our model and handle unexpected scenarios gracefully. 
#Our test assertions will be reviewed to ensure clarity and completeness. We'll verify that each test covers all expected outcomes and that assertions are clear and concise. For instance, in tests like copying due dates to a new assignment, we'll not only check the count but also verify that due dates in the new assignment match the originals. 
#We'll also focus on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we'll ensure that error handling scenarios are covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grows, we'll monitor test performance using RSpec's profiling tools and optimize slow tests as needed. Additionally, we'll document our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we aim to create a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

==Team==
=====Mentor=====
*Kalyan Karnatı

=====Members=====
*Atharva Patil (aspatil2@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024

2024-04-19T00:54:18Z

Dukolhat:

* [[CSC/ECE 517 Spring 2024 - E2401 Implementing and testing import & export controllers]]
* [[CSC/ECE 517 Spring 2024 - E2405 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2407 Refactor review_mapping_controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2428 Replicate Roles and Institution UIs ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2429 Reimplement student_task list]]
* [[CSC/ECE 517 Spring 2024 - E2430 Reimplement student_task view]]
* [[CSC/ECE 517 Spring 2024 - E2410. View for Results of Bidding ]]
* [[CSC/ECE 517 Spring 2024 - E2414 Grading Audit Trail]]
* [[CSC/ECE 517 Spring 2024 - NTNX-1 : Extend NDB Operator to Support Postgres HA]]
* [[CSC/ECE 517 Spring 2024 - ‬NTNX-2‬‭ : Snapshot Functionality for provisioned databases]]
* [[CSC/ECE 517 Spring 2024 - E2411 : Fix "Back" link on “New Late Policy” page]]
* [[CSC/ECE 517 Spring 2024 - E2416. Reimplement the Question hierarchy]]
* [[CSC/ECE 517 Spring 2024 - E2420. Reimplement student_quizzes_controller]]
* [[CSC/ECE 517 Spring 2024 - E2424. Reimplement the Bookmarks Controller]]
* [[CSC/ECE 517 Spring 2024 - E2426. Create a UI for Assignment Edit page "Etc" tab in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2417. Reimplement submitted content controller.rb (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2425. Create a Courses user interface in ReactJS]]
* [[CSC/ECE 517 Spring 2024 - E2431. Reimplement grades/view_team]]
* [[CSC/ECE 517 Spring 2024 - E2404 Refactor student teams functionality]]
* [[CSC/ECE 517 Spring 2024 - E2406 Refactor review_mapping_helper.rb]]
* [[CSC/ECE 517 Spring 2024 - E2403 Mentor-Meeting Management]]
* [[CSC/ECE 517 Spring 2024 - E2421. Reimplement impersonating users (within impersonate controller.rb)]]
* [[CSC/ECE 517 Spring 2024 - E2413. Testing - Answer Tagging]]
* [[CSC/ECE 517 Spring 2024 - E2412. Testing for hamer.rb]]
* [[CSC/ECE 517 Spring 2024 - E2427. UI for questionnaire.rb]]
* [[CSC/ECE 517 Spring 2024 - E2419. Reimplement duties controller.rb and badges controller.rb]]
* [[CSC/ECE 517 Spring 2024 - E2432. UI for Participants.rb]]
* [[CSC/ECE 517 Spring 2024 - G2402 Implement REST client, REST API, and Graphql API endpoint for repositories]]
* [[CSC/ECE 517 Spring 2024 - G2400 DevOp for GitHub Miner app]]
* [[CSC/ECE 517 Spring 2024 - E2439 Testing for view_translation_substitutor.rb]]
* [[CSC/ECE 517 Spring 2024 - E2443 Reimplement grades_controller]]
* [[CSC/ECE 517 Spring 2024 - E2434 Reimplement Frontend for the Grades view]]
* [[CSC/ECE 517 Spring 2024 - E2435 Implement Frontend for the My Profile]]
* [[CSC/ECE 517 Spring 2024 - E2446 Implement Front End for Student Task List]]
* [[CSC/ECE 517 Spring 2024 - E2444 Implement Frontend for the Review]]
* [[CSC/ECE 517 Spring 2024 - E2440 Testing for questionnaire_helper, review_bids_helper]]
* [[CSC/ECE 517 Spring 2024 - E2433 Implement UI for the Student Teams]]
* [[CSC/ECE 517 Spring 2024 - E2415. Reimplement responses controller.rb (Design Document)]]
* [[CSC/ECE 517 Spring 2024 - E2445. Implement BackEnd for participants.rb (Design Document)]]
* [[CSC/ECE 517 Spring 2024 - E2441 Reimplement grades/view_team (Phase 2)]]
* [[CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)]]

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-19T00:51:22Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing class methods to instance methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Class to Instance Methods: Changing as many class methods to instance methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative will encompass specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we'll embark on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we'll include comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we'll focus on enhancing variable and method names. In the done_in_assignment_round method, we'll rename variables like due_dates to assignment_due_dates for clarity. Additionally, we'll rename the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions will be another key aspect. For example, in the done_in_assignment_round method, we'll extract the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts will involve reviewing database queries for efficiency. In the get_next_due_date method, we'll optimize the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements will include refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we'll provide more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices will be ensured throughout the refactoring process. We'll leverage Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we'll utilize ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we'll implement thorough unit tests using frameworks like RSpec or Minitest. For instance, we'll write tests to verify the behavior of the set_flag method and ensure it correctly updates the flag attribute. 
#Lastly, we'll document our progress and collaborate effectively using version control systems like Git. Code reviews will provide valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase.By undertaking these specific actions, we aim to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Class Methods to Instance Methods:====

Transforming class methods to instance methods in the DueDate class requires considering how these methods will interact with the individual state of each instance, rather than operating at the class level. This transformation ensures that methods directly utilize the properties of an individual instance of the class. Here's a structured plan for each class method identified in the provided code:

#set_flag: Currently, as a class method, this might work by accepting an identifier for a DueDate instance (such as id) to locate and update a specific record. To convert it to an instance method, remove the need for an identifier parameter, and allow the method to directly manipulate the attribute of the instance it's called on. The signature would change from set_flag(id) to just set_flag, utilizing the instance's own data.
#due_at_is_valid_datetime: This validation method might currently be designed to accept a datetime string at the class level. Converting this to an instance method involves removing the parameter and directly checking the instance's due_at attribute to see if it is a valid datetime. This aligns better with Rails conventions where validations typically operate on instance data, ensuring that each object maintains its integrity before saving or updating.
#For the <=> (spaceship operator) method, converting this from a class method to an instance method aligns with its conventional use. The spaceship operator is intended to compare two instances of the same class. As an instance method, it would naturally compare the calling instance to another instance passed as a parameter, facilitating direct and intuitive comparison of attributes like due dates within the same class.

The transformation from class methods to instance methods typically means moving from a broad, generalized operation to focusing on the specific attributes and behavior of individual instances. This change often simplifies method signatures by eliminating the need for additional parameters to identify specific instances since the method naturally operates on the instance from which it is called. For functionalities like validations or comparisons (spaceship operator), this shift enhances practicality and aligns well with object-oriented programming principles in Rails, improving code readability and maintainability.

== Design Principles ==
====Single Responsibility Principle (SRP):====
Each method in the DueDate class will be responsible for a specific task related to managing due dates.
Methods will be refactored to separate concerns such as setting due dates, retrieving due dates, and performing operations on due dates.
For example, the set_duedate method will focus solely on setting the due date for a task.

====Don't Repeat Yourself (DRY) Principle:====
Code duplication in the DueDate class will be eliminated by extracting common functionality into helper methods or modules.
Repetitive logic, such as date calculations or formatting, will be refactored to promote code reusability and maintainability.

====Encapsulation:====
Data and behavior within the DueDate class will be encapsulated within appropriate instance methods and attributes to minimize dependencies.
Access to instance variables and methods will be limited, promoting encapsulation and separation of concerns.

====Dependency Inversion Principle (DIP):====
The DueDate class will depend on abstractions, interfaces, or higher-level modules instead of concrete implementations.
Dependency injection or inversion of control will be used to decouple the class from specific date manipulation implementations, allowing for flexibility and easier testing.

== Testing ==
====Testing with Rspec:====
At our next testing iteration, we plan to enhance the readability, maintainability, and coverage of our DueDate model tests using RSpec. We aim to achieve this by implementing several key strategies.

#Firstly, we'll organize our tests into contextual groupings using descriptive describe blocks. Each block will encapsulate different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach will improve the readability of our test suite by providing clear and logical groupings. Additionally, we'll employ helper methods within the before(:each) block to streamline setup logic. These methods will handle common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we'll leverage mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we'll mock the required dependencies rather than relying on real database records. This approach speeds up tests and isolates the behavior under test. 
#Furthermore, we'll pay attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we'll ensure the robustness of our model and handle unexpected scenarios gracefully. 
#Our test assertions will be reviewed to ensure clarity and completeness. We'll verify that each test covers all expected outcomes and that assertions are clear and concise. For instance, in tests like copying due dates to a new assignment, we'll not only check the count but also verify that due dates in the new assignment match the originals. 
#We'll also focus on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we'll ensure that error handling scenarios are covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grows, we'll monitor test performance using RSpec's profiling tools and optimize slow tests as needed. Additionally, we'll document our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we aim to create a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

==Team==
=====Mentor=====
*Kalyan Karnatı

=====Members=====
*Atharva Patil (aspatil2@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-09T00:15:34Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing instance methods to class methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Instance to Class Methods: Changing as many instance methods to class methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative will encompass specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we'll embark on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we'll include comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we'll focus on enhancing variable and method names. In the done_in_assignment_round method, we'll rename variables like due_dates to assignment_due_dates for clarity. Additionally, we'll rename the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions will be another key aspect. For example, in the done_in_assignment_round method, we'll extract the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts will involve reviewing database queries for efficiency. In the get_next_due_date method, we'll optimize the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements will include refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we'll provide more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices will be ensured throughout the refactoring process. We'll leverage Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we'll utilize ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we'll implement thorough unit tests using frameworks like RSpec or Minitest. For instance, we'll write tests to verify the behavior of the set_flag method and ensure it correctly updates the flag attribute. 
#Lastly, we'll document our progress and collaborate effectively using version control systems like Git. Code reviews will provide valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase.By undertaking these specific actions, we aim to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Instance Methods to Class Methods:====

Transforming instance methods to class methods in the DueDate class requires a strategic approach, taking into account the context and usage of these methods within the broader application. This transformation ensures that methods don't rely on the state of a particular instance of the class but rather, operate at the class level, possibly requiring additional parameters to act upon data that would have been inherent to the instance. Here's a structured plan for each instance method identified in the provided code:

#set_flag: Currently, this method updates an attribute of a specific instance. To convert it into a class method, it would need to accept an identifier for the DueDate instance (such as id) as a parameter. The class method would then locate the specific instance within the database and update its attribute. The signature would change from set_flag to something like self.set_flag(id), where id is used to find the DueDate instance and update it.
#due_at_is_valid_datetime: This validation method checks if the due_at attribute of an instance is a valid datetime. To change this into a class method, it would need to accept a datetime string as a parameter. However, validations in Rails models are inherently designed to be instance methods since they operate on the attributes of a specific instance before saving or updating it. Instead of transforming this into a class method, consider whether it's more appropriate to keep as an instance method or refactor the validation logic elsewhere where it can be used more generically.
#For the <=> (spaceship operator) method, transforming it into a class method doesn't follow the conventional use of class methods or the purpose of the spaceship operator. The spaceship operator is used to compare two instances of the same class. Its use as a class method would be unconventional and counterintuitive since it's designed to operate on instances. If there's a compelling reason to compare data at the class level, consider implementing a separate class method that takes identifiers or attributes of two entities as parameters to perform the comparison, but this would be a deviation from the typical use of the <=> operator.

The transformation from instance methods to class methods often means changing the scope from operating on a single, specific instance to handling a broader class-level operation. This usually involves adding parameters to methods that were previously not needed because the instance itself held the context. Moreover, for some functionalities like validations or comparisons (<=> operator), the shift might not be practical or align with Rails conventions and object-oriented principles. It's crucial to assess the necessity and implications of such changes on the overall design and maintainability of the codebase.

====Testing with Rspec:====
At our next testing iteration, we plan to enhance the readability, maintainability, and coverage of our DueDate model tests using RSpec. We aim to achieve this by implementing several key strategies.

#Firstly, we'll organize our tests into contextual groupings using descriptive describe blocks. Each block will encapsulate different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach will improve the readability of our test suite by providing clear and logical groupings. Additionally, we'll employ helper methods within the before(:each) block to streamline setup logic. These methods will handle common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we'll leverage mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we'll mock the required dependencies rather than relying on real database records. This approach speeds up tests and isolates the behavior under test. 
#Furthermore, we'll pay attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we'll ensure the robustness of our model and handle unexpected scenarios gracefully. 
#Our test assertions will be reviewed to ensure clarity and completeness. We'll verify that each test covers all expected outcomes and that assertions are clear and concise. For instance, in tests like copying due dates to a new assignment, we'll not only check the count but also verify that due dates in the new assignment match the originals. 
#We'll also focus on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we'll ensure that error handling scenarios are covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grows, we'll monitor test performance using RSpec's profiling tools and optimize slow tests as needed. Additionally, we'll document our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we aim to create a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

== Design Principles ==

== Testing ==

==Team==
=====Mentor=====
*Kalyan Karnatı

=====Members=====
*Atharva Patil (apatil@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-09T00:14:49Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing instance methods to class methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Instance to Class Methods: Changing as many instance methods to class methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative will encompass specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we'll embark on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we'll include comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we'll focus on enhancing variable and method names. In the done_in_assignment_round method, we'll rename variables like due_dates to assignment_due_dates for clarity. Additionally, we'll rename the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions will be another key aspect. For example, in the done_in_assignment_round method, we'll extract the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts will involve reviewing database queries for efficiency. In the get_next_due_date method, we'll optimize the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements will include refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we'll provide more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices will be ensured throughout the refactoring process. We'll leverage Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we'll utilize ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we'll implement thorough unit tests using frameworks like RSpec or Minitest. For instance, we'll write tests to verify the behavior of the set_flag method and ensure it correctly updates the flag attribute. 
#Lastly, we'll document our progress and collaborate effectively using version control systems like Git. Code reviews will provide valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase.By undertaking these specific actions, we aim to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Instance Methods to Class Methods:====

Transforming instance methods to class methods in the DueDate class requires a strategic approach, taking into account the context and usage of these methods within the broader application. This transformation ensures that methods don't rely on the state of a particular instance of the class but rather, operate at the class level, possibly requiring additional parameters to act upon data that would have been inherent to the instance. Here's a structured plan for each instance method identified in the provided code:

#set_flag: Currently, this method updates an attribute of a specific instance. To convert it into a class method, it would need to accept an identifier for the DueDate instance (such as id) as a parameter. The class method would then locate the specific instance within the database and update its attribute. The signature would change from set_flag to something like self.set_flag(id), where id is used to find the DueDate instance and update it.
#due_at_is_valid_datetime: This validation method checks if the due_at attribute of an instance is a valid datetime. To change this into a class method, it would need to accept a datetime string as a parameter. However, validations in Rails models are inherently designed to be instance methods since they operate on the attributes of a specific instance before saving or updating it. Instead of transforming this into a class method, consider whether it's more appropriate to keep as an instance method or refactor the validation logic elsewhere where it can be used more generically.
#For the <=> (spaceship operator) method, transforming it into a class method doesn't follow the conventional use of class methods or the purpose of the spaceship operator. The spaceship operator is used to compare two instances of the same class. Its use as a class method would be unconventional and counterintuitive since it's designed to operate on instances. If there's a compelling reason to compare data at the class level, consider implementing a separate class method that takes identifiers or attributes of two entities as parameters to perform the comparison, but this would be a deviation from the typical use of the <=> operator.

The transformation from instance methods to class methods often means changing the scope from operating on a single, specific instance to handling a broader class-level operation. This usually involves adding parameters to methods that were previously not needed because the instance itself held the context. Moreover, for some functionalities like validations or comparisons (<=> operator), the shift might not be practical or align with Rails conventions and object-oriented principles. It's crucial to assess the necessity and implications of such changes on the overall design and maintainability of the codebase.

====Testing with Rspec:====
At our next testing iteration, we plan to enhance the readability, maintainability, and coverage of our DueDate model tests using RSpec. We aim to achieve this by implementing several key strategies.

#Firstly, we'll organize our tests into contextual groupings using descriptive describe blocks. Each block will encapsulate different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach will improve the readability of our test suite by providing clear and logical groupings. Additionally, we'll employ helper methods within the before(:each) block to streamline setup logic. These methods will handle common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we'll leverage mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we'll mock the required dependencies rather than relying on real database records. This approach speeds up tests and isolates the behavior under test. 
#Furthermore, we'll pay attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we'll ensure the robustness of our model and handle unexpected scenarios gracefully. 
#Our test assertions will be reviewed to ensure clarity and completeness. We'll verify that each test covers all expected outcomes and that assertions are clear and concise. For instance, in tests like copying due dates to a new assignment, we'll not only check the count but also verify that due dates in the new assignment match the originals. 
#We'll also focus on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we'll ensure that error handling scenarios are covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grows, we'll monitor test performance using RSpec's profiling tools and optimize slow tests as needed. Additionally, we'll document our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we aim to create a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

== Design Principles ==

== Testing ==

==Team==
=====Mentor=====
*Kalyan Kainatı

=====Members=====
*Atharva Patil (apatil@ncsu.edu)
*Deepika Choudhary Patibandla (@ncsu.edu)
*Dhruv Kolhatkar (dukolhat@ncsu.edu)

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-09T00:13:26Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing instance methods to class methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Instance to Class Methods: Changing as many instance methods to class methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
#Our refactoring initiative will encompass specific actions to improve code clarity, optimize performance, and bolster maintainability across our application. 
#Firstly, we'll embark on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we'll include comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior. 
#Secondly, we'll focus on enhancing variable and method names. In the done_in_assignment_round method, we'll rename variables like due_dates to assignment_due_dates for clarity. Additionally, we'll rename the copy method to duplicate_due_dates to better convey its functionality. Breaking down complex methods into smaller, focused functions will be another key aspect. For example, in the done_in_assignment_round method, we'll extract the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability. 
#Optimization efforts will involve reviewing database queries for efficiency. In the get_next_due_date method, we'll optimize the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics. 
#Robustness enhancements will include refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we'll provide more informative error messages to guide developers in identifying and resolving invalid datetime inputs. 
#Adherence to Ruby and Rails best practices will be ensured throughout the refactoring process. We'll leverage Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we'll utilize ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety. 
#To mitigate against regressions, we'll implement thorough unit tests using frameworks like RSpec or Minitest. For instance, we'll write tests to verify the behavior of the set_flag method and ensure it correctly updates the flag attribute. 
#Lastly, we'll document our progress and collaborate effectively using version control systems like Git. Code reviews will provide valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase.By undertaking these specific actions, we aim to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Instance Methods to Class Methods:====

Transforming instance methods to class methods in the DueDate class requires a strategic approach, taking into account the context and usage of these methods within the broader application. This transformation ensures that methods don't rely on the state of a particular instance of the class but rather, operate at the class level, possibly requiring additional parameters to act upon data that would have been inherent to the instance. Here's a structured plan for each instance method identified in the provided code:

#set_flag: Currently, this method updates an attribute of a specific instance. To convert it into a class method, it would need to accept an identifier for the DueDate instance (such as id) as a parameter. The class method would then locate the specific instance within the database and update its attribute. The signature would change from set_flag to something like self.set_flag(id), where id is used to find the DueDate instance and update it.
#due_at_is_valid_datetime: This validation method checks if the due_at attribute of an instance is a valid datetime. To change this into a class method, it would need to accept a datetime string as a parameter. However, validations in Rails models are inherently designed to be instance methods since they operate on the attributes of a specific instance before saving or updating it. Instead of transforming this into a class method, consider whether it's more appropriate to keep as an instance method or refactor the validation logic elsewhere where it can be used more generically.
#For the <=> (spaceship operator) method, transforming it into a class method doesn't follow the conventional use of class methods or the purpose of the spaceship operator. The spaceship operator is used to compare two instances of the same class. Its use as a class method would be unconventional and counterintuitive since it's designed to operate on instances. If there's a compelling reason to compare data at the class level, consider implementing a separate class method that takes identifiers or attributes of two entities as parameters to perform the comparison, but this would be a deviation from the typical use of the <=> operator.

The transformation from instance methods to class methods often means changing the scope from operating on a single, specific instance to handling a broader class-level operation. This usually involves adding parameters to methods that were previously not needed because the instance itself held the context. Moreover, for some functionalities like validations or comparisons (<=> operator), the shift might not be practical or align with Rails conventions and object-oriented principles. It's crucial to assess the necessity and implications of such changes on the overall design and maintainability of the codebase.

====Testing with Rspec:====
At our next testing iteration, we plan to enhance the readability, maintainability, and coverage of our DueDate model tests using RSpec. We aim to achieve this by implementing several key strategies.

#Firstly, we'll organize our tests into contextual groupings using descriptive describe blocks. Each block will encapsulate different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach will improve the readability of our test suite by providing clear and logical groupings. Additionally, we'll employ helper methods within the before(:each) block to streamline setup logic. These methods will handle common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we'll leverage mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we'll mock the required dependencies rather than relying on real database records. This approach speeds up tests and isolates the behavior under test. 
#Furthermore, we'll pay attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we'll ensure the robustness of our model and handle unexpected scenarios gracefully. 
#Our test assertions will be reviewed to ensure clarity and completeness. We'll verify that each test covers all expected outcomes and that assertions are clear and concise. For instance, in tests like copying due dates to a new assignment, we'll not only check the count but also verify that due dates in the new assignment match the originals. 
#We'll also focus on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we'll ensure that error handling scenarios are covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grows, we'll monitor test performance using RSpec's profiling tools and optimize slow tests as needed. Additionally, we'll document our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we aim to create a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

== Design Principles ==

=== Testing with RSwag: ===

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-09T00:11:36Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing instance methods to class methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Instance to Class Methods: Changing as many instance methods to class methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
Our refactoring initiative will encompass specific actions to improve code clarity, optimize performance, and bolster maintainability across our application.

Firstly, we'll embark on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we'll include comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior.

Secondly, we'll focus on enhancing variable and method names. In the done_in_assignment_round method, we'll rename variables like due_dates to assignment_due_dates for clarity. Additionally, we'll rename the copy method to duplicate_due_dates to better convey its functionality.

Breaking down complex methods into smaller, focused functions will be another key aspect. For example, in the done_in_assignment_round method, we'll extract the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability.

Optimization efforts will involve reviewing database queries for efficiency. In the get_next_due_date method, we'll optimize the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics.

Robustness enhancements will include refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we'll provide more informative error messages to guide developers in identifying and resolving invalid datetime inputs.

Adherence to Ruby and Rails best practices will be ensured throughout the refactoring process. We'll leverage Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we'll utilize ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety.

To mitigate against regressions, we'll implement thorough unit tests using frameworks like RSpec or Minitest. For instance, we'll write tests to verify the behavior of the set_flag method and ensure it correctly updates the flag attribute.

Lastly, we'll document our progress and collaborate effectively using version control systems like Git. Code reviews will provide valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase.

By undertaking these specific actions, we aim to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Instance Methods to Class Methods:====

Transforming instance methods to class methods in the DueDate class requires a strategic approach, taking into account the context and usage of these methods within the broader application. This transformation ensures that methods don't rely on the state of a particular instance of the class but rather, operate at the class level, possibly requiring additional parameters to act upon data that would have been inherent to the instance. Here's a structured plan for each instance method identified in the provided code:

#set_flag: Currently, this method updates an attribute of a specific instance. To convert it into a class method, it would need to accept an identifier for the DueDate instance (such as id) as a parameter. The class method would then locate the specific instance within the database and update its attribute. The signature would change from set_flag to something like self.set_flag(id), where id is used to find the DueDate instance and update it.
#due_at_is_valid_datetime: This validation method checks if the due_at attribute of an instance is a valid datetime. To change this into a class method, it would need to accept a datetime string as a parameter. However, validations in Rails models are inherently designed to be instance methods since they operate on the attributes of a specific instance before saving or updating it. Instead of transforming this into a class method, consider whether it's more appropriate to keep as an instance method or refactor the validation logic elsewhere where it can be used more generically.
#For the <=> (spaceship operator) method, transforming it into a class method doesn't follow the conventional use of class methods or the purpose of the spaceship operator. The spaceship operator is used to compare two instances of the same class. Its use as a class method would be unconventional and counterintuitive since it's designed to operate on instances. If there's a compelling reason to compare data at the class level, consider implementing a separate class method that takes identifiers or attributes of two entities as parameters to perform the comparison, but this would be a deviation from the typical use of the <=> operator.

The transformation from instance methods to class methods often means changing the scope from operating on a single, specific instance to handling a broader class-level operation. This usually involves adding parameters to methods that were previously not needed because the instance itself held the context. Moreover, for some functionalities like validations or comparisons (<=> operator), the shift might not be practical or align with Rails conventions and object-oriented principles. It's crucial to assess the necessity and implications of such changes on the overall design and maintainability of the codebase.

====Testing with Rspec:====
At our next testing iteration, we plan to enhance the readability, maintainability, and coverage of our DueDate model tests using RSpec. We aim to achieve this by implementing several key strategies.

#Firstly, we'll organize our tests into contextual groupings using descriptive describe blocks. Each block will encapsulate different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach will improve the readability of our test suite by providing clear and logical groupings. Additionally, we'll employ helper methods within the before(:each) block to streamline setup logic. These methods will handle common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we'll leverage mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we'll mock the required dependencies rather than relying on real database records. This approach speeds up tests and isolates the behavior under test. 
#Furthermore, we'll pay attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we'll ensure the robustness of our model and handle unexpected scenarios gracefully. 
#Our test assertions will be reviewed to ensure clarity and completeness. We'll verify that each test covers all expected outcomes and that assertions are clear and concise. For instance, in tests like copying due dates to a new assignment, we'll not only check the count but also verify that due dates in the new assignment match the originals. 
#We'll also focus on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we'll ensure that error handling scenarios are covered comprehensively, guaranteeing robustness in the face of unexpected inputs. As our test suite grows, we'll monitor test performance using RSpec's profiling tools and optimize slow tests as needed. Additionally, we'll document our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we aim to create a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

== Design Principles ==

=== Testing with RSwag: ===

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-09T00:11:18Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing instance methods to class methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Instance to Class Methods: Changing as many instance methods to class methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
Our refactoring initiative will encompass specific actions to improve code clarity, optimize performance, and bolster maintainability across our application.

Firstly, we'll embark on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we'll include comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior.

Secondly, we'll focus on enhancing variable and method names. In the done_in_assignment_round method, we'll rename variables like due_dates to assignment_due_dates for clarity. Additionally, we'll rename the copy method to duplicate_due_dates to better convey its functionality.

Breaking down complex methods into smaller, focused functions will be another key aspect. For example, in the done_in_assignment_round method, we'll extract the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability.

Optimization efforts will involve reviewing database queries for efficiency. In the get_next_due_date method, we'll optimize the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics.

Robustness enhancements will include refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we'll provide more informative error messages to guide developers in identifying and resolving invalid datetime inputs.

Adherence to Ruby and Rails best practices will be ensured throughout the refactoring process. We'll leverage Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we'll utilize ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety.

To mitigate against regressions, we'll implement thorough unit tests using frameworks like RSpec or Minitest. For instance, we'll write tests to verify the behavior of the set_flag method and ensure it correctly updates the flag attribute.

Lastly, we'll document our progress and collaborate effectively using version control systems like Git. Code reviews will provide valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase.

By undertaking these specific actions, we aim to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Instance Methods to Class Methods:====

Transforming instance methods to class methods in the DueDate class requires a strategic approach, taking into account the context and usage of these methods within the broader application. This transformation ensures that methods don't rely on the state of a particular instance of the class but rather, operate at the class level, possibly requiring additional parameters to act upon data that would have been inherent to the instance. Here's a structured plan for each instance method identified in the provided code:

#set_flag: Currently, this method updates an attribute of a specific instance. To convert it into a class method, it would need to accept an identifier for the DueDate instance (such as id) as a parameter. The class method would then locate the specific instance within the database and update its attribute. The signature would change from set_flag to something like self.set_flag(id), where id is used to find the DueDate instance and update it.
#due_at_is_valid_datetime: This validation method checks if the due_at attribute of an instance is a valid datetime. To change this into a class method, it would need to accept a datetime string as a parameter. However, validations in Rails models are inherently designed to be instance methods since they operate on the attributes of a specific instance before saving or updating it. Instead of transforming this into a class method, consider whether it's more appropriate to keep as an instance method or refactor the validation logic elsewhere where it can be used more generically.
#For the <=> (spaceship operator) method, transforming it into a class method doesn't follow the conventional use of class methods or the purpose of the spaceship operator. The spaceship operator is used to compare two instances of the same class. Its use as a class method would be unconventional and counterintuitive since it's designed to operate on instances. If there's a compelling reason to compare data at the class level, consider implementing a separate class method that takes identifiers or attributes of two entities as parameters to perform the comparison, but this would be a deviation from the typical use of the <=> operator.

The transformation from instance methods to class methods often means changing the scope from operating on a single, specific instance to handling a broader class-level operation. This usually involves adding parameters to methods that were previously not needed because the instance itself held the context. Moreover, for some functionalities like validations or comparisons (<=> operator), the shift might not be practical or align with Rails conventions and object-oriented principles. It's crucial to assess the necessity and implications of such changes on the overall design and maintainability of the codebase.

====Testing with Rspec:====
At our next testing iteration, we plan to enhance the readability, maintainability, and coverage of our DueDate model tests using RSpec. We aim to achieve this by implementing several key strategies.

#Firstly, we'll organize our tests into contextual groupings using descriptive describe blocks. Each block will encapsulate different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach will improve the readability of our test suite by providing clear and logical groupings.
Additionally, we'll employ helper methods within the before(:each) block to streamline setup logic. These methods will handle common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we'll leverage mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we'll mock the required dependencies rather than relying on real database records. This approach speeds up tests and isolates the behavior under test. 
#Furthermore, we'll pay attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we'll ensure the robustness of our model and handle unexpected scenarios gracefully. 
#Our test assertions will be reviewed to ensure clarity and completeness. We'll verify that each test covers all expected outcomes and that assertions are clear and concise. For instance, in tests like copying due dates to a new assignment, we'll not only check the count but also verify that due dates in the new assignment match the originals. 
#We'll also focus on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we'll ensure that error handling scenarios are covered comprehensively, guaranteeing robustness in the face of unexpected inputs.
As our test suite grows, we'll monitor test performance using RSpec's profiling tools and optimize slow tests as needed. Additionally, we'll document our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we aim to create a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

== Design Principles ==

=== Testing with RSwag: ===

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-09T00:10:49Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing instance methods to class methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Instance to Class Methods: Changing as many instance methods to class methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
Our refactoring initiative will encompass specific actions to improve code clarity, optimize performance, and bolster maintainability across our application.

Firstly, we'll embark on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we'll include comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior.

Secondly, we'll focus on enhancing variable and method names. In the done_in_assignment_round method, we'll rename variables like due_dates to assignment_due_dates for clarity. Additionally, we'll rename the copy method to duplicate_due_dates to better convey its functionality.

Breaking down complex methods into smaller, focused functions will be another key aspect. For example, in the done_in_assignment_round method, we'll extract the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability.

Optimization efforts will involve reviewing database queries for efficiency. In the get_next_due_date method, we'll optimize the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics.

Robustness enhancements will include refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we'll provide more informative error messages to guide developers in identifying and resolving invalid datetime inputs.

Adherence to Ruby and Rails best practices will be ensured throughout the refactoring process. We'll leverage Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we'll utilize ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety.

To mitigate against regressions, we'll implement thorough unit tests using frameworks like RSpec or Minitest. For instance, we'll write tests to verify the behavior of the set_flag method and ensure it correctly updates the flag attribute.

Lastly, we'll document our progress and collaborate effectively using version control systems like Git. Code reviews will provide valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase.

By undertaking these specific actions, we aim to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Instance Methods to Class Methods:====

Transforming instance methods to class methods in the DueDate class requires a strategic approach, taking into account the context and usage of these methods within the broader application. This transformation ensures that methods don't rely on the state of a particular instance of the class but rather, operate at the class level, possibly requiring additional parameters to act upon data that would have been inherent to the instance. Here's a structured plan for each instance method identified in the provided code:

#set_flag: Currently, this method updates an attribute of a specific instance. To convert it into a class method, it would need to accept an identifier for the DueDate instance (such as id) as a parameter. The class method would then locate the specific instance within the database and update its attribute. The signature would change from set_flag to something like self.set_flag(id), where id is used to find the DueDate instance and update it.
#due_at_is_valid_datetime: This validation method checks if the due_at attribute of an instance is a valid datetime. To change this into a class method, it would need to accept a datetime string as a parameter. However, validations in Rails models are inherently designed to be instance methods since they operate on the attributes of a specific instance before saving or updating it. Instead of transforming this into a class method, consider whether it's more appropriate to keep as an instance method or refactor the validation logic elsewhere where it can be used more generically.
#For the <=> (spaceship operator) method, transforming it into a class method doesn't follow the conventional use of class methods or the purpose of the spaceship operator. The spaceship operator is used to compare two instances of the same class. Its use as a class method would be unconventional and counterintuitive since it's designed to operate on instances. If there's a compelling reason to compare data at the class level, consider implementing a separate class method that takes identifiers or attributes of two entities as parameters to perform the comparison, but this would be a deviation from the typical use of the <=> operator.

The transformation from instance methods to class methods often means changing the scope from operating on a single, specific instance to handling a broader class-level operation. This usually involves adding parameters to methods that were previously not needed because the instance itself held the context. Moreover, for some functionalities like validations or comparisons (<=> operator), the shift might not be practical or align with Rails conventions and object-oriented principles. It's crucial to assess the necessity and implications of such changes on the overall design and maintainability of the codebase.

====Testing with Rspec:====
At our next testing iteration, we plan to enhance the readability, maintainability, and coverage of our DueDate model tests using RSpec. We aim to achieve this by implementing several key strategies.

#Firstly, we'll organize our tests into contextual groupings using descriptive describe blocks. Each block will encapsulate different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach will improve the readability of our test suite by providing clear and logical groupings. 
Additionally, we'll employ helper methods within the before(:each) block to streamline setup logic. These methods will handle common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable. 
#To ensure test efficiency and isolation, we'll leverage mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we'll mock the required dependencies rather than relying on real database records. This approach speeds up tests and isolates the behavior under test. 
#Furthermore, we'll pay attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we'll ensure the robustness of our model and handle unexpected scenarios gracefully. 
#Our test assertions will be reviewed to ensure clarity and completeness. We'll verify that each test covers all expected outcomes and that assertions are clear and concise. For instance, in tests like copying due dates to a new assignment, we'll not only check the count but also verify that due dates in the new assignment match the originals. 
#We'll also focus on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we'll ensure that error handling scenarios are covered comprehensively, guaranteeing robustness in the face of unexpected inputs.
As our test suite grows, we'll monitor test performance using RSpec's profiling tools and optimize slow tests as needed. Additionally, we'll document our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality. 
#By implementing these strategies, we aim to create a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

== Design Principles ==

=== Testing with RSwag: ===

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-09T00:09:22Z

Dukolhat:

==E2418. Reimplement due_date.rb (Phase 2)==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

==Introduction==
We're refactoring the due_dates.rb in Expertiza, enhancing its codebase to adhere to DRY and design principles, improving readability, and reducing redundancy. Our focus includes changing instance methods to class methods and further testing.

==Problem Statement==
The reimplementation project entails:
#Refactoring due_date.rb: Enhancing code clarity, optimizing, and adding comments for unclear lines of code to improve maintainability and readability.
#Instance to Class Methods: Changing as many instance methods to class methods as possible.
#Testing with Rspec: Writing comprehensive tests using Rspec for each method to ensure functionality and integration, followed by a video demonstration showcasing the functionality of the reimplementation.

==Plan for Reimplementation of DueDate==
====Refactoring due_date.rb:====
Our refactoring initiative will encompass specific actions to improve code clarity, optimize performance, and bolster maintainability across our application.

Firstly, we'll embark on adding descriptive comments throughout the codebase. For instance, within the teammate_review_allowed? method, we'll include comments explaining the logic behind determining whether teammate review is allowed, making it easier for developers to understand the function's purpose and behavior.

Secondly, we'll focus on enhancing variable and method names. In the done_in_assignment_round method, we'll rename variables like due_dates to assignment_due_dates for clarity. Additionally, we'll rename the copy method to duplicate_due_dates to better convey its functionality.

Breaking down complex methods into smaller, focused functions will be another key aspect. For example, in the done_in_assignment_round method, we'll extract the logic for sorting and filtering due dates into separate helper methods, improving readability and maintainability.

Optimization efforts will involve reviewing database queries for efficiency. In the get_next_due_date method, we'll optimize the query by using ActiveRecord query methods or adding appropriate database indexes to speed up retrieval of due dates, especially in cases where assignments have staggered deadlines or multiple topics.

Robustness enhancements will include refining error handling mechanisms. For instance, in the due_at_is_valid_datetime method, we'll provide more informative error messages to guide developers in identifying and resolving invalid datetime inputs.

Adherence to Ruby and Rails best practices will be ensured throughout the refactoring process. We'll leverage Rails conventions and built-in functionalities wherever possible. For example, in the set_flag method, we'll utilize ActiveRecord's update method with attribute names instead of update_attribute for improved code clarity and safety.

To mitigate against regressions, we'll implement thorough unit tests using frameworks like RSpec or Minitest. For instance, we'll write tests to verify the behavior of the set_flag method and ensure it correctly updates the flag attribute.

Lastly, we'll document our progress and collaborate effectively using version control systems like Git. Code reviews will provide valuable feedback on adherence to coding standards and best practices, ensuring consistency and quality across the codebase.

By undertaking these specific actions, we aim to transform our codebase into a more readable, efficient, and maintainable state, facilitating ongoing development and enhancement of our application.

====Instance Methods to Class Methods:====

Transforming instance methods to class methods in the DueDate class requires a strategic approach, taking into account the context and usage of these methods within the broader application. This transformation ensures that methods don't rely on the state of a particular instance of the class but rather, operate at the class level, possibly requiring additional parameters to act upon data that would have been inherent to the instance. Here's a structured plan for each instance method identified in the provided code:

#set_flag: Currently, this method updates an attribute of a specific instance. To convert it into a class method, it would need to accept an identifier for the DueDate instance (such as id) as a parameter. The class method would then locate the specific instance within the database and update its attribute. The signature would change from set_flag to something like self.set_flag(id), where id is used to find the DueDate instance and update it.
#due_at_is_valid_datetime: This validation method checks if the due_at attribute of an instance is a valid datetime. To change this into a class method, it would need to accept a datetime string as a parameter. However, validations in Rails models are inherently designed to be instance methods since they operate on the attributes of a specific instance before saving or updating it. Instead of transforming this into a class method, consider whether it's more appropriate to keep as an instance method or refactor the validation logic elsewhere where it can be used more generically.
#For the <=> (spaceship operator) method, transforming it into a class method doesn't follow the conventional use of class methods or the purpose of the spaceship operator. The spaceship operator is used to compare two instances of the same class. Its use as a class method would be unconventional and counterintuitive since it's designed to operate on instances. If there's a compelling reason to compare data at the class level, consider implementing a separate class method that takes identifiers or attributes of two entities as parameters to perform the comparison, but this would be a deviation from the typical use of the <=> operator.

The transformation from instance methods to class methods often means changing the scope from operating on a single, specific instance to handling a broader class-level operation. This usually involves adding parameters to methods that were previously not needed because the instance itself held the context. Moreover, for some functionalities like validations or comparisons (<=> operator), the shift might not be practical or align with Rails conventions and object-oriented principles. It's crucial to assess the necessity and implications of such changes on the overall design and maintainability of the codebase.

====Testing with Rspec:====
At our next testing iteration, we plan to enhance the readability, maintainability, and coverage of our DueDate model tests using RSpec. We aim to achieve this by implementing several key strategies.

Firstly, we'll organize our tests into contextual groupings using descriptive describe blocks. Each block will encapsulate different aspects of the model's functionality, such as validation, manipulation, and behavior under specific conditions. This approach will improve the readability of our test suite by providing clear and logical groupings.

Additionally, we'll employ helper methods within the before(:each) block to streamline setup logic. These methods will handle common setup tasks, such as creating due dates with various attributes, reducing repetition, and making the test setup more concise and understandable.

To ensure test efficiency and isolation, we'll leverage mocking techniques to simulate dependencies where necessary. For methods relying on complex associations or external data, we'll mock the required dependencies rather than relying on real database records. This approach speeds up tests and isolates the behavior under test.

Furthermore, we'll pay attention to edge cases, ensuring comprehensive test coverage by including scenarios such as nil due dates, absence of response maps, and staggered deadline variations. By testing these edge cases, we'll ensure the robustness of our model and handle unexpected scenarios gracefully.

Our test assertions will be reviewed to ensure clarity and completeness. We'll verify that each test covers all expected outcomes and that assertions are clear and concise. For instance, in tests like copying due dates to a new assignment, we'll not only check the count but also verify that due dates in the new assignment match the originals.

We'll also focus on error handling, testing both error and success paths thoroughly. For methods like due_at_is_valid_datetime, we'll ensure that error handling scenarios are covered comprehensively, guaranteeing robustness in the face of unexpected inputs.

As our test suite grows, we'll monitor test performance using RSpec's profiling tools and optimize slow tests as needed. Additionally, we'll document our tests with comments or descriptions to clarify the purpose of each test, aiding understanding for future maintainers and contributing to overall code quality.

By implementing these strategies, we aim to create a comprehensive, maintainable, and efficient test suite for our DueDate model using RSpec.

== Design Principles ==

=== Testing with RSwag: ===

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-08T23:53:42Z

Dukolhat:

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-08T23:53:20Z

Dukolhat:

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-08T23:52:28Z

Dukolhat:

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb (Phase 2)

2024-04-08T23:40:11Z

Dukolhat: Created page with "==E2418. Reimplement due_date.rb== This page provides a description of the Expertiza based OSS project. __TOC__ ===About Expertiza=== [http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form tea..."

==E2418. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Utilized Rails built-in APIs for tasks such as validation, scoping, and database access.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

Old Code:
<pre>
def self.current_due_date(due_dates)
..
def self.teammate_review_allowed(student)
..
def self.set_duedate(duedate, deadline, assign_id, max_round)
..
def self.deadline_sort(due_dates)
</pre>

New Code:
<pre>
def self.current(due_dates)
..
def self.teammate_review_allowed?(student)
..
def self.set_due_date(duedate, deadline, assign_id, max_round)
..
def self.sort_deadlines(due_dates)
</pre>

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

Old Code:
<pre>
def self.current(due_dates)
# Get the current due date from list of due dates
due_dates.each do |due_date|
if due_date.due_at > Time.now
current_due_date = due_date
return current_due_date
end
end
# in case current due date not found
nil
end
</pre>

<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
due_date &&
(due_date.teammate_review_allowed_id == 3 ||
due_date.teammate_review_allowed_id == 2) # late(2) or yes(3)
end
</pre>

<pre>
def self.copy(old_assignment_id, new_assignment_id)
duedates = where(parent_id: old_assignment_id)
duedates.each do |orig_due_date|
..
end
end
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| due_date.deadline_type_id != 1 && due_date.deadline_type_id != 2 }
..
end
</pre>

New Code:
<pre>
def self.current(due_dates)
due_dates.detect { |due_date| due_date.due_at > Time.now }
end

<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
(due_date && [2, 3].include?(due_date.teammate_review_allowed_id))
end
</pre>

<pre>
def self.copy(old_assignment_id, new_assignment_id)
where(parent_id: old_assignment_id).each do |orig_due_date|
..
end
end
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| ![1, 2].include?(due_date.deadline_type_id) }
..
end
</pre>

=== Utilized Rails built-in APIs for tasks such as validation, scoping, and database access ===

Old Code:
<pre>
def set_flag
self.flag = true
save
end
..
</pre>

<pre>
def self.set_due_date(duedate, deadline, assign_id, max_round)
submit_duedate = DueDate.new(duedate)
submit_duedate.deadline_type_id = deadline
submit_duedate.parent_id = assign_id
submit_duedate.round = max_round
submit_duedate.save
end
</pre>

New Code:
<pre>
def set_flag
update_attribute(:flag, true)
end
..
</pre>

<pre>
def self.set_due_date(duedate, deadline, assign_id, max_round)
submit_duedate = DueDate.new(duedate)
submit_duedate.update(deadline_type_id: deadline, parent_id: assign_id, round: max_round)
end
</pre>

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

Old Code:
<pre>
def self.sort_deadlines(due_dates)
due_dates.sort do |m1, m2|
if m1.due_at && m2.due_at
m1.due_at <=> m2.due_at
elsif m1.due_at
-1
else
1
end
end
end
</pre>

<pre>
..
def self.done_in_assignment_round(assignment_id, response)
..
sorted_deadlines = sort_deadlines(due_dates)
..
end
</pre>

New Code:
<pre>
def <=>(other)
return nil unless other.is_a?(DueDate)

if due_at && other.due_at
due_at <=> other.due_at
elsif due_at
-1
else
1
end
end
..
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
sorted_deadlines = due_dates.sort
..
end
</pre>

== Test Plan ==

All the previous test cases pass in the new implementation of the system.
The following outlines the NEW scenario and cases to be tested for the <=> functionality within the system:

=== Sorting Due Dates ===
* Scenario: Verify that due dates are sorted in the correct order.
* Edge Case: Include due dates with identical timestamps to assess the stability of the sorting algorithm.

<pre>
it 'sort duedate records' do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all? { |m1, m2| (m1.due_at <=> m2.due_at) != 1 }).to eql false
sorted_due_dates = @due_dates.sort
expect(sorted_due_dates.each_cons(2).all? { |m1, m2| (m1.due_at <=> m2.due_at) != 1 }).to eql true
end
</pre>

All tests passed successfully:
[[File:DueDateTest.png|1000px|thumb|none|]]

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-24T20:49:03Z

Dukolhat:

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-24T20:48:44Z

Dukolhat:

==E2418. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Utilized Rails built-in APIs for tasks such as validation, scoping, and database access.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

Old Code:
<pre>
def self.current_due_date(due_dates)
..
def self.teammate_review_allowed(student)
..
def self.set_duedate(duedate, deadline, assign_id, max_round)
..
def self.deadline_sort(due_dates)
</pre>

New Code:
<pre>
def self.current(due_dates)
..
def self.teammate_review_allowed?(student)
..
def self.set_due_date(duedate, deadline, assign_id, max_round)
..
def self.sort_deadlines(due_dates)
</pre>

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

Old Code:
<pre>
def self.current(due_dates)
# Get the current due date from list of due dates
due_dates.each do |due_date|
if due_date.due_at > Time.now
current_due_date = due_date
return current_due_date
end
end
# in case current due date not found
nil
end
</pre>

<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
due_date &&
(due_date.teammate_review_allowed_id == 3 ||
due_date.teammate_review_allowed_id == 2) # late(2) or yes(3)
end
</pre>

<pre>
def self.copy(old_assignment_id, new_assignment_id)
duedates = where(parent_id: old_assignment_id)
duedates.each do |orig_due_date|
..
end
end
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| due_date.deadline_type_id != 1 && due_date.deadline_type_id != 2 }
..
end
</pre>

New Code:
<pre>
def self.current(due_dates)
due_dates.detect { |due_date| due_date.due_at > Time.now }
end

<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
(due_date && [2, 3].include?(due_date.teammate_review_allowed_id))
end
</pre>

<pre>
def self.copy(old_assignment_id, new_assignment_id)
where(parent_id: old_assignment_id).each do |orig_due_date|
..
end
end
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| ![1, 2].include?(due_date.deadline_type_id) }
..
end
</pre>

=== Utilized Rails built-in APIs for tasks such as validation, scoping, and database access ===

Old Code:
<pre>
def set_flag
self.flag = true
save
end
..
</pre>

<pre>
def self.set_due_date(duedate, deadline, assign_id, max_round)
submit_duedate = DueDate.new(duedate)
submit_duedate.deadline_type_id = deadline
submit_duedate.parent_id = assign_id
submit_duedate.round = max_round
submit_duedate.save
end
</pre>

New Code:
<pre>
def set_flag
update_attribute(:flag, true)
end
..
</pre>

<pre>
def self.set_due_date(duedate, deadline, assign_id, max_round)
submit_duedate = DueDate.new(duedate)
submit_duedate.update(deadline_type_id: deadline, parent_id: assign_id, round: max_round)
end
</pre>

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

Old Code:
<pre>
def self.sort_deadlines(due_dates)
due_dates.sort do |m1, m2|
if m1.due_at && m2.due_at
m1.due_at <=> m2.due_at
elsif m1.due_at
-1
else
1
end
end
end
</pre>

<pre>
..
def self.done_in_assignment_round(assignment_id, response)
..
sorted_deadlines = sort_deadlines(due_dates)
..
end
</pre>

New Code:
<pre>
def <=>(other)
return nil unless other.is_a?(DueDate)

if due_at && other.due_at
due_at <=> other.due_at
elsif due_at
-1
else
1
end
end
..
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
sorted_deadlines = due_dates.sort
..
end
</pre>

== Test Plan ==

All the previous test cases pass in the new implementation of the system.
The following outlines the NEW scenario and cases to be tested for the <=> functionality within the system:

=== Sorting Due Dates ===
* Scenario: Verify that due dates are sorted in the correct order.
* Edge Case: Include due dates with identical timestamps to assess the stability of the sorting algorithm.

<pre>
it 'sort duedate records' do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all? { |m1, m2| (m1.due_at <=> m2.due_at) != 1 }).to eql false
sorted_due_dates = @due_dates.sort
expect(sorted_due_dates.each_cons(2).all? { |m1, m2| (m1.due_at <=> m2.due_at) != 1 }).to eql true
end
</pre>

All tests running:
[[File:DueDateTest.png|1000px|thumb|none|]]

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

File:DueDateTest.png

2024-03-24T20:48:36Z

Dukolhat:

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-24T20:43:01Z

Dukolhat:

==E2418. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Utilized Rails built-in APIs for tasks such as validation, scoping, and database access.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

Old Code:
<pre>
def self.current_due_date(due_dates)
..
def self.teammate_review_allowed(student)
..
def self.set_duedate(duedate, deadline, assign_id, max_round)
..
def self.deadline_sort(due_dates)
</pre>

New Code:
<pre>
def self.current(due_dates)
..
def self.teammate_review_allowed?(student)
..
def self.set_due_date(duedate, deadline, assign_id, max_round)
..
def self.sort_deadlines(due_dates)
</pre>

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

Old Code:
<pre>
def self.current(due_dates)
# Get the current due date from list of due dates
due_dates.each do |due_date|
if due_date.due_at > Time.now
current_due_date = due_date
return current_due_date
end
end
# in case current due date not found
nil
end
</pre>

<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
due_date &&
(due_date.teammate_review_allowed_id == 3 ||
due_date.teammate_review_allowed_id == 2) # late(2) or yes(3)
end
</pre>

<pre>
def self.copy(old_assignment_id, new_assignment_id)
duedates = where(parent_id: old_assignment_id)
duedates.each do |orig_due_date|
..
end
end
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| due_date.deadline_type_id != 1 && due_date.deadline_type_id != 2 }
..
end
</pre>

New Code:
<pre>
def self.current(due_dates)
due_dates.detect { |due_date| due_date.due_at > Time.now }
end

<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
(due_date && [2, 3].include?(due_date.teammate_review_allowed_id))
end
</pre>

<pre>
def self.copy(old_assignment_id, new_assignment_id)
where(parent_id: old_assignment_id).each do |orig_due_date|
..
end
end
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| ![1, 2].include?(due_date.deadline_type_id) }
..
end
</pre>

=== Utilized Rails built-in APIs for tasks such as validation, scoping, and database access ===

Old Code:
<pre>
def set_flag
self.flag = true
save
end
..
</pre>

<pre>
def self.set_due_date(duedate, deadline, assign_id, max_round)
submit_duedate = DueDate.new(duedate)
submit_duedate.deadline_type_id = deadline
submit_duedate.parent_id = assign_id
submit_duedate.round = max_round
submit_duedate.save
end
</pre>

New Code:
<pre>
def set_flag
update_attribute(:flag, true)
end
..
</pre>

<pre>
def self.set_due_date(duedate, deadline, assign_id, max_round)
submit_duedate = DueDate.new(duedate)
submit_duedate.update(deadline_type_id: deadline, parent_id: assign_id, round: max_round)
end
</pre>

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

Old Code:
<pre>
def self.sort_deadlines(due_dates)
due_dates.sort do |m1, m2|
if m1.due_at && m2.due_at
m1.due_at <=> m2.due_at
elsif m1.due_at
-1
else
1
end
end
end
</pre>

<pre>
..
def self.done_in_assignment_round(assignment_id, response)
..
sorted_deadlines = sort_deadlines(due_dates)
..
end
</pre>

New Code:
<pre>
def <=>(other)
return nil unless other.is_a?(DueDate)

if due_at && other.due_at
due_at <=> other.due_at
elsif due_at
-1
else
1
end
end
..
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
sorted_deadlines = due_dates.sort
..
end
</pre>

== Test Plan ==

All the previous test cases pass in the new implementation of the system.
The following outlines the NEW scenario and cases to be tested for the <=> functionality within the system:

=== Sorting Due Dates ===
* Scenario: Verify that due dates are sorted in the correct order.
* Edge Case: Include due dates with identical timestamps to assess the stability of the sorting algorithm.

<pre>
it 'sort duedate records' do
sorted_due_dates = @due_dates
expect(sorted_due_dates.each_cons(2).all? { |m1, m2| (m1.due_at <=> m2.due_at) != 1 }).to eql false
sorted_due_dates = @due_dates.sort
expect(sorted_due_dates.each_cons(2).all? { |m1, m2| (m1.due_at <=> m2.due_at) != 1 }).to eql true
end
</pre>

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-24T20:36:46Z

Dukolhat:

==E2418. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Utilized Rails built-in APIs for tasks such as validation, scoping, and database access.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

Old Code:
<pre>
def self.current_due_date(due_dates)
..
def self.teammate_review_allowed(student)
..
def self.set_duedate(duedate, deadline, assign_id, max_round)
..
def self.deadline_sort(due_dates)
</pre>

New Code:
<pre>
def self.current(due_dates)
..
def self.teammate_review_allowed?(student)
..
def self.set_due_date(duedate, deadline, assign_id, max_round)
..
def self.sort_deadlines(due_dates)
</pre>

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

Old Code:
<pre>
def self.current(due_dates)
# Get the current due date from list of due dates
due_dates.each do |due_date|
if due_date.due_at > Time.now
current_due_date = due_date
return current_due_date
end
end
# in case current due date not found
nil
end
..
</pre>

<pre>

def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
due_date &&
(due_date.teammate_review_allowed_id == 3 ||
due_date.teammate_review_allowed_id == 2) # late(2) or yes(3)
end
..
</pre>

<pre>
def self.copy(old_assignment_id, new_assignment_id)
duedates = where(parent_id: old_assignment_id)
duedates.each do |orig_due_date|
..
end
end
..
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| due_date.deadline_type_id != 1 && due_date.deadline_type_id != 2 }
..
end
</pre>

New Code:
<pre>
def self.current(due_dates)
due_dates.detect { |due_date| due_date.due_at > Time.now }
end
..

<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
(due_date && [2, 3].include?(due_date.teammate_review_allowed_id))
end
..
</pre>

<pre>
def self.copy(old_assignment_id, new_assignment_id)
where(parent_id: old_assignment_id).each do |orig_due_date|
..
end
end
..
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| ![1, 2].include?(due_date.deadline_type_id) }
..
end
</pre>

=== Utilized Rails built-in APIs for tasks such as validation, scoping, and database access ===

Old Code:
<pre>
def set_flag
self.flag = true
save
end
..
</pre>

<pre>
def self.set_due_date(duedate, deadline, assign_id, max_round)
submit_duedate = DueDate.new(duedate)
submit_duedate.deadline_type_id = deadline
submit_duedate.parent_id = assign_id
submit_duedate.round = max_round
submit_duedate.save
end
</pre>

New Code:
<pre>
def set_flag
update_attribute(:flag, true)
end
..
</pre>

<pre>
def self.set_due_date(duedate, deadline, assign_id, max_round)
submit_duedate = DueDate.new(duedate)
submit_duedate.update(deadline_type_id: deadline, parent_id: assign_id, round: max_round)
end
</pre>

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

Old Code:
<pre>
def self.sort_deadlines(due_dates)
due_dates.sort do |m1, m2|
if m1.due_at && m2.due_at
m1.due_at <=> m2.due_at
elsif m1.due_at
-1
else
1
end
end
end
</pre>

<pre>
..
def self.done_in_assignment_round(assignment_id, response)
..
sorted_deadlines = sort_deadlines(due_dates)
..
end
</pre>

New Code:
<pre>
def <=>(other)
return nil unless other.is_a?(DueDate)

if due_at && other.due_at
due_at <=> other.due_at
elsif due_at
-1
else
1
end
end
..
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
sorted_deadlines = due_dates.sort
..
end
</pre>

== Test Plan ==

All the previous test cases pass in the new implementation of the system.
The following outlines the NEW scenario and cases to be tested for the <=> functionality within the system:

=== Sorting Due Dates ===
* Scenario: Verify that due dates are sorted in the correct order.
* Edge Case: Include due dates with identical timestamps to assess the stability of the sorting algorithm.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-24T20:32:50Z

Dukolhat:

==E2418. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Utilized Rails built-in APIs for tasks such as validation, scoping, and database access.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

Old Code:
<pre>
def self.current_due_date(due_dates)
..
def self.teammate_review_allowed(student)
..
def self.set_duedate(duedate, deadline, assign_id, max_round)
..
def self.deadline_sort(due_dates)
</pre>

New Code:
<pre>
def self.current(due_dates)
..
def self.teammate_review_allowed?(student)
..
def self.set_due_date(duedate, deadline, assign_id, max_round)
..
def self.sort_deadlines(due_dates)
</pre>

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

Old Code:
<pre>
def self.current(due_dates)
# Get the current due date from list of due dates
due_dates.each do |due_date|
if due_date.due_at > Time.now
current_due_date = due_date
return current_due_date
end
end
# in case current due date not found
nil
end
..
</pre>

<pre>

def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
due_date &&
(due_date.teammate_review_allowed_id == 3 ||
due_date.teammate_review_allowed_id == 2) # late(2) or yes(3)
end
..
</pre>

<pre>
def self.copy(old_assignment_id, new_assignment_id)
duedates = where(parent_id: old_assignment_id)
duedates.each do |orig_due_date|
..
end
end
..
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| due_date.deadline_type_id != 1 && due_date.deadline_type_id != 2 }
..
end
</pre>

New Code:
<pre>
def self.current(due_dates)
due_dates.detect { |due_date| due_date.due_at > Time.now }
end
..

<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
(due_date && [2, 3].include?(due_date.teammate_review_allowed_id))
end
..
</pre>

<pre>
def self.copy(old_assignment_id, new_assignment_id)
where(parent_id: old_assignment_id).each do |orig_due_date|
..
end
end
..
</pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| ![1, 2].include?(due_date.deadline_type_id) }
..
end
</pre>

=== Utilized Rails built-in APIs for tasks such as validation, scoping, and database access ===

[[File:DueDateRails1.png|1000px|thumb|none|]]

[[File:DueDateRails2.png|1000px|thumb|none|]]

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

[[File:DueDateOverride1.png|1000px|thumb|none|]]

[[File:DueDateOverride2.png|1000px|thumb|none|]]

[[File:DueDateOverride3.png|1000px|thumb|none|]]

== Test Plan ==

All the previous test cases pass in the new implementation of the system.
The following outlines the NEW scenario and cases to be tested for the <=> functionality within the system:

=== Sorting Due Dates ===
* Scenario: Verify that due dates are sorted in the correct order.
* Edge Case: Include due dates with identical timestamps to assess the stability of the sorting algorithm.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-24T20:31:12Z

Dukolhat:

==E2418. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Utilized Rails built-in APIs for tasks such as validation, scoping, and database access.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

Old Code:
<pre>
def self.current_due_date(due_dates)
..
def self.teammate_review_allowed(student)
..
def self.set_duedate(duedate, deadline, assign_id, max_round)
..
def self.deadline_sort(due_dates)

New Code:
<pre>
def self.current(due_dates)
..
def self.teammate_review_allowed?(student)
..
def self.set_due_date(duedate, deadline, assign_id, max_round)
..
def self.sort_deadlines(due_dates)

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

Old Code:
<pre>
def self.current(due_dates)
# Get the current due date from list of due dates
due_dates.each do |due_date|
if due_date.due_at > Time.now
current_due_date = due_date
return current_due_date
end
end
# in case current due date not found
nil
end
..

<pre>

def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
due_date &&
(due_date.teammate_review_allowed_id == 3 ||
due_date.teammate_review_allowed_id == 2) # late(2) or yes(3)
end
..

<pre>
def self.copy(old_assignment_id, new_assignment_id)
duedates = where(parent_id: old_assignment_id)
duedates.each do |orig_due_date|
..
end
end
..

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| due_date.deadline_type_id != 1 && due_date.deadline_type_id != 2 }
..
end

New Code:
<pre>
def self.current(due_dates)
due_dates.detect { |due_date| due_date.due_at > Time.now }
end
..

<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
(due_date && [2, 3].include?(due_date.teammate_review_allowed_id))
end
..

<pre>
def self.copy(old_assignment_id, new_assignment_id)
where(parent_id: old_assignment_id).each do |orig_due_date|
..
end
end
..

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| ![1, 2].include?(due_date.deadline_type_id) }
..
end

=== Utilized Rails built-in APIs for tasks such as validation, scoping, and database access ===

[[File:DueDateRails1.png|1000px|thumb|none|]]

[[File:DueDateRails2.png|1000px|thumb|none|]]

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

[[File:DueDateOverride1.png|1000px|thumb|none|]]

[[File:DueDateOverride2.png|1000px|thumb|none|]]

[[File:DueDateOverride3.png|1000px|thumb|none|]]

== Test Plan ==

All the previous test cases pass in the new implementation of the system.
The following outlines the NEW scenario and cases to be tested for the <=> functionality within the system:

=== Sorting Due Dates ===
* Scenario: Verify that due dates are sorted in the correct order.
* Edge Case: Include due dates with identical timestamps to assess the stability of the sorting algorithm.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-24T20:29:55Z

Dukolhat:

==E2418. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Utilized Rails built-in APIs for tasks such as validation, scoping, and database access.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

Old Code:
<pre>
def self.current_due_date(due_dates)
..
def self.teammate_review_allowed(student)
..
def self.set_duedate(duedate, deadline, assign_id, max_round)
..
def self.deadline_sort(due_dates)
<pre>

New Code:
<pre>
def self.current(due_dates)
..
def self.teammate_review_allowed?(student)
..
def self.set_due_date(duedate, deadline, assign_id, max_round)
..
def self.sort_deadlines(due_dates)
<pre>

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

Old Code:
<pre>
def self.current(due_dates)
# Get the current due date from list of due dates
due_dates.each do |due_date|
if due_date.due_at > Time.now
current_due_date = due_date
return current_due_date
end
end
# in case current due date not found
nil
end
..
<pre>

<pre>

def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
due_date &&
(due_date.teammate_review_allowed_id == 3 ||
due_date.teammate_review_allowed_id == 2) # late(2) or yes(3)
end
..
<pre>

<pre>
def self.copy(old_assignment_id, new_assignment_id)
duedates = where(parent_id: old_assignment_id)
duedates.each do |orig_due_date|
..
end
end
..
<pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| due_date.deadline_type_id != 1 && due_date.deadline_type_id != 2 }
..
end
<pre>

New Code:
<pre>
def self.current(due_dates)
due_dates.detect { |due_date| due_date.due_at > Time.now }
end
..
<pre>

<pre>
def self.teammate_review_allowed?(student)
# time when teammate review is allowed
due_date = current(student.assignment.due_dates)
student.assignment.find_current_stage == 'Finished' ||
(due_date && [2, 3].include?(due_date.teammate_review_allowed_id))
end
..
<pre>

<pre>
def self.copy(old_assignment_id, new_assignment_id)
where(parent_id: old_assignment_id).each do |orig_due_date|
..
end
end
..
<pre>

<pre>
def self.done_in_assignment_round(assignment_id, response)
..
due_dates.reject { |due_date| ![1, 2].include?(due_date.deadline_type_id) }
..
end

<pre>

=== Utilized Rails built-in APIs for tasks such as validation, scoping, and database access ===

[[File:DueDateRails1.png|1000px|thumb|none|]]

[[File:DueDateRails2.png|1000px|thumb|none|]]

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

[[File:DueDateOverride1.png|1000px|thumb|none|]]

[[File:DueDateOverride2.png|1000px|thumb|none|]]

[[File:DueDateOverride3.png|1000px|thumb|none|]]

== Test Plan ==

All the previous test cases pass in the new implementation of the system.
The following outlines the NEW scenario and cases to be tested for the <=> functionality within the system:

=== Sorting Due Dates ===
* Scenario: Verify that due dates are sorted in the correct order.
* Edge Case: Include due dates with identical timestamps to assess the stability of the sorting algorithm.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-24T20:22:52Z

Dukolhat:

==E2418. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Utilized Rails built-in APIs for tasks such as validation, scoping, and database access.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

OLD:
<pre>
def self.current_due_date(due_dates)
..
def self.teammate_review_allowed(student)
..
def self.set_duedate(duedate, deadline, assign_id, max_round)
..
def self.deadline_sort(due_dates)
<pre>

[[File:DueDateRename1.png|1000px|thumb|none|]]

[[File:DueDateRename2.png|1000px|thumb|none|]]

[[File:DueDateRename3.png|1000px|thumb|none|]]

[[File:DueDateRename4.png|1000px|thumb|none|]]

[[File:DueDateRename5.png|1000px|thumb|none|]]

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

[[File:DueDateRuby1.png|1000px|thumb|none|]]

[[File:DueDateRuby2.png|1000px|thumb|none|]]

[[File:DueDateRuby3.png|1000px|thumb|none|]]

[[File:DueDateRuby4.png|1000px|thumb|none|]]

=== Utilized Rails built-in APIs for tasks such as validation, scoping, and database access ===

[[File:DueDateRails1.png|1000px|thumb|none|]]

[[File:DueDateRails2.png|1000px|thumb|none|]]

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

[[File:DueDateOverride1.png|1000px|thumb|none|]]

[[File:DueDateOverride2.png|1000px|thumb|none|]]

[[File:DueDateOverride3.png|1000px|thumb|none|]]

== Test Plan ==

All the previous test cases pass in the new implementation of the system.
The following outlines the NEW scenario and cases to be tested for the <=> functionality within the system:

=== Sorting Due Dates ===
* Scenario: Verify that due dates are sorted in the correct order.
* Edge Case: Include due dates with identical timestamps to assess the stability of the sorting algorithm.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-23T22:31:55Z

Dukolhat:

==E2418. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Utilized Rails built-in APIs for tasks such as validation, scoping, and database access.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

[[File:DueDateRename1.png|1000px|thumb|none|]]

[[File:DueDateRename2.png|1000px|thumb|none|]]

[[File:DueDateRename3.png|1000px|thumb|none|]]

[[File:DueDateRename4.png|1000px|thumb|none|]]

[[File:DueDateRename5.png|1000px|thumb|none|]]

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

[[File:DueDateRuby1.png|1000px|thumb|none|]]

[[File:DueDateRuby2.png|1000px|thumb|none|]]

[[File:DueDateRuby3.png|1000px|thumb|none|]]

[[File:DueDateRuby4.png|1000px|thumb|none|]]

=== Utilized Rails built-in APIs for tasks such as validation, scoping, and database access ===

[[File:DueDateRails1.png|1000px|thumb|none|]]

[[File:DueDateRails2.png|1000px|thumb|none|]]

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

[[File:DueDateOverride1.png|1000px|thumb|none|]]

[[File:DueDateOverride2.png|1000px|thumb|none|]]

[[File:DueDateOverride3.png|1000px|thumb|none|]]

== Test Plan ==

All the previous test cases pass in the new implementation of the system.
The following outlines the NEW scenario and cases to be tested for the <=> functionality within the system:

=== Sorting Due Dates ===
* Scenario: Verify that due dates are sorted in the correct order.
* Edge Case: Include due dates with identical timestamps to assess the stability of the sorting algorithm.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-23T22:22:34Z

Dukolhat:

==E2368. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Utilized Rails built-in APIs for tasks such as validation, scoping, and database access.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

[[File:DueDateRename1.png|1000px|thumb|none|]]

[[File:DueDateRename2.png|1000px|thumb|none|]]

[[File:DueDateRename3.png|1000px|thumb|none|]]

[[File:DueDateRename4.png|1000px|thumb|none|]]

[[File:DueDateRename5.png|1000px|thumb|none|]]

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

[[File:DueDateRuby1.png|1000px|thumb|none|]]

[[File:DueDateRuby2.png|1000px|thumb|none|]]

[[File:DueDateRuby3.png|1000px|thumb|none|]]

[[File:DueDateRuby4.png|1000px|thumb|none|]]

=== Utilized Rails built-in APIs for tasks such as validation, scoping, and database access ===

[[File:DueDateRails1.png|1000px|thumb|none|]]

[[File:DueDateRails2.png|1000px|thumb|none|]]

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

[[File:DueDateOverride1.png|1000px|thumb|none|]]

[[File:DueDateOverride2.png|1000px|thumb|none|]]

[[File:DueDateOverride3.png|1000px|thumb|none|]]

== Test Plan ==

All the previous test cases pass in the new implementation of the system.
The following outlines the NEW scenario and cases to be tested for the <=> functionality within the system:

=== Sorting Due Dates ===
* Scenario: Verify that due dates are sorted in the correct order.
* Edge Case: Include due dates with identical timestamps to assess the stability of the sorting algorithm.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-23T22:18:16Z

Dukolhat:

==E2368. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Utilized Rails built-in APIs for tasks such as validation, scoping, and database access.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

[[File:DueDateRename1.png|1000px|thumb|none|]]

[[File:DueDateRename2.png|1000px|thumb|none|]]

[[File:DueDateRename3.png|1000px|thumb|none|]]

[[File:DueDateRename4.png|1000px|thumb|none|]]

[[File:DueDateRename5.png|1000px|thumb|none|]]

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

[[File:DueDateRuby1.png|1000px|thumb|none|]]

[[File:DueDateRuby2.png|1000px|thumb|none|]]

[[File:DueDateRuby3.png|1000px|thumb|none|]]

[[File:DueDateRuby4.png|1000px|thumb|none|]]

=== Utilized Rails built-in APIs for tasks such as validation, scoping, and database access ===

[[File:DueDateRails1.png|1000px|thumb|none|]]

[[File:DueDateRails2.png|1000px|thumb|none|]]

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

[[File:DueDateOverride1.png|1000px|thumb|none|]]

[[File:DueDateOverride2.png|1000px|thumb|none|]]

[[File:DueDateOverride3.png|1000px|thumb|none|]]

== Test Plan for DueDateHelper Specs ==

The following outlines the scenarios and cases to be tested for the DueDateHelper functionality within the system.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-23T22:17:05Z

Dukolhat:

==E2368. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Utilized Rails built-in APIs for tasks such as validation, scoping, and database access.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

[[File:DueDateRename1.png|1000px|thumb|none|]]

[[File:DueDateRename2.png|1000px|thumb|none|]]

[[File:DueDateRename3.png|1000px|thumb|none|]]

[[File:DueDateRename4.png|1000px|thumb|none|]]

[[File:DueDateRename5.png|1000px|thumb|none|]]

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

[[File:DueDateRuby1.png|1000px|thumb|none|]]

[[File:DueDateRuby2.png|1000px|thumb|none|]]

[[File:DueDateRuby3.png|1000px|thumb|none|]]

[[File:DueDateRuby4.png|1000px|thumb|none|]]

=== Utilized Rails built-in APIs for tasks such as validation, scoping, and database access ===

[[File:DueDateRails1.png|1000px|thumb|none|]]

[[File:DueDateRails2.png|1000px|thumb|none|]]

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

[[File:DueDateOverride1.png|1000px|thumb|none|]]

[[File:DueDateOverride2.png|1000px|thumb|none|]]

[[File:DueDateOverride3.png|1000px|thumb|none|]]

== Test Plan for DueDateHelper Specs ==

The following outlines the scenarios and cases to be tested for the DueDateHelper functionality within the system.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

File:DueDateRails2.png

2024-03-23T22:16:51Z

Dukolhat:

File:DueDateRails1.png

2024-03-23T22:16:39Z

Dukolhat:

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-23T22:12:53Z

Dukolhat:

==E2368. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
* Overrode the comparator operator for the DueDate class and replace the `deadline_sort` class method.
* Conducted code smell checks using Code Climate

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

[[File:DueDateRename1.png|1000px|thumb|none|]]

[[File:DueDateRename2.png|1000px|thumb|none|]]

[[File:DueDateRename3.png|1000px|thumb|none|]]

[[File:DueDateRename4.png|1000px|thumb|none|]]

[[File:DueDateRename5.png|1000px|thumb|none|]]

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

[[File:DueDateRuby1.png|1000px|thumb|none|]]

[[File:DueDateRuby2.png|1000px|thumb|none|]]

[[File:DueDateRuby3.png|1000px|thumb|none|]]

[[File:DueDateRuby4.png|1000px|thumb|none|]]

=== Overrode the comparator operator for the DueDate class and replaced the `deadline_sort` class method ===
* '''Problem''': Existing code had a dedicated method for sorting due dates, which violated Ruby conventions.
* '''Solution''': Overrode the <=> operator and defined a new function for sorting due_dates and called that instead.

[[File:DueDateOverride1.png|1000px|thumb|none|]]

[[File:DueDateOverride2.png|1000px|thumb|none|]]

[[File:DueDateOverride3.png|1000px|thumb|none|]]

== Test Plan for DueDateHelper Specs ==

The following outlines the scenarios and cases to be tested for the DueDateHelper functionality within the system.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

File:DueDateOverride3.png

2024-03-23T22:12:27Z

Dukolhat:

File:DueDateOverride2.png

2024-03-23T22:12:15Z

Dukolhat:

File:DueDateOverride1.png

2024-03-23T22:12:03Z

Dukolhat:

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-23T21:51:36Z

Dukolhat:

==E2368. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
*
*

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

[[File:DueDateRename1.png|1000px|thumb|none|]]

[[File:DueDateRename2.png|1000px|thumb|none|]]

[[File:DueDateRename3.png|1000px|thumb|none|]]

[[File:DueDateRename4.png|1000px|thumb|none|]]

[[File:DueDateRename5.png|1000px|thumb|none|]]

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

[[File:DueDateRuby1.png|1000px|thumb|none|]]

[[File:DueDateRuby2.png|1000px|thumb|none|]]

[[File:DueDateRuby3.png|1000px|thumb|none|]]

[[File:DueDateRuby4.png|1000px|thumb|none|]]

== Test Plan for DueDateHelper Specs ==

The following outlines the scenarios and cases to be tested for the DueDateHelper functionality within the system.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

CSC/ECE 517 Spring 2024 - E2418. Reimplement of due date.rb

2024-03-23T21:50:59Z

Dukolhat:

==E2368. Reimplement due_date.rb==

This page provides a description of the Expertiza based OSS project.

__TOC__

===About Expertiza===

[http://expertiza.ncsu.edu/ Expertiza] is an open source project based on [http://rubyonrails.org/ Ruby on Rails] framework. Expertiza allows the instructor to create new assignments and customize new or existing assignments. It also allows the instructor to create a list of topics the students can sign up for. Students can form teams in Expertiza to work on various projects and assignments. Students can also peer review other students' submissions. Expertiza supports submission across various document types, including the URLs and wiki pages.

== Project Changes ==
In this project, the following specific changes were implemented:

* Renamed methods and variables to accurately describe their responsibilities.
* Refactored each method to comply with DRY (Don't Repeat Yourself), SRP (Single Responsibility Principle), and other Ruby conventions.
*
*

These changes aimed to enhance code quality, organization, and adherence to best practices in the Expertiza project.

== Current Implementation of DueDate Class ==

The current implementation of the `DueDate` class can be summarized in a few key points:

=== Validation of Due Date Format ===
The class includes a validation method due_at_is_valid_datetime to ensure that the due date is in a valid datetime format. It checks if the due_at attribute is present and attempts to parse it using DateTime.strptime. If parsing fails and raises an ArgumentError, the method adds an error to the due_at attribute indicating that it must be a valid datetime.

=== Default Permission Handling ===
The class provides a default_permission method, which retrieves the default permission for a given deadline type and permission type. It accesses the DEFAULT_PERMISSION constant defined in the DeadlineRight module and returns the corresponding permission value.

=== Current Due Date Retrieval ===
It offers functionality through the current_due_date method to retrieve the current due date from a list of due dates. This method iterates over the provided due dates and checks if any due date lies in the future compared to the current time. It returns the first future due date encountered, indicating the current due date.

=== Flag Setting ===
It includes a set_flag method to set the flag attribute to true for a DueDate instance. This method updates the flag attribute and saves the record to the database.

=== Due Date Copying ===
The class implements functionality to copy due dates from one assignment to another using the copy method. It retrieves due dates associated with a given assignment ID, duplicates each due date record, assigns the new parent ID, and saves the duplicated records for the new assignment.

=== Due Date Setting ===
Provides a set_duedate method to set due dates for assignments with specified parameters. It creates a new DueDate instance with the provided parameters, including the deadline type, parent assignment ID, round, and saves the record to the database.

===Sorting of Due Dates ===
Implements a method deadline_sort to sort due dates based on the due date attribute. This method sorts the provided list of due dates in ascending order of their due dates, ensuring that due dates without due_at values are placed at the end.

=== Assignment Round Calculation ===
Calculates the round of the response within an assignment based on due dates using the done_in_assignment_round method. It retrieves due dates associated with the given assignment ID, sorts them by due date, and iterates over them to determine the round based on the response's creation time.

=== Next Due Date Retrieval ===
Offers functionality through the get_next_due_date method to retrieve the next due date for an assignment or topic. Depending on whether the assignment has staggered deadlines, it queries either AssignmentDueDate or TopicDueDate records and returns the next due date after the current time.

The DueDate class in the Expertiza project serves as a pivotal component responsible for managing, validating, and retrieving due dates associated with assignments, encompassing functionalities such as validation of datetime formats, permission handling, and determining the current and next due dates for assignments and topics.

== Improvements in the New Implementation of DueDate Class ==

=== Renamed methods to describe their responsibility ===
* '''Problem''': Method names might not have accurately described their functionality, leading to confusion for developers.
* '''Solution''': Method renaming with descriptive names clarified their purpose, improving code readability and comprehension for developers to understand method functionalities without deep code inspection.

[[File:DueDateRename1.png|1000px|thumb|none|]]

[[File:DueDateRename2.png|1000px|thumb|none|]]

[[File:DueDateRename3.png|1000px|thumb|none|]]

[[File:DueDateRename4.png|1000px|thumb|none|]]

[[File:DueDateRename5.png|1000px|thumb|none|]]

=== Refactored each method according to DRY, SRP, and other Ruby conventions ===
* '''Problem''': Methods were potentially repetitive, non-optimized, or didn't adhere to best practices, causing inefficiencies and confusion.
* '''Solution''': Method refactoring according to DRY, SRP, and Ruby conventions optimized the code for clarity, efficiency, and maintainability, ensuring each method has a clear purpose and follows standard practices.

[[File:DueDateRuby1.png|1000px|thumb|none|]]

[[File:DueDateRuby2.png|1000px|thumb|none|]]

[[File:DueDateRuby3.png|1000px|thumb|none|]]

[[File:DueDateRuby4.png|1000px|thumb|none|]]

[[File:DueDateRuby5.png|1000px|thumb|none|]]

== Test Plan for DueDateHelper Specs ==

The following outlines the scenarios and cases to be tested for the DueDateHelper functionality within the system.

==References==

#[https://github.com/expertiza/expertiza Expertiza on GitHub]
#[https://github.com/Dhruv-Kolhatkar/expertiza GitHub Project Repository Fork]
#[http://expertiza.ncsu.edu/ The live Expertiza website]
#[http://wikis.lib.ncsu.edu/index.php/Expertiza Expertiza project documentation wiki]
#[https://relishapp.com/rspec Rspec Documentation]
#Clean Code: A handbook of agile software craftsmanship. Author: Robert C Martin

File:DueDateRuby2.png

2024-03-23T21:50:17Z

Dukolhat:

File:DueDateRuby4.png

2024-03-23T21:49:59Z

Dukolhat:

File:DueDateRuby3.png

2024-03-23T21:49:45Z

Dukolhat:

File:DueDateRuby1.png

2024-03-23T21:48:10Z

Dukolhat: