Skip to content

Instantly share code, notes, and snippets.

@Randy1Burrell

Randy1Burrell/Trello_Clone_Engineer_Plan.md

Last active August 16, 2020 20:55
Show Gist options
  • Save Randy1Burrell/3e84e86e631216bb9e4da1c7675bc12e to your computer and use it in GitHub Desktop.
Save Randy1Burrell/3e84e86e631216bb9e4da1c7675bc12e to your computer and use it in GitHub Desktop.
Download ZIP
Raw
Trello_Clone_Engineer_Plan.md

Table of Contents

  1. Questions
  2. Technology Stack
  3. Database Models
  4. API Endpoints/Routes
  5. Tasks to be done
  6. Completion date

Questions

Since the project guideline states that I have "full autonomy to make all technology decisions", I will make some assumptions based on questions that came to me while I was planning this project. Please note: usually I would not make assumptions, but direct all questions I have to the client(s)/stakeholder(s), but in the interest of time and for the purposes of showing how I think, I will make key assumptions based on questions I find have been left unanswered in the specification document.

  1. What should happen to TODOs that are completed and how would users view them? I will assume that TODOs that have been completed would have its own column called Done that is visible when a user toggles it.
  2. What would happen when a TODO is completed without being scheduled (ex. task in the Backlog)? In this case I will assume that TODOs that are done without a schedule should be moved to a completed list and not shown in the Backlog column.
  3. What would happen to tasks that have missed their scheduled deadlines? I will assume that these tasks should still show up in the scheduled list. However, should they have a different color, should I update their priority to the highest priority or maybe show the task in the Today column until the user cancels/completes the task?
    1. Assuming that I choose to give them a different color, I cannot use red to show danger because it is already being used to show priority of tasks.
    2. I cannot update their priority to the highest priority because a user may not necessarily think of a task as high priority even if the deadline has passed.
    3. Assuming that management of tasks for each user is priority and because a user might focus on the Today column for TODOs to be completed today, I will show each tasks that was not completed and have passed their completion date in the Today column under the sub-heading "overdue" at the top.
  4. Which brings me to the next question about cancelled tasks. What would happen to them? Is there a place to show a user's log history? I will assume that there will be a version 2, so this can be included later.
  5. What would happen if a user wants to delete a task? I will assume that users should be able to edit and delete tasks, so I will make each tasks editable and place a delete and edit icon at the end of each tasks.
  6. Do I need to build a Back-end for this project or will I be given an API to integrate with the Front-end? Assuming that I will not be given an API to integrate with because the specification said that I should assume that "I am the only engineer working on the project", I will make this a part of my project plan.
  7. Will I have to authenticate users for this TODO dashboard? The specification did not spell this out but if you are going to have many users then this is a must.
    1. Should I allow social logins/sign-up? I will skip social sign-up/logins for the time being because the specification did not state that this is a requirement. Let's do this the good old fashion way before FB and leave social logins for version 2.
  8. Can users reference one task from another? For the purpose of simplicity, I think I should leave this out until version 2. :-)
  9. Do I need to store the progression history of each tasks? Ex. when a user move a task from Backlog to Today or from Today back to Backlog. For simplicity reasons I will leave this for version 2. :-)

Technology Stack

The following table lists the languages and frameworks that I will use in this project's technology stack and the reasons. Given the interest of time and for the purpose of assuming that only one developer will be on the project, there will only be one language used in this project for simplicity reasons.

Technology Reasons
Hapi.js Provides flexibility to quickly build and test the API.
MongoDB Great NoSql database that will make it easy to develop a flexible
  schema and store data without the added complexity of dealing
  with SQL join statements which are not necessary for this type of
  project.
React.js This will allow for the UI to update easily each time a user
  makes change to a task. Ex. user drags task from Backlog to
  Today column.
Node.js This is the language all the current technologies in the stack
  that I am proposing have been built in, but I will add TypeScript
  on top of this to help make the application much more stable and
  easily modifiable in the future.

Database Models

  1. Users
    • Id number - this should be an auto increasing number for each users.
    • first name - does not need to be unique.
    • last name - does not need to be unique.
    • email - this must be an email unique to the user.
    • password - can be any string of characters that are no shorter than 8 characters and no longer than 256 characters.
    • salt - salt used in hashing password.
    • TODOs - Remember one user can have many TODOs but one TODO can only be assigned to one user.
  2. Tasks
    • Id number - this should be an auto increasing number for each tasks.
    • title - this should be a string of characters. (I think 100 characters maximum should be good).
    • description - optional text that will be used to describe the task to be completed.
    • taskpriority - store this as a number between 1-3 inclusive.
    • taskduedate - date datatype!
    • taskscheduleddate - date datatype!
    • currentstatus - this will store the deck/column that the task have been last placed in. Given that there will only be about 5 columns and Today & Tomorrow tasks will be scheduled tasks anyway, I will store currentstatus as a number from 1-3 where:
      1. Is Backlog
      2. Is Scheduled
      3. Is Done

Here is a tabular form of the models.

Model Attributes Data Type
`User` id   number
  firstname string
  lastname string
  email string/email
  password bytes/hashed string
  salt bytes
  TODOS Array of Tasks
  createdOn date
     
`Tasks` id number
  title string
  description string
  taskpriority number
  taskduedate date
  taskscheduleddate date
  currentstatus number
  createdOn date

API Endpoints/Routes

The following table lists a set of routes that the API will use:

