CSC/ECE 517 Fall 2024 - E2468. Reimplement due date

From Expertiza_Wiki
Jump to navigation Jump to search

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

Team

Mentor: Dr. Ed Gehringer - efg@ncsu.edu

  • Akul Devali - devali@ncsu.edu
  • Pete Chopelas - pechopel@ncsu.edu
  • Snehil Behar - sbehar@ncsu.edu