danielesegato

To enable serverless bash completion:

• Install serverless: npm -g serverless
• Append the servereless.bash code to the .bashrc or .bash_profile file in your home directory

This gitst is a fork of https://gist.github.com/davidgf/5bd76141aa70f9ed4d8f716851e68830. It avoid using find .to look for lambda functions: the command, if executed in the root directory or a big directory, can be really bad for performances. It also add subcommand handling for non-functions.

The script instead look for the serverless project file s-project.json starting from the current directory and looking up,

davidgf

_sls()
{
    local cur prev words cword
    COMPREPLY=()
    cur="${COMP_WORDS[COMP_CWORD]}"
    prev="${COMP_WORDS[COMP_CWORD-1]}"
    words="${COMP_WORDS}"

    local COMMANDS=(
        "project"

bendc

// array utils
// =================================================================================================

const combine = (...arrays) => [].concat(...arrays);

const compact = arr => arr.filter(Boolean);

const contains = (() => Array.prototype.includes
  ? (arr, value) => arr.includes(value)
  : (arr, value) => arr.some(el => el === value)

zsup

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

• Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
• Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
• Once documentation has been written, development should commence, and test-driven development is preferred.
• Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
• When a feature is being modified, it should be modified documentation-first.
• When documentation is modified, so should be the tests.