CSC/ECE 517 Fall 2024 - E2468. Reimplement due date
About Expertiza
Expertiza is an open-source project built using Ruby on Rails. It provides a platform for instructors and students to manage, submit, and evaluate assignments and projects. Instructors can create, edit, and grade assignments, while students can collaborate in teams, submit their work, and review peers' submissions. Expertiza supports submission across various document types, including URLs and wiki pages.
Issues with previous Functionality
- Outdated Code: The original implementation seems to be very old code that does not utilize features that are standard in current ruby versions. Updating this code improves maintainability and code clarity. A prime example is the use of a flag attribute, which apparently has not been used in nearly a decade.
- Readability: The original due_date.rb had become quite bloated and messy, with overly complex methods that were difficult to read. An example of this is self.get_next_due_date. This could hamper future development as understanding exactly what due dates can and cannot do could become difficult due to unclear code.
- Single-Responsibility Principle Violations: The original implementation violated several SOLID principles, primarily violations around the Single-Responsibility Principle. These issues create difficulty in maintainability as code may need to be updated in multiple places that each do the same thing.
Design Goals
- We had one overarching goal with this reimplementation: clean up the old bloated model. To do so, we broke down functionality into two separate buckets - code that was overly complex and/or wordy, which could be reused after some basic cleanup and simplification; and code that was obsolete and therefore could be removed entirely with the reimplementation
- Some attributes of the old model were determined to not be reused in the new implementation. However, these attributes need to be present for backward compatibility, so we removed any references to them but left their associated column within our table.
Implementation
Reimplemented Methods
DueDate
While most of the methods in the original model were functionally correct, we saw areas of possible improvement both in readability and complexity. We also removed a few methods that were unnecessary after reimplementation.
| Reimplemented method | Description |
|---|---|
| due_at_is_valid_datetime | Simple validation that due_at is a datetime and not some other data type. |
| self.sort_due_dates | Sorts the due dates by earliest to latest. |
| self.fetch_due_dates | Fetches all the due dates for the assignment or topic, then returns the sorted list of due dates. |
| self.any_future_due_dates? | Method that returns a boolean of whether there are any upcoming due dates left in the assignment or topic. |
| self.next_due_date | Calls the fetcher to retrieve all the due dates for an assignment, then returns the next upcoming due date. |
| set | Instance method used to update a due date's deadline type, assignment, and round. |
| copy | Instance method to copy all the due dates from one assignment or topic to another. |
TopicDueDate
| Reimplemented method | Description |
|---|---|
| self.next_due_date | Overloaded super method to first look for any upcoming topic due dates, and return the next one if so. If there are not any, it returns the next due date for the topic's assignment instead. |
Other changes
We did not reimplement these methods as they were unused and therefore obsolete
| Obsolete method | Description |
|---|---|
| self.teammate_review_allowed | Unnecessary method now that teammate_review_allowed is an attr_accessor |
| self.done_in_assignment_round | This determined the round that the due date was used in. Unnecessary as we can just grab the deadline_type_id directly from a due_date instance. |
| set_flag | Simple setter of the flag attribute. Not reimplemented as flag had not been used since 2015 and no one was really sure what it was used for. |
Testing Plan
We primarily tested using automated testing through RSpec. Since due dates are a relatively self-contained structure, RSpec testing was more than sufficient for covering all testing scenarios. Here are some of our test cases:
Relevant Links
- Github Repository: https://github.com/akuldevali/reimplementation-back-end
- Pull Request: https://github.com/expertiza/reimplementation-back-end/pull/129
Team
Mentor: Dr. Ed Gehringer - efg@ncsu.edu
- Akul Devali - devali@ncsu.edu
- Pete Chopelas - pechopel@ncsu.edu
- Snehil Behar - sbehar@ncsu.edu