Notes.txt

NEXT:
    build the login system

REDESIGN!
    Alright, How are we going to approach this as an API?
        Lets break it down so there is the section of the API that handles CRUD operations
        and then another section that handles the app itself. (Microservice the app)
    First, lets look at our CRUDL operations and what they're doing:
        CREATE - Be able to add a rule to the database
            Do we want to implement a schema for this so it's  much more clean?
        READ - Get a single rule from the database
            How will we identify them? Probably by tag name
        UPDATE - Change a single rule from the database
        DELETE - Remove a sing rule from the database
        LIST - List all the rules for a single language
            How do we differ from different languages?
            Should we return the entire language list and then let the frontend sort it out?
                Not quite, use mongodb aggregate to compile all the rules we need
            How should we get all the rules vs. only a few per page?
                If there isn't a query, then send all the rules back

    Things to consider:
        How are we going to keep this stateless? Probably with less of my own 'caching'
        Agregating the database for the normal token is fine, but regex might need some more love
        Check for and remove redundant information (token sig?)

    Next, we need to decouple the application from the server
        The app itself shouldn't be that complicated. Just CRUDL it.
        The page might need more work though so we can clean up the code editor
    
    CLEAN UP THE README

    Finally, we need to make the frontend application to edit each of the rules

---

NOW:
- Organize your project to sperate the server from the application
    * Put your server files and stuff in 'www' directory
    * Have the app and functionality be seperate
    * this makes things easier to test
- USE DEBOUNCE TO WAIT FOR INPUT
    * When you're writing info, it will wait a few miliseconds before processing data (like 400ms or so);
- Organize your pages and routes to be handled accordingly

Things to do v1:

√ Sanatize the html input from the rules
√ Set 'code snippets' for the rules.html
√ Have a 'rating' bar at the bottom of each explination asking if it was a good definition
    * This is just for now to get a better use of the code
    * Have it just be a 'feedback' button with a modal
√ Write up the README and include instructions on how to write the rules
    * Look up how to do 'markdown' as in README.md <--
√ Fix the 'new line' problem with the code snippits inside explinations
√ Fix the 'GET' limit problem
    * Maybe it's only when I start it up insead of inserting?
√ Just have another mock language at the top (change collection name)
    * Have a database of language names?
√ Fix design on big screen with zoom (use bootstrap)
√ Clean up explinations (better grammar)
√ Do some "data collection"
    * Just have a database collect how often a tag was used
√ DEPLOY

v2:
- Deploy properly
    * Have it on an actual engine
√ Turn off mobile version
- Build a "Language" collection
    * Have it hold both the language, and the values to add onto the language
- Add a default page if javascript is off
- Build a card/rule constructor for them to code on their own
- Make a CRUD app to configure things
- Have a better transition between descriptions
- Link explinations in rules to other explinations
    * Have it retrieve it from the backend using a single token 'GET'
- Have an error message if we don't have complete code
- Save the users code in the 'local' storage as a cookie
    * Might cause the GET error
- Write a better card for an object key/pair values instead of them just being "variables"
- Favicon, node middleware, proper version control
- Have a copy icon for your code to bring it over
- Have sanitize only allow certian words
- Pull the actual value that we're working with
- Admin CRUD functionality

v3:
- Have highlighting parse and explain further

Things to consider:

(√) 1. No mobile version. It'll just be too hard to implement. Instead have a page that explains why
2. Useless information: "this is error code 24"
(√) 3. Parse the document first and gather all the keywords, then get the corresponding rules from the server. Not locally
4. Prevent user from trying to 'explain' non compilable code. Maybe in the future, have a prompt that says to the effect "This code is invalid, which might cause some errors with the explination. Do you want us to try and explain it anyway?"

Extra stuff if there's time:

~ "Grammar Checker": Check spelling for common words (ex: funciton -> function) // Is this taken care of by ace code editor already?
- Get a bunch of people to use it and then start doing data collection.
√ Check if the code compiles and then show errors if it doesn't. (done by Ace)
- Have a select function that can parse a selection and give some explination what might be going on (ex. "let x = 0;" 'We're creating a variable and assigning it the value of 0')
    * This will probably need it's own database to get running. The server will likely parse the tokens and then relate them to a database that has the correct regex syntax
- Have rules reference various parts of the code entered (ex. while describing a funciton name, include the function name in the rules);
- You can link between different keywords using the token iterator till it runs into it.
- When naming the collections, have a naming convention so you can get it by concating string (Ex. if we're using javascript as our code, have the databases be called "javascriptTokensRules")
- Have it be "function begin" instead of "Curly Brace" (probably set this as regex rule instead of a token)
- Create a "simplifier" button at the top of each explination to give an even simpler explination of the code
- Have a "request" part that someone can request a specific keyword, maybe part of the "This keyword doesn't exist"
- Have a button to "execute" the code and have it simply just redirect to another site and include the code body in the header to run it there.

Rules for Tokens:
    
    The only character able to be passed into a token is '\n'
    No '\t' characters are allowed. Use 4 spaces instead
    All links are automaticlaly set to open a new tab

Random:

    Regex for a variable declaration: (?:let|var|const)\s+[a-zA-Z][0-1a-zA-Z]+
    Keywords to do: (Everything that can be listed in the "code" part of a card, give it a card)
        ---
        errors (try/catch)
        of
        in
        escape character
        undefined/null
        include '^' in Boolean operators
        ternary operator
        switch/case/default;
        arrow functions
        Objects & object notation
        dot notation (obj.x)
        shift opperations(<<, >>)
        regexp
        'document' && 'window'
        quasi string (`)
        spread operator (...)
        extended libraries (Math, etc.)
    Primary index file is used only to import middleware and errors

Feedback:
    Use the term "Proof of concept"
    If you have an error, wait till someone says so and then show the 'feedback' modal (like spellchecking)
        Have the message to nowhere (for now)
    Make the slides SUPER brief (have it be more of a life story)
    "Why didn't you do this?" - "Thats a great challenge"
    "How many keywords have you done?" - "Here is the list of words I have got working"
        "Where did you get that number of keywords?" - "I made a list of keywords"
    Whatever it is, show confidence (NOT "I didn't get that" YES "I achieved the minimum")

    List out your licences: are they safe/not safe?
        Include a copy of the MIT licence - in the source code? Just one line
        Grab the beginning of a bootstrap CDN.
    Networky enough? They don't need to know more than what they see
        Classic 3 tier artitecutre
    Typographically set apart the keywords
    keep it as a '0' for your version when you're in beta
    Data collection? Just show them some random chart. "I looked up let 21 times!"
        Chart.js

    WRITE THE LIST: I estimated to be complete with the javascript language, I would need 120 entries
        This is a moving target
        I set a goal to have the concept complete
    I made this open source because I know this project is bigger than me.
        The more people involved will improve beyond my 
    When you're done, stop talking. Don't wait for them to "end you"
    Stronger beginning:
        The problem has to be personalized - "Wanted to solve this problem"
            Personal story of how you got to here: "Everyone in the tutoring lab has a hard time understanding the syntax"
        First slide after your personal story.

PROBLEMS:
    How should we organize the data? - We need to have different collections for the various parts 
    of a language: (ex. javascriptRegexRules, javascriptStats) How do we oranize these?
        Option 1: Have a database for each language
            Pros: Better oranized and structured, Want to know info about that database? Don't need to query
            Cons: Hard changing between languages...
        Option 2: (Current) Each language has it's name tied to collection
            Pros: Don't have to refactor, No difficulty in changing to language
            Cons: Database has lots of collections, will probably get messy...
        Options 3: One collection type (token/regex/stats), include language property into document
            Pros: Cleaner database that's still flexible
            Cons: Large amount of documents in a collection, heavier processing to retrieve data
        Solution: Option 2 - Don't need to refactor and collections can scale easier