API Route Type Auth Logic Return
/api/createaccount POST NO Accepts a user's credentials in the body of the request, 201 if success or 400/401
      hashes the password and stores it with the rest of the user's depending on the error
      details in the database user table.  
/api/login POST NO Accepts a user's credentials in the body of the requests, 200 and json web token on
      checks to see if it is a valid user success or 404/401
        otherwise
         
/api/{userid}/logout POST YES Logs out the user and invalidates their token 200 or 404/401 otherwise
/api/{userid}/task POST YES Creates a task for the userid from the data contained in 201 and created task on
      the body of the request success or 400/401
        otherwise
         
/api/{userid}/task GET YES Retrieves all tasks for the current userid based on a query 200 and tasks on success
      parameter called type. The allowed values are: or 404/401/500 depending
      1. Done on the error
      2. Scheduled - all scheduled tasks that are not done, their  
      due/scheduled date have not passed, and they are not scheduled  
      for today/tomorrow.  
      3. Today  
      4. Tomorrow  
      5. Backlog  
/api/{userid}/task/{taskid} GET YES Retrieve a single task with a certain taskid 200 and task on success
        or 404/401 depending
        on the error
/api/{userid}/task/{taskid} PUT YES Updates task with taskid with the data contained 200 and task updated on
      in the body of the request success or 404/401
        depending on the error
/api/{userid}/task/{taskid} DELETE YES Deletes task with taskid 200 on success or 404/401
        depending on the error
         

Tasks to be done

  • Create database and the database schema and tables to support all users and TODOs. Please see 3 for details on how models should look and Questions for assumptions made. Estimated time: 30 minutes
  • Create API endpoints that will be used to fulfil CRUD requests for users TODOs and basic validation of inputs, user authentications and authorizations. Please see Questions for assumptions made. Estimated time: 5 hours.
  • Write tests for API endpoints to test the different routes for errors. Estimated time: 10 hours
  • Design the UI and UX to ensure seamless usage for users and a beautiful and attractive user interface. This will take some amount of time to choose color scheme, theme, etc. but some of the requirements for color was given within the specification. Estimated time: 8 hours
  • Write documentation and descriptive pseudo-code for the TODO app components. Estimated time: 8 hours
  • Write unit and integration tests (leave integration tests until after the components have been integrated with each other) for each component and the API. Estimated time: 2 days
  • Build the UI that the user will interact with. It will function in the following way:

    • A HeaderBarComponent (only shows up on the tasks page) that will contain:

      • Logo of the site
      • A log out button that when clicked will send a request to the api route /api/{userid}/logout to invalidate the user session, then on success, redirects the user to the login page. Estimated time: 30 minutes.

    • A TodoComponent that can be dragged that accepts the following props:

      1. priority - a number that will determine the color a task is displayed in:
        1. Is Red
        2. Is Orange
        3. Is Blue
        4. Is Light Grey to show task is complete.
      2. title - a string that will be displayed as the identifier of the task
      3. description - a detailed description of the task to be completed. This text will only show when a user select a task

      Estimated time: 1 hour

    • AddTodoComponent that displays a text field and a button that when clicked, takes the current texts in the text field, makes an API request to create the task, then on success, appends the task to the task list array through invoking a function called addtask passed by the parent component. The addtask function will accept as argument a task object. Estimated time: 1 hour

    • A ColumnComponent that can be used to display the TODOs. This component will function as follows:

      1. Will accept the following props:
        1. date - Either a date object or a function that will be used to set the taskduedate and taskscheduleddate on each task. This is not a required prop and will default to none/null/undefined.
        2. tasklist - this is the list of tasks to be displayed by the component.
        3. title - this title will be used to determine the display name of the component.
        4. currentstate - A number used to update the state of any object that have been dragged onto this component.
      2. Sorts tasks passed to it based on date and time created
      3. Senses when a TodoComponent has been dragged to it and updates the state of this dragged object's currentstatus to the currentstatus from its props variable, then sends a PUT request to /api/{userid}/task/{taskid} to notify the API and updates the changed status of the task.
      4. Display AddTodoComponent at the top of the component.

      Estimated time: 6 hours

    • DisplayColumns component that makes different calls to the /api/{userid}/task API route with different values in the type parameter on each consecutive calls and builds the different task list, then displays four ColumnComponent with the different tasks. These columns are as follows:

      1. Backlog - no date/function will be passed as a prop to this component so all dates for dragged/created items will be undefined.
      2. Today - today's date would be passed so that any item dragged to this component would "automagically" ;-) be set to be completed today.
      3. Tomorrow - Tomorrow's date would be passed so that any todo item dragged to this component would be set to tomorrow's date "automagically" :-D.
      4. Scheduled - date prop will be given a function where this function will be called when an item is dropped/created. When this function is called, a popup date picker will appear so that a user can select two dates which are used to populate the taskduedate and taskscheduleddate fields on the given todo item.

      Estimated time: 3 hours

    • Views for the different pages

      • Login
      • Create Account (Can be same page as login)
      • Tasks

      Estimated time: 3 hours

Completion date

Task Time in hours
API 19
UI 26
Documentation 8
Meetings 1
Pages 3
Contingency 16
Total 73

Time to completion is approximately 11 week days from August 13, 2020. When counting 2 mandatory holidays this would make the estimated time to completion be August 27, 2020. Production ship date would be August 28, 2020. The following is a table showing important dates:

Period Date
Begin August 13, 2020
Complete August 27, 2020
Ship to Production August 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment