CSC/ECE 517 Spring 2023 - E2316. Reimplement sign up sheet controller.rb

Expertiza Overview

Expertiza is a comprehensive and open-source assignment and project management portal that supports collaborative learning and feedback between instructors and students. Developed on the Ruby on Rails framework, this web application is designed to provide a range of features and capabilities to create and customize assignments, quizzes, topics, and assignment groups. Expertiza also enables students to form teams and work together on various projects while providing a complete mechanism for peer review and feedback on other groups and teammates' submissions. Developed and maintained by students and faculty at NC State, Expertiza is a versatile and well-developed application that can handle all types of assignments, and its full functionality can be explored in the Expertiza wiki.

Project Overview

The signup_sheet_controller in expertiza is responsible for managing the signup sheet for an assignment. The controller includes functions to add, edit, and delete topics for the assignment, as well as perform team and deadline management functions. One important feature of the signup sheet is the ability for teams to sign up for topics. The controller includes methods to handle this functionality, including checking if there are available slots for a particular topic, adding the team to the waitlist if there are no available slots, and updating the signup sheet accordingly. In addition to signing up for topics, teams also have the ability to drop a topic. If a team drops a topic and there are teams on the waitlist for that topic, the first team on the waitlist (based on the creation date) will be automatically signed up for the topic. The controller includes methods to populate the objects needed for the signup sheet for a particular assignment. This could include retrieving information about the assignment, the topics, and the teams that have signed up for each topic. Most importantly, only instructors can create, update and delete the topics.

Problem Statement

Our task is to reimplement these major functionalities for signing up topics and teams in Rails API which will then be consumed by a React based frontend. The current business logic in the controller is complex and involves multiple things in a single function which contradicts Single-Responsibility principle. In this project, in the first phase, we decided to work on simplifying the logic and extracting only the required functionalities which are being currently used extensively.

Design Decisions

1. Split the signup_sheet controller into signup_teams controller and signup_topics controller.

Rationale

Splitting a monolithic controller into multiple controllers can help to isolate specific areas of functionality. This can make the codebase easier to navigate and modify in the future. Smaller controllers can often lead to better performance, especially in cases where the original monolithic controller is handling too much traffic or too many requests at once. Splitting the controller into smaller, more focused controllers can help to distribute traffic more evenly and improve overall application performance. By breaking down a monolithic controller into smaller controllers, we can create more focused unit tests that can help to catch bugs and improve overall code quality. When multiple developers are working on a project, it can be easier to collaborate when the codebase is split into smaller, more focused controllers.

Work Done

The signup_topics controller deals with the basic CRUD operations. It allows only the instructor to create, read, update and delete the topics for a particular assignment.

method name	description
index	returns all the topics
create	creates the new topic
update	updates the topic with newly provided params
destroy	destroys the topic info for given topic id

Additionally, it supports the following methods from the original implementation to delete multiple topics at once.

method name	description
delete_all_selected_topics	allows the instructor to delete all the selected topics from the list
delete_all_topics_for_assignment	allows the instructor to delete all the topics for the given assignment

Some more helper methods

method name	description
load_all_selected_topics	populates only the selected topics. It works as a helper function for delete_all_selected_topics. Optionally, the methods can be accessed using its dedicated end point.
set_sign_up_topic	loads the signup topic for given topic id.
sign_up_topic_params	decides the required parameters for a signup topic

Note: signup_team_controlelr will be implemented in the next phase.

---

2. Move business logic from controller to model.

Rationale

The Model-View-Controller (MVC) design pattern separates the application into three main components: models, views, and controllers. The controller's job is to handle user input and interaction, while the model's job is to represent the data and perform operations on it. By moving the business logic to the models, we can achieve a better separation of concerns and keep the controller's responsibility limited to handling user input. Moving the business logic to the models can also improve the scalability of the application. By separating the business logic from the controller, we can avoid having a monolithic controller that performs many different operations (which was the case for earlier expertiza implementation). This can help to improve performance and make the application more scalable.

Work Done
Since this project involves reimplementing the controller from the ground up, all the complex business logic that was making the signup sheet controller bulkier has been removed. In this first phase, the controller has minimum viable methods to make the core functionalities of the signup sheet like CRUD operation on the topics and other additional methods required by the instructor. In the next, phase the additional required business logic will be implemented in the respective models as per the additional requirements.

Changes planned for next phase

• list method in the original implementation is too crowded with populating the required data from the model and also doing some checks on topic deadlines. Those checks can be moved to the model which will make the list method a Single Responsibility method which populates the required topic details.
• save_topic_deadlines is one of the gigantic method doing lot of things related to setting deadlines which should be done thorugh the deadline models

---

3. Delete irrelevant/redundant methods from the controller.

Rationale

Controllers are responsible for handling incoming requests and managing the flow of data between the model and the view. If a controller has methods that are not being used or are redundant, it can make the codebase harder to navigate and more difficult to maintain. Deleting unused or redundant methods from a controller can help to simplify the codebase and reduce the risk of errors. It can also make it easier for other developers to understand the code and make changes to it in the future.

Work Done
There are currently so many methods in the signup_sheet_controller which are absolute and are not being used for many years. So, we decide to remove those methods and cleanup up the controllers. Since, this is a reimplementation of the controller, we didn't include those absolute functions in our newer implementation.

method removed	reason
ad_info	the method was earlier used for broadcasting an ad for team member which is not being done for quite a while now.
set_priority	it was used as helper function for bidding on the topics which is not being used currently.
list	some part of this method which deals with the bidding logic will be removed.

---

Testing

For testing the functionality of the controller the swagger API has been used. The tests covered are to perform create, read, update and delete operations as a part of the sign up topic controller. Other tests covered are to list all topics, delete all selected topics and delete all topics. Testing each functionality - The tests require injection of data into the data base and rswag spec running 1. Setting up rswag - the following command needs to be run after setting up the project on a local machine - rails rswag:specs:swaggerize 2. Injecting dummy data into the database - The sign up topic table and the assignment table needs dummy entries. The easiest way to do the same is to load the project and add them manually. 3. Once the rswag command from step 1 has been run, the rswag testing environment can be loaded using the local server by the following link - <host-name>/api-docs.

TEST 1 Create topic - In the rswag API the test can be conducted, using the assignment ID one can create a new topic, the topic name and assignment ID is a unique combination and the test fails if the same combination is used for testing.

Relevant Links

Github Repository: https://github.com/colin-odowd/expertiza Pull Request: https://github.com/expertiza/expertiza/pull/2476 VCL Server: http://152.7.178.100:8080/ Video: https://youtu.be/Hcqr4uLzU38