octetful / karmayoga Goto Github PK

Problem Statement

Currently the app lacks support to integrate with Google Calendar to pull data from there.

Expected Outcomes

• Add an adapter with support for Google Calendar integration.

Problem Statement

Currently there is no support to generate static documenation site for the project.

Expected Outcomes

• Mkdocs configuration yaml is added to the project.
• Mkdocs site base structure is added to the project.

Problem Statement

There's a bit of redundancy in the code that also doesn't read very well.

Expected Outcomes

• Redundant method names are simplified in base model classes - TimeSlot and Schedule.
• Redundant implementations are removed - SampleAllocator.

The goal is to be able to have multiple varying implementations of the Allocator interface in the future with the user being able to select any given algorithm and even configuration. Hence a Factory for Allocator needs to be built.

Requirements

• Given an AllocatorSpec, return an AllocatorImpl.

• Tasks with deadlines get highest priority.
• Tasks with lower estimates are favoured next.
• Tasks with same estimates are sorted by priority next.

Problem Statement

Currently the domain has an Allocator that expects a sequence of TimeSlot, but lacks a mechanism to find empty time slots from a sequence Schedule or Event objects.

Expected Outcome

• Given a sequence of Event or Schedule objects, and a valid working hours TimeSlot, this new service should be able to find any free or empty slots between these events.
• In case no free slots are available in between the given list of Schedule or Event objects, it should return the earliest available TimeSlot after all of them.

Create a full fledged implementation of the Allocator interface that would take into account Task estimate, deadline and priority and uses the 80-20 principle to allocate the tasks.

Requirements

• Tasks with extremely low estimates should be allocated first.
• Tasks with same estimates should be allocated based on priority such that a task with higher priority gets precedence.
• Tasks with deadline should get highest precedence. Given two tasks, if one has a nearer deadline, it should get allocated first.

A hexagonal architecture design would enable us to easily evolve the project and integrate with other components.

Expected Outcomes:

• Project has submodule core
• Project has additional submodule for rest api.

Problem Statement

Currently the domain model is devoid of any representation of regular calendar events which may or may not have associated tasks, for example appointments.

Expected Outcome

• Add a construct to model task-less events.

Problem Statement

Currently the application lacks any implementation of the Repositories for Tasks or Schedules.

Expected Outcomes

• An in-memory implementation of TaskRepository is created.
• An in-memory implementation of ScheduleRepository is created.

Problem Statement

Karmayoga, starting off as a library, lacks some basic application layer components such as repositories, command bus, command handlers, etc.

Expected Outcomes

• Add repositories for basic entities.
• Add basic CRUD commands.
• Add a CommandBus.
• Add CommandHandler interface.

Problem Statement

Add springboot adapter for REST API support.

Expected Outcomes

• Add a springboot adapter to expose a REST API.

Problem Statement

Currently there are no ADRs describing the hexagonal architecture choice that provides the foundation of this project.

Expected Outcomes

• Create an ADR explaining the choice of hexagonal architecture.
• Explain future adapter possibilities as an outcome.

Problem Statement

The current domain model lacks any ownership information or mechanism. In a multiuser system, a sense of ownership for all business aggregates is essential.

Expected Outcome

• All Domain aggregates such as Task and Schedule are attributed with ownership information.
• Future scenarios such as sharing of certain aggregates are taken into consideration in the ownership model.

Expected Outcomes:

• README contains notes on architectural changes (hexagonal design).
• README contains notes on shift from library to selfhosted backend project.

Because the current SimpleFirstFit algorithm only checks if a task fits a slot before trying to create a schedule, but the Schedule.createSchedule method validates with the deadline field as well.

Problem Statement

Currently the site only has the build status badge.

Expected Outcomes

• Update build status to shields.io badge.
• Add license badge.
• Add code quality badge.

Problem Statement

Currently the application lacks any rest api endpoint for the defined resources.

Expected Outcomes

• GET, POST, and DELETE endpoints are created for /tasks.
• GET, POST, and DELETE endpoints are created for /users.
• GET,POST, and DELETE endpoints are created for /schedules.

Add support for Architectural Decision Records to the project.