Code Monkey home page Code Monkey logo

bhelpful / momentmeal Goto Github PK

View Code? Open in Web Editor NEW
13.0 4.0 5.0 63.18 MB

MomentMeal is a marketplace for food and recipes. We help you find and create the best recipes and meal plans for you.

Home Page: https://momentmeal.com/

License: GNU Affero General Public License v3.0

JavaScript 4.14% TypeScript 89.26% CSS 0.89% MDX 5.71%
typescript hacktoberfest meal-management prisma hacktoberfest-accepted clerk contentlayer nextjs prisma-orm stripe

momentmeal's Introduction

momentmeal's People

Contributors

ahashm avatar andreasgdp avatar baremaxx avatar dependabot[bot] avatar imgbot[bot] avatar shikhavani avatar toeffe3 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

momentmeal's Issues

[Story]: Generator for collection

Description

As a developer I would like to be able to create a new collection, so I can quicker get to developing the actual collectionand not write all the boilerplate code.

Acceptance criteria

  • Be able to generate a collection that has a specific configuration matching the project
    • Collection folder with Controller, model, schema and service
    • Collection route w. templated documentation

Comments / questions

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Story]: Path mapping instead of relative paths

Priority

MINOR

Description

As a developer, I would like to worry less about the paths to my imports, so I can more easily create new imports and understand the current imports.

Use path mapping to simplify imports instead of using relative paths

UX

No UX needed.

Acceptance criteria

  • Implement path mapping instead of relative paths

Comments / questions

https://youtu.be/WpgZKBtW_t8

Definition of ready/done (DOR/DOD) [DONT CHANGE THE CONTENT]

Definition of ready

  • DOR

    Description
    - Acceptance criteria written and reviewed by QA, PM and SE
    - Behaviour scenarios written
    - Signed off UX
    - Estimated and appropriately scoped
    

Definition of done

  • DOD

    Description
    - Test complete
        - Merged to master
        - Unit tests on all new code (80% coverage)
        - Integration tests for endpoints / web sockets
        - End-to-end or integration tests verifying acceptance criteria
    - Code complete
        - Peer reviewed (1 person/people)
        - Follows BHelpful code standards / versioning guidelines
        - No commented out code or TODOs
        - TSLint / Sonarqube exceptions have explicit explanations
    - Verified by QA
        - Functionally manually verified on a setup like the actual setup
        - QA verifies test coverage aligns with master test plan
    - Verified by UX and product owner / verified by the team
    - Documentation of tech debt
    - Persistent technical documentation updated / written
        - Ready is updated / written
    

Code of Conduct

  • I agree to follow this project's Code of Conduct

Structure for recipe showcase

Short description of a problem or missing feature

The website is currently missing the recipe showcase underneath the meal plan
image

Description of a possible solution

Add the structure for the recipe showcase.

[Minor]: Implement loading screen/logo

Description

Implement loading screen for when API calls or similar takes long(er) time to execute

UX

CSS background or something maybe an overlay or blurred out background

Acceptance criteria

  • Idea and live test
  • an actual design/implementation

Comments / questions

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Minor]: Create basic Epic issue Form

Description

Create basic Epic issue Form that allows to easily create new epics with the same structure and the Epic label.

Acceptance criteria

  • A basic form that looks something like BHelpful/Mealplanr-api#66
  • All of the issue forms should be looked at and refactored/changed to be simpler and intuitive

Comments / questions

No response

Definition of ready/done (DOR/DOD) [DONT CHANGE THE CONTENT]

Definition of ready

  • DOR

    Description
    - Acceptance criteria written and reviewed by QA, PM and SE
    - Behaviour scenarios written
    - Estimated and appropriately scoped
    

Definition of done

  • DOD

    Description
    - Test complete
        - Merged to master
        - Unit tests on all new code (80% coverage)
        - Integration tests for endpoints / web sockets
    - Code complete
        - Peer reviewed (1 person/people)
        - Follows BHelpful code standards / versioning guidelines
        - No commented out code or TODOs
        - TSLint / SonarCloud exceptions have explicit explanations
    - Verified by QA
        - Functionally manually verified on a setup like the actual setup
        - QA verifies test coverage aligns with master test plan
    - Documentation of tech debt
    - Persistent technical documentation updated / written
        - Ready is updated / written
    

Code of Conduct

  • I agree to follow this project's Code of Conduct

Active recipes in meal plan

Short description of a problem or missing feature

  1. The recipes that is added to the meal plan is somewhat missing images.
  2. The description needs to be cut off a little more before the time in the bottom, as there is not a lot of white space between the description and the time section.
  3. The settings icon needs to give the option when clicked to remove or change to another recipe.

Expected look:
image

Current look:
image

[Epic]: Generators for easy new file creation

Description of task

Add generators to create files and file structures that we use all the time to speed up the development process.

  • Create generators (CLI or generator scripts - could be Yeoman: https://yeoman.io/) that can generate templates for different parts of the project. (Create epics for these changes and estimate them onto the roadmap)
    • For the backend it would make sense to have a generator for creating a new:
      • Middleware
      • Utils
      • Collection
        • Collection folder with Controller, model, schema and service
        • Collection route w. templated documentation
      • Component
      • Reducer
      • Cypress test

Sub tasks

[Story]: Make sure all properties that should not be send out to the user is omitted before returning

Description

As a developer, I would not like to get all values, that should be hidden from the API like a user's password.

Acceptance criteria

  • All routes should return complete objects (no referering id's but all information on collections referenced in another collection)
  • If there is sensitive information in an object, those information should get omitted before returning.

Comments / questions

No response

Definition of ready/done

Definition of ready

  • DOR

    Description
    - Acceptance criteria written and reviewed by QA, PM and SE
    - Behaviour scenarios written
    - Estimated and appropriately scoped
    

Definition of done

  • DOD

    Description
    - Test complete
        - Merged to master
        - Unit tests on all new code (80% coverage)
        - Integration tests for endpoints / web sockets
    - Code complete
        - Peer reviewed (1 person/people)
        - Follows BHelpful code standards / versioning guidelines
        - No commented out code or TODOs
        - TSLint / SonarCloud exceptions have explicit explanations
    - Verified by QA
        - Functionally manually verified on a setup like the actual setup
        - QA verifies test coverage aligns with master test plan
    - Documentation of tech debt
    - Persistent technical documentation updated / written
        - Ready is updated / written
    

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Story]: Create Recipe bottom selection area

Priority

MAJOR

Description

As a user I would like to be able to add a side dish to my recipe, so that my recipes can be easier to follow with grouped recipes (side dishes and main dish)

UX

image

Acceptance criteria

  • There should be an area in which the side dishes shall be placed once added.
  • In the same area there should be a selection to add a new side dish
    • Upon clicking the selection there should be a recipe selection popup
    • If the recipe is not available there, there should be an option to create a new recipe

Comments / questions

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Story]: Relocation of content in api folder

Description

As a developer I would like to have the Node project placed in the root of the repo to reduce the amount of steps needed to start development each time.

Acceptance criteria

  • Move all unnecessary files from root to docs- or more fitting folder
  • Move contents of api folder to root of repo
  • Delete api folder

Comments / questions

No response

Definition of ready/done

Definition of ready

  • DOR

    Description
    - Acceptance criteria written and reviewed by QA, PM and SE
    - Behaviour scenarios written
    - Estimated and appropriately scoped
    

Definition of done

  • DOD

    Description
    - Test complete
        - Merged to master
        - Unit tests on all new code (80% coverage)
        - Integration tests for endpoints / web sockets
    - Code complete
        - Peer reviewed (1 person/people)
        - Follows BHelpful code standards / versioning guidelines
        - No commented out code or TODOs
        - TSLint / SonarCloud exceptions have explicit explanations
    - Verified by QA
        - Functionally manually verified on a setup like the actual setup
        - QA verifies test coverage aligns with master test plan
    - Documentation of tech debt
    - Persistent technical documentation updated / written
        - Ready is updated / written
    

Code of Conduct

  • I agree to follow this project's Code of Conduct

Add recipe window

Short description of a problem or missing feature

The window for adding a recipe to the meal plan manually is missing.
image

Description of a possible solution

Add it, so it shows, when the user clicks the add recipe option or when the user changes an existing recipe in the plan to another.

[Story]: Personal information in settings

Priority

MAJOR

Description

As a user I would like to be able to change my user settings so that I can tailor my experience of using the product to my liking.

UX

image

Acceptance criteria

  • Have the UI elements in the UX
  • Make the UI elements interactable (API functionality can wait as it is not ready for it)

Comments / questions

This is the current look
image

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Story]: README to explain the development process of the project

Priority

MINOR

Description

As a developer, I would like to have a place to go to, where I can read about all things development of the project, so I can more easily get to developing the actual features.

UX

No UX needed.

Acceptance criteria

  • Create comprehensive READMEs that explain the complete workflow to make it easier for outsiders to start contributing

Comments / questions

No response

Definition of ready/done (DOR/DOD) [DONT CHANGE THE CONTENT]

Definition of ready

  • DOR

    Description
    - Acceptance criteria written and reviewed by QA, PM and SE
    - Behaviour scenarios written
    - Signed off UX
    - Estimated and appropriately scoped
    

Definition of done

  • DOD

    Description
    - Test complete
        - Merged to master
        - Unit tests on all new code (80% coverage)
        - Integration tests for endpoints / web sockets
        - End-to-end or integration tests verifying acceptance criteria
    - Code complete
        - Peer reviewed (1 person/people)
        - Follows BHelpful code standards / versioning guidelines
        - No commented out code or TODOs
        - TSLint / Sonarqube exceptions have explicit explanations
    - Verified by QA
        - Functionally manually verified on a setup like the actual setup
        - QA verifies test coverage aligns with master test plan
    - Verified by UX and product owner / verified by the team
    - Documentation of tech debt
    - Persistent technical documentation updated / written
        - Ready is updated / written
    

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Story]: Generator for component

Priority

MAJOR

Description

As a developer I would like to be able to create a new react component, so I can quicker get to developing the actual component and not write all the boilerplate code.

UX

No UX needed.

Acceptance criteria

  • Be able to generate a custom react component

Comments / questions

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Actions for recipes in recipe showcase

Short description of a problem or missing feature

The 2 functionalities that is missing, is adding to collection and clicking to open the recipe itself.

Description of a possible solution

When a user clicks the plus icon, it should change to a checkmark icon to show the user, it has been added to the user's collection.
image

When a user clicks the recipe box itself, it should take the user to the show recipe page.

[Story]: Generator for utils

Description

As a developer I would like to be able to create a new utility, so I can quicker get to developing the actual utility and not write all the boilerplate code.

Acceptance criteria

  • Be able to generate a utility that has a specific configuration matching the project

Comments / questions

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Recipes based on season

Short description of a problem or missing feature

The web app is missing this feature for the create meal plan
image

Description of a possible solution

Add it

[Story]: README to explain the development process of the project

Description

As a developer, I would like to have a place to go to, where I can read about all things development of the project, so I can more easily get to developing the actual features.

Acceptance criteria

  • Create comprehensive READMEs that explain the complete workflow to make it easier for outsiders to start contributing

Comments / questions

No response

Definition of ready/done

Definition of ready

  • DOR

    Description
    - Acceptance criteria written and reviewed by QA, PM and SE
    - Behaviour scenarios written
    - Estimated and appropriately scoped
    

Definition of done

  • DOD

    Description
    - Test complete
        - Merged to master
        - Unit tests on all new code (80% coverage)
        - Integration tests for endpoints / web sockets
    - Code complete
        - Peer reviewed (1 person/people)
        - Follows BHelpful code standards / versioning guidelines
        - No commented out code or TODOs
        - TSLint / SonarCloud exceptions have explicit explanations
    - Verified by QA
        - Functionally manually verified on a setup like the actual setup
        - QA verifies test coverage aligns with master test plan
    - Documentation of tech debt
    - Persistent technical documentation updated / written
        - Ready is updated / written
    

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Story]: Generator for middleware

Description

As a developer I would like to be able to create a new middleware, so I can quicker get to developing the actual middleware and not write all the boilerplate code.

Acceptance criteria

  • Be able to generate a middleware that has a specific configuration matching the project

Comments / questions

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Epic]: Monorepo

Priority

MAJOR

Description

As a developer, I would like to have the complete codebase for MealPlanr in one repo to simplify additions, builds, tests etc.

  • #2
  • #3
  • #4
  • Investigate if other repos should be added as well
    • No other issues for now
  • #5
  • #6
  • #7

UX

No UX

Acceptance criteria

  • The API needs to be moved to this repo
  • All issues and information from the API needs to moved and/or merged into this repo

Comments / questions

No response

Definition of ready/done (DOR/DOD) [DONT CHANGE THE CONTENT]

Definition of ready

  • DOR

    Description
    - Acceptance criteria written and reviewed by QA, PM and SE
    - Behaviour scenarios written
    - Signed off UX
    - Estimated and appropriately scoped
    

Definition of done

  • DOD

    Description
    - Test complete
        - Merged to master
        - Unit tests on all new code (80% coverage)
        - Integration tests for endpoints / web sockets
        - End-to-end or integration tests verifying acceptance criteria
    - Code complete
        - Peer reviewed (1 person/people)
        - Follows BHelpful code standards / versioning guidelines
        - No commented out code or TODOs
        - TSLint / Sonarqube exceptions have explicit explanations
    - Verified by QA
        - Functionally manually verified on a setup like the actual setup
        - QA verifies test coverage aligns with master test plan
    - Verified by UX and product owner / verified by the team
    - Documentation of tech debt
    - Persistent technical documentation updated / written
        - Ready is updated / written
    

Code of Conduct

  • I agree to follow this project's Code of Conduct

Recipe box in show recipes

Short description of a problem or missing feature

The recipe box for the private page needs to look like the following
image
The recipe box for the public page needs to look like the following
image

Current look
image

Description of a possible solution

  • The bottom icons may need to be a bit bigger (only a bit)
  • The text in the bottom needs to stay within the boundaries of the box
  • The images needs to show

Special for the private recipe box

  • Add gear icon and functionality when clicked (edit, delete)

Special for the public recipe box

  • Add plus icon, that adds the recipe to the user's collection upon click and thereafter turns into a checkmark.

[Story]: Generator for Cypress test

Priority

MAJOR

Description

As a developer I would like to be able to create a new Cypress test, so I can quicker get to developing the actual Cypress test and not write all the boilerplate code.

UX

No UX needed.

Acceptance criteria

Comments / questions

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Story]: Be able to get all recipes and a subset of public recipes

Description

As a developer, I would like to be able to get all or a subset of public recipes, so that I can display them in a UI.

Acceptance criteria

  • One should be able to get all the public recipes
  • One should be able to get a subset of public recipes

Comments / questions

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

Meal plan

Description of task

This task contains all that needs to be done to the meal plan view.
image

Sub tasks

[Story]: Respond should consist of complete object and not obj IDs

Description

As a developer I would like to get a response of the complete object I requested and not a semi-complete with IDs as references to other objects.

Acceptance criteria

  • The API should respond with complete objects for any route that benefits from it

Comments / questions

Session route does not need to be populated, since the purpose of the session isn't to get the user's information, but to get information on wether the user has a valid login or not; whereas, recipe needs to get all the information on the recipe, meaning it needs to get all the ingredients but also the user information, as the user should be displayed in relation to the recipe on the website.

Definition of ready/done

Definition of ready

  • DOR

    Description
    - Acceptance criteria written and reviewed by QA, PM and SE
    - Behaviour scenarios written
    - Estimated and appropriately scoped
    

Definition of done

  • DOD

    Description
    - Test complete
        - Merged to master
        - Unit tests on all new code (80% coverage)
        - Integration tests for endpoints / web sockets
    - Code complete
        - Peer reviewed (1 person/people)
        - Follows BHelpful code standards / versioning guidelines
        - No commented out code or TODOs
        - TSLint / SonarCloud exceptions have explicit explanations
    - Verified by QA
        - Functionally manually verified on a setup like the actual setup
        - QA verifies test coverage aligns with master test plan
    - Documentation of tech debt
    - Persistent technical documentation updated / written
        - Ready is updated / written
    

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Minor]: Possible name-change of MealPlanr

Description

  • Look into a possible name-change for the App
    • Figure out if there are any competitors with our current name.
    • Figure out if there are better names available.

UX

Possible new logo and animation.

Acceptance criteria

No response

Comments / questions

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Story]: Implement code coverage of tests

Description

As a developer I would like to log the test coverage to a service lige CodeCov in order to have an overview of the coverage and also to reach the goal of 80% code coverage for SonarCloud.

Acceptance criteria

  • Coverage needs to be logged (jest should have an option to log coverage.
  • The testing system on PRs (CircleCI) also needs to log the coverage, since we can't rely on the developers to test and log coverage on their PRs.
  • The coverage needs to be logged to a service like CodeCov to get an overview and to be able to add a CodeCov badge to the readme.

Comments / questions

No response

Definition of ready/done

  • Definition of ready
DOR
- Acceptance criteria written and reviewed by QA, PM and SE
- Behaviour scenarios written
- Estimated and appropriately scoped
  • Definition of done
DOD
- Test complete
    - Merged to master
    - Unit tests on all new code (80% coverage)
    - Integration tests for endpoints / web sockets
    - End-to-end or integration tests verifying acceptance criteria
- Code complete
    - Peer reviewed (2 people)
    - Follows Helpful code standards / versioning guidelines
    - No commented out code or TODOs
    - TSLint / Sonarqube exceptions have explicit explanations
- Verified by QA
    - Functionally manually verified on a setup like the actual setup
    - QA verifies test coverage aligns with master test plan
- Verified by product owner / verified by the team
- Documentation of tech debt
- Persistent technical documentation updated / written
    - Ready is updated / written

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Epic]: Generators for easy new file creation

Description of task

Add generators to create files and file structures that we use all the time to speed up the development process.

  • Create generators (CLI or generator scripts - could be Yeoman: https://yeoman.io/) that can generate templates for different parts of the project. (Create epics for these changes and estimate them onto the roadmap)
    • For the frontend it would make sense to have a generator for creating a new:
      • Component
      • Reducer
      • Cypress test

Sub tasks

[Minor]: Add example text to all models of collections (swagger)

Description

Implement example text for all models in swagger

Current behaviour:

  • The value next to the field in an input just shows the type of the parameter

Expected behaviour:

  • The value should show an example value to make it easier for the developer to know, what to place as that value.

Acceptance criteria

  • An example text should be added to all parts of each model so that the value can hopefully be used in the input for the routes displayed in swagger.

Comments / questions

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Story]: Relocation of content in app folder

Priority

MINOR

Description

As a developer I would like to have the Node project placed in the root of the repo to reduce the amount of steps needed to start development each time.

UX

No UX needed.

Acceptance criteria

  • Move all unnecessary files from root to docs- or more fitting folder
  • Move contents of app folder to root of repo
  • Delete app folder

Comments / questions

No response

Definition of ready/done (DOR/DOD) [DONT CHANGE THE CONTENT]

Definition of ready

  • DOR

    Description
    - Acceptance criteria written and reviewed by QA, PM and SE
    - Behaviour scenarios written
    - Signed off UX
    - Estimated and appropriately scoped
    

Definition of done

  • DOD

    Description
    - Test complete
        - Merged to master
        - Unit tests on all new code (80% coverage)
        - Integration tests for endpoints / web sockets
        - End-to-end or integration tests verifying acceptance criteria
    - Code complete
        - Peer reviewed (1 person/people)
        - Follows BHelpful code standards / versioning guidelines
        - No commented out code or TODOs
        - TSLint / Sonarqube exceptions have explicit explanations
    - Verified by QA
        - Functionally manually verified on a setup like the actual setup
        - QA verifies test coverage aligns with master test plan
    - Verified by UX and product owner / verified by the team
    - Documentation of tech debt
    - Persistent technical documentation updated / written
        - Ready is updated / written
    

Code of Conduct

  • I agree to follow this project's Code of Conduct

Requirements for making a recipe public

Description of a problem or missing feature

If any recipe can be made public, that means that there could be introduced many duplicate recipes in the public browse recipes section.

This is mostly a big problem as the user can take a public recipe, and add it to their own collection. If there were no restrictions, the user could then just make their copied version public resulting in 2 identical recipes in the public browsing area.

Description of a possible solution

Add requirements to make a recipe public

  • There has to be different ingredients
  • ?

Alternatives considered

?

Additional context

[Story]: Generator for reducer

Priority

MAJOR

Description

As a developer I would like to be able to create a new redux reducer, so I can quicker get to developing the actual reducer and not write all the boilerplate code.

UX

No UX needed.

Acceptance criteria

  • Be able to generate a custom redux reducer that has a specific configuration matching the project

Comments / questions

No response

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Story]: Create generator CLI system

Priority

MAJOR

Description

As a developer, I would like to have a generator setup, in which I am able to create generators for different parts of the project.

UX

No UX needed.

Acceptance criteria

  • Create some sort of CLI generator system, where it is possible to create generators for specific parts of the project.
  • ...

Comments / questions

No response

Definition of ready/done (DOR/DOD) [DONT CHANGE THE CONTENT]

Definition of ready

  • DOR

    Description
    - Acceptance criteria written and reviewed by QA, PM and SE
    - Behaviour scenarios written
    - Signed off UX
    - Estimated and appropriately scoped
    

Definition of done

  • DOD

    Description
    - Test complete
        - Merged to master
        - Unit tests on all new code (80% coverage)
        - Integration tests for endpoints / web sockets
        - End-to-end or integration tests verifying acceptance criteria
    - Code complete
        - Peer reviewed (1 person/people)
        - Follows BHelpful code standards / versioning guidelines
        - No commented out code or TODOs
        - TSLint / Sonarqube exceptions have explicit explanations
    - Verified by QA
        - Functionally manually verified on a setup like the actual setup
        - QA verifies test coverage aligns with master test plan
    - Verified by UX and product owner / verified by the team
    - Documentation of tech debt
    - Persistent technical documentation updated / written
        - Ready is updated / written
    

Code of Conduct

  • I agree to follow this project's Code of Conduct

[Story]: Create generator CLI system

Description

As a developer, I would like to have a generator setup, in which I am able to create generators for different parts of the project.

Acceptance criteria

  • Create some sort of CLI generator system, where it is possible to create generators for specific parts of the project.
  • ...

Comments / questions

No response

Definition of ready/done

Definition of ready

  • DOR

    Description
    - Acceptance criteria written and reviewed by QA, PM and SE
    - Behaviour scenarios written
    - Estimated and appropriately scoped
    

Definition of done

  • DOD

    Description
    - Test complete
        - Merged to master
        - Unit tests on all new code (80% coverage)
        - Integration tests for endpoints / web sockets
    - Code complete
        - Peer reviewed (1 person/people)
        - Follows BHelpful code standards / versioning guidelines
        - No commented out code or TODOs
        - TSLint / SonarCloud exceptions have explicit explanations
    - Verified by QA
        - Functionally manually verified on a setup like the actual setup
        - QA verifies test coverage aligns with master test plan
    - Documentation of tech debt
    - Persistent technical documentation updated / written
        - Ready is updated / written
    

Code of Conduct

  • I agree to follow this project's Code of Conduct

What meals for each day

Short description of a problem or missing feature

  1. The disabled toggles should not be interactive
    Zr83fOPVKf
  2. The popup menu should be changed to the one in the mockup
    This:
    image
    Should look like:
    image

[Story]: Path mapping instead of relative paths

Description

As a developer, I would like to worry less about the paths to my imports, so I can more easily create new imports and understand the current imports.

Acceptance criteria

  • Implement path mapping instead of relative paths

Comments / questions

https://youtu.be/WpgZKBtW_t8

Code of Conduct

  • I agree to follow this project's Code of Conduct

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.