diff --git a/high_level_diagram.drawio.png b/high_level_diagram.drawio.png new file mode 100644 index 0000000..b1761b0 Binary files /dev/null and b/high_level_diagram.drawio.png differ diff --git a/meeting_minutes/11th_July.md b/meeting_minutes/11th_July.md new file mode 100644 index 0000000..bb14597 --- /dev/null +++ b/meeting_minutes/11th_July.md @@ -0,0 +1,65 @@ + +--- + +**Meeting Details:** + +- Date: 11th July 2023, Tuesday +- Time: 1400 WAT + +**Agenda Review:** + +- Finalize our idea + - define our goal + - research on practicability + - confirm with mindsdb team +- Register for the hackathon +- Plan the project + - define milestones, assign deadlines, roles + - tech stack + - coding guidelines: naming conventions +- Discuss how to start with the project + - reach out to community for help + - possibility of mentors + +**Meeting Summary:** + +- Goal is to help console people who are going through tough times mentally + - Practicable, refer Build a Twitter Chatbot with OpenAI GPT in mindsdb learning hub + - We need to research & find the better engine & model which is specific to our use case +- Registered for the hackathon +- Prepared a high level diagram +- Defining milestones requires better understanding of the tasks to be done underneath. + So we are going to work on the action items & define them by 22nd July 1400 WAT. + - Front-end: TypeScript, ReactJS + Back-end: Python + - Coding guidelines draft will be prepared & later updated + + +**Action Items:** + +- Reach out to MindsDB community to know if the idea is practicable by Seb + - how to get started + - reach out for help + - check if we would get mentors +- Research on working of mindsdb (refer chatbot examples), chatbot in general by Penn & Seb +- Preparing coding guidelines by Penn on 16th July + + +**Decisions and Resolutions:** + +- Finalized idea: Chatbot for mental health + - Should revisit ideation in case it's not practicable + + +**Additional Notes:** (not specific to agenda items) +- [WeMakeDevs blogging challenge on hashnode](https://wemakedevs.org/events/hashnode) +- Hashnode hackathons + + +**Next Meeting:** + +- Date: 15th July +- Time: 1400 WAT +- Expected End Time: 1500 WAT + +--- diff --git a/meeting_minutes/16th_July.md b/meeting_minutes/16th_July.md new file mode 100644 index 0000000..a6652e1 --- /dev/null +++ b/meeting_minutes/16th_July.md @@ -0,0 +1,39 @@ + +--- + +**Meeting Details:** + +- Date: 16th July 2023, Sunday +- Time: 1400 WAT + +**Agenda Review:** + +- Plan the project + - breakdown the project into tasks + +**Meeting Summary:** + +- Broke down the project into tasks in terms of front-end, back-end by referring to Snoopstein chatbot example in detail. + +**Action Items:** + +- Design & implementing UI by Penn by 21st July +- Linking front-end to back-end by Penn +- Deciding the engine & model for the use case by Seb by 19th July +- Pass request (name, chat text) to mindsdb by Seb by 22nd July +- Python coding guidelines by Seb + +**Decisions and Resolutions:** +- Tasks defined & assigned, along with deadlines +- Review progress, & keep each other in check + +**Additional Notes:** (not specific to agenda items) +- few others are working on similar idea, saw it in questions channel + +**Next Meeting:** + +- Date: 19th July +- Time: 1400 WAT +- Expected End Time: 1500 WAT + +--- diff --git a/meeting_minutes/23rd_July.md b/meeting_minutes/23rd_July.md new file mode 100644 index 0000000..b8ff93f --- /dev/null +++ b/meeting_minutes/23rd_July.md @@ -0,0 +1,43 @@ + +--- +**Submission deadline: 19th Aug** + +**Meeting Details:** + +- Date: 23rd July 2023, Sunday +- Time: 1400 WAT + +**Agenda Review:** + +- Progress wrt action items & tasks assigned +- Code structure: monolithic arch - front-end & back-end in same codebase +- Develop & release faster with deadline in view + +**Meeting Summary:** + +- Penn has designed & implemented basic UI. Penn will be checking on how to link front-end to back-end. +- Seb researched on engine & model. Privacy is a concern when it comes to openai & gpt. Future scope: explore on open source projects which respects privacy. Coding guidelines have been updated. Seb will be implementing the connection between back-end & mindsdb using python sdk provided by mindsdb. + +**Action Items:** + +- Deploy front-end for demo by Penn +- Linking front-end to back-end by Penn +- How to approach deploying front-end & back-end: research on best practices on use of multiple github accounts by Seb +- DB schema design: input & output tables by Seb + +**Decisions and Resolutions:** + +- Penn will be creating a repo for front-end in his github. +- Use of vercel (front-end) & render (back-end) for deploying + +**Additional Notes:** (not specific to agenda items) + +- + +**Next Meeting:** + +- Date: 30th July +- Time: 1400 WAT +- Expected End Time: 1500 WAT + +--- diff --git a/meeting_minutes/30th_July.md b/meeting_minutes/30th_July.md new file mode 100644 index 0000000..617df66 --- /dev/null +++ b/meeting_minutes/30th_July.md @@ -0,0 +1,46 @@ + +--- +**Submission deadline: 19th Aug** + +**Meeting Details:** + +- Date: 30th July 2023, Sunday +- Time: 1300 - 1330 WAT + +**Agenda Review:** + +- Progress wrt tasks + - front-end deployment + - back-end connection to mindsdb +- Importance of automating backend +- Reviewing code & documentation, and merging into dev for reference + +**Meeting Summary:** + +- Penn facing minor issue with front-end deployment +- Seb facing import error for mindsdb-python-sdk +- Going forward the focus will be on getting more work done towards having a project for submission with proper documentation. + +**Action Items:** + +- Penn will finish up the minimal front-end & connection to back-end +- Penn will take up tasks for back-end based on github issues +- Seb will connect back-end to mindsdb & get a basic flow working +- Seb will create github issues + +**Decisions and Resolutions:** + +- Github issues will be used to create, define tasks with steps & resources +- Penn & Seb will work towards a working submission + +**Additional Notes:** (not specific to agenda items) + +- Meeting preponed as per Penn's suggestion + +**Next Meeting:** + +- Date: 4th August +- Time: 1400 WAT +- Expected End Time: 1500 WAT + +--- diff --git a/meeting_minutes/4th_Aug.md b/meeting_minutes/4th_Aug.md new file mode 100644 index 0000000..980b98a --- /dev/null +++ b/meeting_minutes/4th_Aug.md @@ -0,0 +1,36 @@ + +--- +**Submission deadline: 19th Aug** + +**Meeting Details:** + +- Date: 4th Aug 2023, Friday +- Time: 1400 - WAT + +**Agenda Review:** + +- Urgency to focus on back-end tasks + +**Meeting Summary:** + +- + +**Action Items:** + +- + +**Decisions and Resolutions:** + +- + +**Additional Notes:** (not specific to agenda items) + +- + +**Next Meeting:** + +- Date: August +- Time: 1400 WAT +- Expected End Time: 1500 WAT + +--- diff --git a/meeting_minutes/9th_July.md b/meeting_minutes/9th_July.md new file mode 100644 index 0000000..67deb98 --- /dev/null +++ b/meeting_minutes/9th_July.md @@ -0,0 +1,54 @@ +--- + +**Meeting Details:** + +- Date: 9th July 2023, Sunday +- Time: 1300 WAT + +**Attendees:** + +- Penn - Front-end +- Sebastian - Back-end + +**Agenda Review:** + +- Self-introduction +- Sharing ideas + +**Meeting Summary:** + +- Self-introduction: + - Address each other's names, shared details such as country, timezone, language, current tech stacks and areas of experience +- Ideas Shared: + - Chatbot for mental health by Sebastian + - Chatbot for coding assistance by Penn + +**Action Items:** + +- Prepare meeting minutes format - Assigned to Seb - Deadline: 11th July +- Research for more ideas - Assigned to Penn - Deadline: 11th July + +**Decisions and Resolutions:** + +- Fix ideas, & start with the project by next meeting mentioned below + +**Additional Notes:** (not specific to agenda items) + +- [Kunal Kushwaha](https://www.youtube.com/c/kunalkushwaha) +- [WeMakeDevs](https://wemakedevs.org/) +- [Hashnode](https://hashnode.com/) +- [Rix](https://hashnode.com/rix?source=nav) + +**Next Meeting and Adjournment:** + +- Date: 11th July +- Time: 1400 WAT +- Expected End Time: 1500 WAT + +**Review and Distribution:** + +- Please review the minutes for accuracy and clarity. + +**Archive:** + +- Store the minutes in the designated archive folder. diff --git a/meeting_minutes/format.md b/meeting_minutes/format.md new file mode 100644 index 0000000..e47690b --- /dev/null +++ b/meeting_minutes/format.md @@ -0,0 +1,72 @@ + +--- + +**Meeting Details:** + +- Date: [Insert Date] +- Time: [Insert Time] + +**Attendees:** + +- [Insert Attendee 1 Name] - [Insert Attendee 1 Role] +- [Insert Attendee 2 Name] - [Insert Attendee 2 Role] +- [Insert Attendee 3 Name] - [Insert Attendee 3 Role] +- ... + +**Absentees:** (include when anyone else has been invited). + +- [Insert Absent Member 1 Name] +- [Insert Absent Member 2 Name] +- ... + +**Agenda Review:** + +- [Insert Agenda Item 1] +- [Insert Agenda Item 2] +- ... + +**Meeting Summary:** + +- [Insert Agenda Item 1 Summary] + - [Important Point/Idea/Decision 1] + - [Important Point/Idea/Decision 2] + - ... + +- [Insert Agenda Item 2 Summary] + - [Important Point/Idea/Decision 1] + - [Important Point/Idea/Decision 2] + - ... + +**Action Items:** + +- [Task 1] - Assigned to [Assigned Person/Team] - Deadline: [Insert Deadline] +- [Task 2] - Assigned to [Assigned Person/Team] - Deadline: [Insert Deadline] +- ... + +**Decisions and Resolutions:** + +- [Insert Decision 1] +- [Insert Decision 2] +- ... + +**Additional Notes:** (not specific to agenda items) +eg: suggestions, recommendations + +- [Insert Additional Note 1] +- [Insert Additional Note 2] +- ... + +**Next Meeting and Adjournment:** + +- Date: [Insert Next Meeting Date] +- Time: [Insert Next Meeting Time] +- Expected End Time: [Insert Expected End Time] + +**Review and Distribution:** + +- Please review the minutes for accuracy and clarity. + +**Archive:** +- Store the minutes in the designated archive folder. + +--- diff --git a/references/coding_guidelines/GeneralCodingGuidelines.md b/references/coding_guidelines/GeneralCodingGuidelines.md new file mode 100644 index 0000000..70a525c --- /dev/null +++ b/references/coding_guidelines/GeneralCodingGuidelines.md @@ -0,0 +1,148 @@ +# Coding Guidelines + +## Introduction + +This document provides a set of general coding guidelines to follow when writing code. These guidelines aim to enhance code readability, maintainability, and collaboration within the development team. + +## Table of Contents + +1. [Naming Conventions](#naming-conventions) +2. [Formatting and Style](#formatting-and-style) +3. [Documentation](#documentation) +4. [Error Handling](#error-handling) +5. [Testing](#testing) +6. [Version Control](#version-control) +7. [Performance](#performance) + +## Naming Conventions + +- Use descriptive and meaningful names for variables, functions, classes, and other identifiers. +- Follow a consistent naming convention (e.g., camelCase, PascalCase, snake_case) throughout the codebase. +- Avoid using single-letter variable names except in cases where the purpose is clear and limited to a short scope. + +Example: +```javascript +// Good +const firstName = 'John'; +const maxAttempts = 3; + +function calculateSum(a, b) { + return a + b; +} + +class Customer { + // Class implementation +} + +// Avoid +const a = 5; +const s = 'Hello'; + +function sum(a, b) { + return a + b; +} + +class cust { + // Class implementation +} +``` + +## Formatting and Style + +- Use consistent indentation (e.g., 2 or 4 spaces) for code blocks and maintain a consistent coding style throughout the project. +- Follow the language-specific formatting guidelines and best practices. +- Ensure proper spacing around operators, commas, and other elements to improve code readability. +- Use clear and concise comments to explain complex logic, algorithms, or important code sections. + +Example: +```javascript +// Good +if (condition) { + // Code block +} + +const result = number1 + number2 + number3; + +// Avoid +if(condition){ + // Code block +} + +const result=number1+number2+number3; +``` + +## Documentation + +- Document public APIs, functions, and classes to provide usage instructions, parameter descriptions, return values, and any relevant examples. +- Use inline comments to provide explanatory notes for code sections that may be non-obvious or require additional context. +- Maintain up-to-date documentation that reflects the current state of the codebase. + +Example: +```javascript +/** + * Calculates the sum of two numbers. + * @param {number} a - The first number. + * @param {number} b - The second number. + * @returns {number} The sum of a and b. + */ +function calculateSum(a, b) { + return a + b; +} +``` + +## Error Handling + +- Implement appropriate error handling mechanisms to handle exceptions, errors, and unexpected situations. +- Use meaningful error messages and log appropriate details for debugging purposes. +- Avoid excessive use of nested try-catch blocks and handle errors at an appropriate level. + +Example: +```javascript +try { + // Code that may throw an exception + const result = calculateSum(10, '20'); +} catch (error) { + console.error('An error occurred:', error.message); +} +``` + +## Testing + +- Write unit tests to verify the correctness and functionality of code components. +- Automate testing as much as possible using testing frameworks or tools. +- Aim for high code coverage to ensure adequate test coverage. + +Example (using Jest testing framework): +```javascript +test('Calculate sum', () => { + expect(calculateSum(2, 3)).toBe(5); + expect(calculateSum(-1, 1)).toBe(0); +}); +``` + +## Version Control + +- Use a version control system (e.g., Git) to manage code changes, branches, and collaboration. +- Follow best practices for branching, committing, and merging code. +- Write meaningful commit messages that describe the purpose and changes made in each commit. + +Example: +``` +feat: Add new feature to calculateSum function + +The calculateSum function now supports floating-point numbers as inputs and handles them correctly. +``` + +## Performance + +- Write efficient code by considering performance implications. +- Optimize critical sections of code when necessary, based on profiling and performance analysis. +- Avoid unnecessary duplication, excessive memory usage, or unnecessary computations. + +## Conclusion + +Following these coding guidelines will promote consistency, readability, and maintainability of the codebase. Adhering to these guidelines will help create clean, robust, and high-quality code. + +Remember, these guidelines can be adapted and extended based on the specific needs and requirements of your project and development team. + +Please review and adhere to these guidelines when writing code. \ No newline at end of file diff --git a/references/coding_guidelines/PythonCodingGuidelines.md b/references/coding_guidelines/PythonCodingGuidelines.md new file mode 100644 index 0000000..d695a1e --- /dev/null +++ b/references/coding_guidelines/PythonCodingGuidelines.md @@ -0,0 +1,161 @@ +# Python Coding Guidelines + +## Introduction + +These guidelines aim to enhance code readability, maintainability, and collaboration within the development team. + +## Table of Contents + +1. [Naming Conventions](#naming-conventions) +2. [Formatting and Style](#formatting-and-style) +3. [Documentation](#documentation) +4. [Error Handling](#error-handling) +5. [Testing](#testing) +6. [Imports](#imports) +7. [Version Control](#version-control) + +## Naming Conventions + +- Use descriptive and meaningful names for variables, functions, classes, and modules. +- Follow the PEP 8 naming conventions for Python code. +- Use lowercase letters for variable and function names, and capitalize class names (e.g., `my_variable`, `my_function`, `MyClass`). Example: + ```python + # Good + my_variable = 42 + + def my_function(): + pass + + class MyClass: + pass + + # Avoid + MyVariable = 42 + + def MyFunction(): + pass + + class my_class: + pass + ``` +- Avoid using single leading underscores for regular identifiers to indicate privacy. + +## Formatting and Style + +- Use consistent indentation using spaces (typically 4 spaces) rather than tabs. +- Limit lines to a maximum length of 79 characters to improve readability. +- Break long lines into multiple lines using parentheses or backslashes. Example: + ```python + # Good + result = (number1 + + number2 + + number3) + + # Avoid + result = number1 + number2 + number3 + ``` + +- Use vertical whitespace sparingly to group related lines of code. +- Follow PEP 8 guidelines for code layout, whitespace, and other style recommendations. + +## Documentation + +- Document modules, classes, and functions using docstrings to provide descriptions, parameters, and return value details. Example: + ```python + def calculate_sum(a, b): + """ + Calculates the sum of two numbers. + + Args: + a (int): The first number. + b (int): The second number. + + Returns: + int: The sum of a and b. + """ + return a + b + ``` + +- Use clear and concise comments to explain complex logic or important code sections. +- Use meaningful variable and function names that help convey their purpose and usage. +- Write self-explanatory code that doesn't require excessive comments to understand. + +## Error Handling + +- Use appropriate exception handling to handle errors and exceptions. +- Avoid using bare `except` statements unless handling specific exceptions. Example: + ```python + # Good + try: + # Code that may raise an exception + pass + except ValueError as e: + # Handle ValueError + pass + except Exception as e: + # Handle other exceptions + pass + + # Avoid + try: + # Code that may raise an exception + pass + except: + # Handle all exceptions (bad practice) + pass + ``` + +- Use specific exception classes whenever possible to catch only relevant exceptions. +- Log errors and exception details to aid in debugging and troubleshooting. + +## Testing + +- Write unit tests using a testing framework (e.g., `unittest`, `pytest`) to verify the functionality of code components. Example: + ```python + import unittest + + def add(a, b): + return a + b + + class TestAdd(unittest.TestCase): + def test_add(self): + self.assertEqual(add(2, 3), 5) + self.assertEqual(add(-1, 1), 0) + ``` + +- Aim for high test coverage to ensure thorough testing of code. +- Automate testing using testing frameworks or tools. +- Separate test code from production code and organize tests into logical test suites. + +## Imports + +- Follow the recommended import style, importing only the necessary modules or classes. +- Use absolute imports over relative imports whenever possible. +- Group imports in the following order: standard library imports, third-party library imports, and local application imports. Example: + ```python + import os + import sys + import datetime + + import requests + import numpy as np + import pandas as pd + + from my_package import module1, module2 + ``` + +- Avoid wildcard imports (`from module import *`) as they can pollute the namespace and make code less readable. + +## Version Control + +- Use a version control system (e.g., Git) to manage code changes, branches, and collaboration. +- Follow best practices for branching, committing, and merging code. +- Write meaningful commit messages that describe the purpose and changes made in each commit. + +## Conclusion + +Following these coding guidelines will promote consistency, readability, and maintainability of Python code. Adhering to these guidelines will help create clean, robust, and high-quality Python code. + +Remember, these guidelines can be adapted and extended based on the specific needs and requirements of your project and development team. + +Please review and adhere to these guidelines when writing Python code. \ No newline at end of file diff --git a/references/coding_guidelines/TypeScriptCodingGuidelines.md b/references/coding_guidelines/TypeScriptCodingGuidelines.md new file mode 100644 index 0000000..e3d3f49 --- /dev/null +++ b/references/coding_guidelines/TypeScriptCodingGuidelines.md @@ -0,0 +1,270 @@ +# TypeScript Coding Guidelines + + July 15, 2021 + +# Why do we need coding guidelines? + +Is a general rule of software development to craft applications that are readable, maintainable and scalable. This is not always the truth but we aim for this goal. + +Code standards are tools that helps to achieve building applications with the triad principles mentioned above. Here are some of the benefits that are provided by establishing a consistent development guideline: + +- Reduction of security risks +- Increase of software performance +- Reduce the system complexity +- Cost-efficient. + +# This Document + +This is a living document under continuous improvement. +Copying, use, modification, and creation of derivative works from this project is licensed under an MIT-style license. +Contributing to this project requires agreeing to a Contributor License. See the accompanying [LICENSE](LICENSE) file for details. +We make this project available to "friendly users" to use, copy, modify, and derive from, hoping for constructive input. + +Comments and suggestions for improvements are most welcome. +We plan to modify and extend this document as our understanding improves and the language and the set of available libraries improve. + +# Summary + +- [Proposed Convention](#P-Conventions) +- [Variable Declaration](#S-Variables) +- [Types & SubTypes](#S-Types) +- [Type Casting](#TC-Casting) +- [Conditional Flow](#CF-Flow) +- [Ternary Operation](#TO-Op) +- [Language Features](#S-Language-Features) + +# Proposed Convention + +| Name | Convention | Example | Code | +| ---------------------- | ---------- | ------------- | --------------------------------- | +| single variable name | camelCase | variable | `let age: number = 0;` | +| compound variable name | camelCase | variableName | `let firstName: string = "";` | +| constant name | UPPER_CASE | CONSTANT | `const CPU: number = 100;` | +| compound constant name | UPPER_CASE | CONSTANT_NAME | `const MAX_NUMBER: number = 100;` | +| enum name | PascalCase | MyEnum | `enum MyEnum { A, B, C };` | +| function name | camelCase | function | `function function()` | +| compound function name | camelCase | myFunction | `function myFunction()` | +| class name | PascalCase | Class | `class Base` | +| compound class name | PascalCase | MyClass | `class MyClass` | +| interface name | PascalCase | Interface | `interface IMyInterface` | + +# Variable Declaration + +- To declare a variable you can use the keywords `var`, `let` or `const`. + - **const:** increase the predictability of your code, that intrinsically improve performance. + - **var:** is globally scoped, doesn't respect code blocks, this may sometimes generate confusion. **Avoid var when you can**. + - **let:** is scoped constrained. If you declare a variable inside of a scope that variable will exist only inside of the scope + where it was created. You can't access the variable externally. This is usually the strategy used in most of the strongly typed languages. +- Prefer `const` over `let` when possible, and **avoid using var**. +- Always initialize variables to avoid undefined behavior +- Always define the type for your variable. +- Declaration patterns: designator statement, variable name, type, and optional assignment operator + value. + +> <> _Don’t ever use the types Number, String, Boolean, Symbol, or Object These types refer to non-primitive boxed objects that are +> almost never used appropriately in JavaScript code_. + +```typescript +// Variable declaration +// Designator - variable name - assignment operator - optional value + +let name: string = "developer"; +const NAME: string = "developer"; + +{Without optional value} + +let name: string; +const NAME: string; +``` + +```typescript +// Use of let +let y: number = 100; +{ + let x: number = 10; + y = 101; {OK} +} + +x = 11; {You can't assign value to the variable x because the variable was created in a blocked scope} +``` + +# Types & Subtypes + +- Brief explanation of types and subtypes: + + - **number:** represents an integer or floating point number. Ex. 56 or 76.987. The size of a number is a double-precision 64-bit binary [format IEEE 754](https://en.wikipedia.org/wiki/Double-precision_floating-point_format). + - **bigint:** can represent integers of arbitrary size, larger than whole numbers 2^53 - 1. `Number.MAX_SAFE_INTEGER` is the largest number JavaScript can represent with a number primitive (or Number value). + - **string:** sequence of characters used to represent text. Ex. "Hello World". + - **symbol:** a unique and immutable symbol. Used to represent a property key, and used to avoid conflicts with other symbols. + - **boolean:** true or false (it is not equivalent to 0 and 1). There is no data overlap between boolean and number. + - **Array:** is an ordered list of values. In Typescript you can use array type to specify a list of values. + Arrays can be declared using the generics template `let myArray: Array` or the type annotation `let myArray: number[]`. + - **null:** null varies from language to language but in type script null represents the absence of value, nonexistent or invalid object or address. + + ```typescript + class MyType { + public typeInfo: string = "MyType"; + } + + let myType: MyType = new MyType(); + console.log(myType.typeInfo); // MyType {OK} + + myType = null; // Setting object to point to null + console.log(myType); // null {OK} + console.log(myType.typeInfo); // cannot read property 'typeInfo' of null {NOK} + ``` + + - **undefined:** when a variable is declared but not initialized or when an argument is not formally passed. + + ```typescript + let x: number; // variable declared but not initialized + console.log(x); // undefined + + function MyFunction(x: number) { + console.log(x); + } + + MyFunction(); // undefined + ``` + + - **object:** any javascript value with a set of properties. + - **any:** is a special type that you can use whenever you don't want to specify a type, or you don't want a particular value to cause a typechecking error. If you don't specify a type, or Typescript can't infer the type from it context,the compiler will default to any. You don't usually want to use any because defeats the purpose of typechecking. + - **void** is a special type that is used to represent the absence of a value. + - **unknown:** is a type that represents any value. It is the default type for any variable that is not explicitly typed. + - **never:** is a type that represents the absence of a value. Unreachable code is typed as never. + +## Table of Types + +| Type | Use | +| ------- | ---------------------------------------------------------------- | +| boolean | when we want to represent true or false | +| number | when we want to represent an integer or a floating point | +| bigint | to represent a large integer number | +| string | represent a sequence of characters | +| symbol | to represent a unique symbol | +| array | ordered list of values. Can be used combined with any other type | + +## Table of Subtypes + +| Type | Use | +| --------- | ------------------------------------------------------------------------------------------- | +| null | to represent absence of value, invalid object | +| undefined | when a variable is declared but not initialized or when an argument is not formally passed. | +| object | to represent a value with a set of properties. Ex. { id: 1, foo: 'foo' } | +| any | to be used to avoid typechecking. Try to do not use this type much | +| void | to represent the absence of a value | +| unknown | to represent any value. Prefer to use unknown rather than any | +| never | to represent the absence of a value. It is the default type for any variable that is not | + +## Assignment of Subtypes + +| Type | any | unknown | object | void | undefined | null | never | +| --------- | --- | ------- | ------ | ---- | --------- | ---- | ----- | +| any | | OK | OK | OK | OK | OK | | +| unknown | OK | | | | | | | +| object | OK | OK | | | | | | +| void | OK | OK | | | | | | +| never | OK | OK | OK | OK | OK | OK | | +| null | OK | OK | OK | OK | OK | | | +| undefined | OK | OK | OK | OK | | OK | | + +# Type Casting + +- Type casting is the capability to convert one type to another. In Typescript you can use `as` or `<>` to convert a value to a different type. +- When `any` or `unknown` is used, you can't use `as` or `<>` to convert a value to a specific type. **Always prefer to use unknown over any**. Unknown will force to explicitly specify the type. Unknown also prevents you to reasign a value to a variable without casting it. + +```typescript +let varUnknown: unknown = "foo"; +let varAny: any = "foo"; + +// Reassign of values +varUnknown = 1; +varAny = 1; + +// Variable reassignment +let varStringAny: string = varAny; // (OK) +let varStringUnknown: string = varUnknown; // (NOK) + +// Typecasting is necessary +let varStringUnknown1: string = varUnknown; // (OK) +// Or +let varStringUnknown2: string = varUnknown as string; // (OK) +// Or +let varStringUnknown3: string = String(varUnknown); // (OK) +``` + +## From any type to string, except object type + +```typescript +let localNumber: number = 1; +// Recommended methods below : More readable +let localNumberToString1: string = localNumber.toString(); +let localNumberToString2: string = String(localNumber); +let localNumberToString3: string = localNumber as unknown as string; + +let localNumberToString4: string = (localNumber as unknown); +let localNumberToString5: string = (localNumber) as string; +``` + +# Conditional Flow + +- Conditionals statements are expressions or simply features of a programming language that tell the computer to execute certain actions, provided certain conditions are met. + +- If statement always evaluate if condition is `True` + +```typescript +if (true) { + // Always true +} +``` + +- If statements can be followed by Else if the condition is not `True` + +```typescript +if (!true) { + // Always true +} else { + // Is not true +} +``` + +- Example of double validation inside of if conditional statement + +```typescript +let username: string = "Admin"; +let password: string = "password"; + +if (username == "Admin" && password == "password") { + // It will be True if both variables are evaluated to True +} +``` + +- Nested If conditionals. You can nest as many if's you would like to, there is no limits, however a good programming practice tell us that if you have more than 2 if conditionals nested is time for you to review your code, and add some of these conditions inside of a function. +- Nesting too many if's makes difficult to read the code! + +```typescript +if (true) { + if (true) { + } +} +``` + +# Ternary Operation + +- The benefits of using ternary operation are: + + - It will shorten the code. + - It will improve the code readability. + - The code becomes more straightforward. + - Replaces if/else in a compressed form. + +- Ternary operations can be nested but it is not recommended as defeats the purpose of having a shorted and easy to read code. + +```typescript +let isTrue = true ? true : false; +``` + +- Nested ternary + +```typescript +let isTrue = true ? (true ? true : false) : false; // Not recommended +``` diff --git a/references/notes.md b/references/notes.md new file mode 100644 index 0000000..3541af0 --- /dev/null +++ b/references/notes.md @@ -0,0 +1,41 @@ +**Ideation** + +- The chatbot should have a personality. We can refer how snoopstein chatbot was done. +- We can provide an option to customize the personality. + +**Implementation** + +- Initially we can try with Andrew Huberman or Mother Theresa to understand how to get response similar to the case of Snoopstein. +- Get an eye catching but minimal front-end ready + +**To-do** + +- Decide which tools to use. eg: IDE + - Consider front-end & back-end +- Update meeting minutes + - consider to include meeting end time + +**Features** + +- Loading of chat history + +**Future Scope** + +- _Tech upgrade_: + - Monolithic arch to microservice migration +- _Features to consider_: + - **Empathy and Emotional Understanding**: Use natural language processing and sentiment analysis + - **Crisis Support and Escalation**: identifying users who may be in crisis or at risk of self-harm; how to seek professional help or connect with a helpline + - **Personalization**: profiles or share their preferences; personalized support and recommendations + - **Mental Health Resources**: articles, videos, and self-help materials + - **Mindfulness and Meditation**: exercises or guided meditation sessions + - **Coping Strategies**: practical tips for stress, anxiety, or depression. + - **Progress Tracking**: track their mood, emotions, or progress over time to gain insights into their mental well-being and identify patterns + - **Referral to Professionals**: how and where to seek help from therapists, counselors, or support groups. + - **Community Support**: connections between users who may be going through similar experiences, encouraging peer support. + - **Feedback and Continuous Improvement**: Collect feedback from users on chatbot's responses and support capabilities. + - **Privacy and Security**: _strict_ privacy guidelines and data security measures to protect user information. + - **Multilingual Support**: multilingual to reach a broader audience and provide support to users from diverse backgrounds. + + +- [Notes for quick reference](https://docs.google.com/document/d/1Kzqg4lyQfeKj0JlYseAoTHpWlFvCInm-v72zGA_8oJc/edit?usp=sharing) diff --git a/references/submission_checklist.md b/references/submission_checklist.md new file mode 100644 index 0000000..550627c --- /dev/null +++ b/references/submission_checklist.md @@ -0,0 +1,2 @@ +**Things to take care before submission** +- Is specific license required for the project?