text:
# pytest-cases

*Separate test code from test cases in `pytest`.*

[![Python versions](https://img.shields.io/pypi/pyversions/pytest-cases.svg)](https://pypi.python.org/pypi/pytest-cases/) [![Build Status](https://travis-ci.org/smarie/python-pytest-cases.svg?branch=master)](https://travis-ci.org/smarie/python-pytest-cases) [![Tests Status](https://smarie.github.io/python-pytest-cases/junit/junit-badge.svg?dummy=8484744)](https://smarie.github.io/python-pytest-cases/junit/report.html) [![codecov](https://codecov.io/gh/smarie/python-pytest-cases/branch/master/graph/badge.svg)](https://codecov.io/gh/smarie/python-pytest-cases)

[![Documentation](https://img.shields.io/badge/doc-latest-blue.svg)](https://smarie.github.io/python-pytest-cases/) [![PyPI](https://img.shields.io/pypi/v/pytest-cases.svg)](https://pypi.python.org/pypi/pytest-cases/) [![Downloads](https://pepy.tech/badge/pytest-cases)](https://pepy.tech/project/pytest-cases) [![Downloads per week](https://pepy.tech/badge/pytest-cases/week)](https://pepy.tech/project/pytest-cases) [![GitHub stars](https://img.shields.io/github/stars/smarie/python-pytest-cases.svg)](https://github.com/smarie/python-pytest-cases/stargazers)

!!! success "You can now use `pytest.param` in the argvalues provided to `fixture_union`, `param_fixture[s]` and `parametrize_plus`, just as you do in `pytest`. See [pytest documentation](https://docs.pytest.org/en/stable/example/parametrize.html#set-marks-or-test-id-for-individual-parametrized-test)"

!!! success "New `lazy_value` feature for parametrize, [check it out](#parametrize_plus) !"

!!! warning "Test execution order"
    Installing pytest-cases now has effects on the order of `pytest` tests execution, even if you do not use its features. One positive side effect is that it fixed [pytest#5054](https://github.com/pytest-dev/pytest/issues/5054). But if you see less desirable ordering please [report it](https://github.com/smarie/python-pytest-cases/issues).

Did you ever think that most of your test functions were actually *the same test code*, but with *different data inputs* and expected results/exceptions ?

`pytest-cases` leverages `pytest` and its great<EMAIL_ADDRESS>decorator, so that you can **separate your test cases from your test functions**. For example with `pytest-cases` you can now write your tests with the following pattern:

 * on one hand, the usual `test_xxxx.py` file containing your test functions
 * on the other hand, a new `test_xxxx_cases.py` containing your cases functions

In addition, `pytest-cases` improves `pytest`'s fixture mechanism to support "fixture unions". This is a **major change** in the internal `pytest` engine, unlocking many possibilities such as using fixture references as parameter values in a test function. See [below](#fixture_union).

`pytest-cases` is fully compliant with [pytest-steps](https://smarie.github.io/python-pytest-steps/) so you can create test suites with several steps and send each case on the full suite. See [usage page for details](./usage/advanced/#test-suites-several-steps-on-each-case).

## Installing

```bash
> pip install pytest_cases
```

## Usage - 'Data' cases

### a- Some code to test

Let's consider the following `foo` function under test:

```python
def foo(a, b):
    return a + 1, b + 1
```

### b- Case functions

First we create a `test_foo_cases.py` file. This file will contain *test cases generator* functions, that we will call **case functions** for brevity:

```python
def case_two_positive_ints():
    """ Inputs are two positive integers """
    return dict(a=1, b=2)

def case_two_negative_ints():
    """ Inputs are two negative integers """
    return dict(a=-1, b=-2)
```

In these functions, you will typically either parse some test data files, or generate some simulated test data and expected results.

Case functions **do not have any particular requirement**, apart from their names starting with `case_`. They can return anything that is considered useful to run the associated test.

!!! note "Support for pytest marks"
    Pytest marks such as<EMAIL_ADDRESS>can be used on case functions, the corresponding case will be handled according to the expected behaviour (failed if<EMAIL_ADDRESS>skipped under condition if<EMAIL_ADDRESS>etc.)

### c- Test functions

Then, as usual we write our `pytest` functions starting with `test_`, in a `test_foo.py` file:

```python
from pytest_cases import cases_data
from example import foo

# import the module containing the test cases
import test_foo_cases

@cases_data(module=test_foo_cases)
def test_foo(case_data):
    """ Example unit test that is automatically parametrized with @cases_data """

    # 1- Grab the test case data
    inputs = case_data.get()

    # 2- Use it
    foo(**inputs)
```

*Note: as explained [here](https://smarie.github.io/python-pytest-cases/usage/basics/#cases-in-the-same-file-than-tests), cases can also be located inside the test file.*

As you can see above there are three things that are needed to parametrize a test function with associated case functions:

 * decorate your test function with `@cases_data`, indicating which module contains the cases functions
 * add an input argument to your test function, named `case_data` with optional type hint `CaseData`
 * use that input argument at the beginning of the test function, to retrieve the test data: `inputs = case_data.get()`

Once you have done these three steps, executing `pytest` will run your test function **once for every case function**:

```bash
>>> pytest
============================= test session starts =============================
(...)
<your_project>/tests/test_foo.py::test_foo[case_two_positive_ints] PASSED [ 50%]
<your_project>/tests/test_foo.py::test_foo[case_two_negative_ints] PASSED [ 100%]

========================== 2 passed in 0.24 seconds ==========================
```

### d- Case fixtures

You might be concerned that case data is gathered or created *during* test execution.

Indeed creating or collecting case data is not part of the test *per se*. Besides, if you benchmark your tests durations (for example with [pytest-harvest](https://smarie.github.io/python-pytest-harvest/)), you may want the test duration to be computed without acccounting for the data retrieval time - especially if you decide to add some caching mechanism as explained [here](https://smarie.github.io/python-pytest-cases/usage/advanced/#caching).

It might therefore be more interesting for you to parametrize **case fixtures** instead of parametrizing your test function. Thanks to our new [`@fixture_plus`](#pytest_fixture_plus) decorator, this works exactly the same way than for test functions:

```python
from pytest_cases import fixture_plus, cases_data
from example import foo

# import the module containing the test cases
import test_foo_cases

@fixture_plus
@cases_data(module=test_foo_cases)
def inputs(case_data):
    """ Example fixture that is automatically parametrized with @cases_data """
    # retrieve case data
    return case_data.get()

def test_foo(inputs):
    # Use case data
    foo(**inputs)
```

In the above example, the `test_foo` test does not spend time collecting or generating data. When it is executed, it receives the required data directly as `inputs`. The test case creation instead happens when each `inputs` fixture instance is created by `pytest` - this is done in a separate pytest phase (named "setup"), and therefore is not counted in the test duration.

Note: you can still use `request` in your fixture's signature if you wish to.

## Usage - 'True' test cases

#### a- Case functions update

In the above example the cases were only containing inputs for the function to test. In real-world applications we often need more: we need both inputs **and an expected outcome**.

For this, `pytest_cases` proposes to adopt a convention where the case functions returns a tuple of inputs/outputs/errors. A handy `CaseData` PEP484 type hint can be used to denote that. But of course this is only a proposal, which is not mandatory as we saw above.

!!! note "A case function can return **anything**"
    Even if in most examples in this documentation we chose to return a tuple (inputs/outputs/errors) (type hint `CaseData`), you can decide to return anything: a single variable, a dictionary, a tuple of a different length, etc. Whatever you return will be available through `case_data.get()`.

Here is how we can rewrite our case functions with an expected outcome:

```python
def case_two_positive_ints() -> CaseData:
    """ Inputs are two positive integers """

    ins = dict(a=1, b=2)
    outs = 2, 3

    return ins, outs, None

def case_two_negative_ints() -> CaseData:
    """ Inputs are two negative integers """

    ins = dict(a=-1, b=-2)
    outs = 0, -1

    return ins, outs, None
```

We propose that the "expected error" (`None` above) may contain exception type, exception instances, or callables. If you follow this convention, you will be able to write your test more easily with the provided utility function `unfold_expected_err`. See [here for details](https://smarie.github.io/python-pytest-cases/usage/basics/#handling-exceptions).

### b- Test body update

With our new case functions, a case will be made of three items. So `case_data.get()` will return a tuple. Here is how we can update our test function body to retrieve it correctly, and check that the outcome is as expected:

```python
@cases_data(module=test_foo_cases)
def test_foo(case_data: CaseDataGetter):
    """ Example unit test that is automatically parametrized with @cases_data """

    # 1- Grab the test case data: now a tuple !
    i, expected_o, expected_e = case_data.get()

    # 2- Use it: we can now do some asserts !
    if expected_e is None:
        # **** Nominal test ****
        outs = foo(**i)
        assert outs == expected_o
    else:
        # **** Error tests: see <Usage> page to fill this ****
        pass
```

See [Usage](./usage) for complete examples with custom case names, case generators, exceptions handling, and more.

## `pytest` Goodies

### `--with-reorder`

`pytest` postprocesses the order of the collected items in order to optimize setup/teardown of session, module and class fixtures. This optimization algorithm happens at the `pytest_collection_modifyitems` stage, and is still under improvement, as can be seen in [pytest#3551](https://github.com/pytest-dev/pytest/pull/3551), [pytest#3393](https://github.com/pytest-dev/pytest/issues/3393), [#2846](https://github.com/pytest-dev/pytest/issues/2846)...

Besides other plugins such as [pytest-reorder](https://github.com/not-raspberry/pytest_reorder) can modify the order as well.

This new commandline is a goodie to change the reordering:

 * `--with-reorder normal` is the default behaviour: it lets pytest and all the plugins execute their reordering in each of their `pytest_collection_modifyitems` hooks, and simply does not interact

 * `--with-reorder skip` allows you to restore the original order that was active before `pytest_collection_modifyitems` was initially called, thus not taking into account any reordering done by pytest or by any of its plugins.

### `@fixture_plus`

`@fixture_plus` is similar to `pytest.fixture` but without its `param` and `ids` arguments. Instead, it is able to pick the parametrization from<EMAIL_ADDRESS>marks applied on fixtures. This makes it very intuitive for users to parametrize both their tests and fixtures. As a bonus, its `name` argument works even in old versions of pytest (which is not the case for `fixture`).

Finally it now supports unpacking, see [unpacking feature](#unpack_fixture-unpack_into).

!!! note "`@fixture_plus` deprecation if/when<EMAIL_ADDRESS>supports<EMAIL_ADDRESS>    The ability for pytest fixtures to support the<EMAIL_ADDRESS>annotation is a feature that clearly belongs to `pytest` scope, and has been [requested already](https://github.com/pytest-dev/pytest/issues/3960). It is therefore expected that `@fixture_plus` will be deprecated in favor of `@pytest_fixture` if/when the `pytest` team decides to add the proposed feature. As always, deprecation will happen slowly across versions (at least two minor, or one major version update) so as for users to have the time to update their code bases.

### `unpack_fixture` / `unpack_into`

In some cases fixtures return a tuple or a list of items. It is not easy to refer to a single of these items in a test or another fixture. With `unpack_fixture` you can easily do it:

```python
import pytest
from pytest_cases import unpack_fixture, fixture_plus

@fixture_plus
@pytest.mark.parametrize("o", ['hello', 'world'])
def c(o):
    return o, o[0]

a, b = unpack_fixture("a,b", c)

def test_function(a, b):
    assert a[0] == b
```

Note that you can also use the `unpack_into=` argument of `@fixture_plus` to do the same thing:

```python
import pytest
from pytest_cases import fixture_plus

@fixture_plus(unpack_into="a,b")
@pytest.mark.parametrize("o", ['hello', 'world'])
def c(o):
    return o, o[0]

def test_function(a, b):
    assert a[0] == b
```

And it is also available in `fixture_union`:

```python
import pytest
from pytest_cases import fixture_plus, fixture_union

@fixture_plus
@pytest.mark.parametrize("o", ['hello', 'world'])
def c(o):
    return o, o[0]

@fixture_plus
@pytest.mark.parametrize("o", ['yeepee', 'yay'])
def d(o):
    return o, o[0]

fixture_union("c_or_d", [c, d], unpack_into="a, b")

def test_function(a, b):
    assert a[0] == b
```

### `param_fixture[s]`

If you wish to share some parameters across several fixtures and tests, it might be convenient to have a fixture representing this parameter. This is relatively easy for single parameters, but a bit harder for parameter tuples.

The two utilities functions `param_fixture` (for a single parameter name) and `param_fixtures` (for a tuple of parameter names) handle the difficulty for you:

```python
import pytest
from pytest_cases import param_fixtures, param_fixture

# create a single parameter fixture
my_parameter = param_fixture("my_parameter", [1, 2, 3, 4])

@pytest.fixture
def fixture_uses_param(my_parameter):
    ...

def test_uses_param(my_parameter, fixture_uses_param):
    ...

# -----
# create a 2-tuple parameter fixture
arg1, arg2 = param_fixtures("arg1, arg2", [(1, 2), (3, 4)])

@pytest.fixture
def fixture_uses_param2(arg2):
    ...

def test_uses_param2(arg1, arg2, fixture_uses_param2):
    ...
```

You can mark any of the argvalues with `pytest.mark` to pass a custom id or a custom "skip" or "fail" mark, just as you do in `pytest`. See [pytest documentation](https://docs.pytest.org/en/stable/example/parametrize.html#set-marks-or-test-id-for-individual-parametrized-test).

### `fixture_union`

As of `pytest` 5, it is not possible to create a "union" fixture, i.e. a parametrized fixture that would first take all the possible values of fixture A, then all possible values of fixture B, etc. Indeed all fixture dependencies (a.k.a. "closure") of each test node are grouped together, and if they have parameters a big "cross-product" of the parameters is done by `pytest`.

The topic has been largely discussed in [pytest-dev#349](https://github.com/pytest-dev/pytest/issues/349) and a [request for proposal](https://docs.pytest.org/en/latest/proposals/parametrize_with_fixtures.html) has been finally made.

`fixture_union` is an implementation of this proposal. It is also used by `parametrize_plus` to support `fixture_ref` in parameter values, see [below](#parametrize_plus).

```python
from pytest_cases import fixture_plus, fixture_union

@fixture_plus
def first():
    return 'hello'

@fixture_plus(params=['a', 'b'])
def second(request):
    return request.param

# c will first take all the values of 'first', then all of 'second'
c = fixture_union('c', [first, second])

def test_basic_union(c):
    print(c)
```

yields

```
<...>::test_basic_union[c_is_first] hello   PASSED
<...>::test_basic_union[c_is_second-a] a    PASSED
<...>::test_basic_union[c_is_second-b] b    PASSED
```

As you can see the ids of union fixtures are slightly different from standard ids, so that you can easily understand what is going on. You can change this feature with `ìdstyle`, see [API documentation](./api_reference.md#fixture_union) for details.

You can mark any of the alternatives with `pytest.mark` to pass a custom id or a custom "skip" or "fail" mark, just as you do in `pytest`. See [pytest documentation](https://docs.pytest.org/en/stable/example/parametrize.html#set-marks-or-test-id-for-individual-parametrized-test).

Fixture unions also support unpacking with the `unpack_into` argument, see [unpacking feature](#unpack_fixture-unpack_into).

Fixture unions are a **major change** in the internal pytest engine, as fixture closures (the ordered set of all fixtures required by a test node to run - directly or indirectly) now become trees where branches correspond to alternative paths taken in the "unions", and leafs are the alternative fixture closures. This feature has been tested in very complex cases (several union fixtures, fixtures that are not selected by a given union but that is requested by the test function, etc.). But if you find some strange behaviour don't hesitate to report it in the [issues](https://github.com/smarie/python-pytest-cases/issues) page !

**IMPORTANT** if you do not use `@fixture_plus` but only<EMAIL_ADDRESS>then you will see that your fixtures are called even when they are not used, with a parameter `NOT_USED`. This symbol is automatically ignored if you use `@fixture_plus`, otherwise you have to handle it. Alternatively you can use `@ignore_unused` on your fixture function.

!!! note "fixture unions vs. cases"
    If you're familiar with `pytest-cases` already, you might note that `@cases_data` is not so different than a fixture union: we do a union of all case functions. If one day union fixtures are directly supported by `pytest`, we will probably refactor this lib to align all the concepts.

### `@parametrize_plus`

`@parametrize_plus` is a replacement for<EMAIL_ADDRESS>that allows you to include references to fixtures and to value-generating functions in the parameter values.

 - Simply use `fixture_ref(<fixture>)` in the parameter values, where `<fixture>` can be the fixture name or fixture function.
 - if you do not wish to create a fixture, you can also use `lazy_value(<function>)`
 - Note that when parametrizing several argnames, both `fixture_ref` and `lazy_value` can be used *as* the tuple, or *in* the tuple. Several `fixture_ref` and/or `lazy_value` can be used in the same tuple, too.

For example, with a single argument:

```python
import pytest
from pytest_cases import parametrize_plus, fixture_plus, fixture_ref, lazy_value

@pytest.fixture
def world_str():
    return 'world'

def whatfun():
    return 'what'

@fixture_plus
@parametrize_plus('who', [fixture_ref(world_str),
                          'you'])
def greetings(who):
    return 'hello ' + who

@parametrize_plus('main_msg', ['nothing',
                               fixture_ref(world_str),
                               lazy_value(whatfun),
                               fixture_ref(greetings)])
@pytest.mark.parametrize('ending', ['?', '!'])
def test_prints(main_msg, ending):
    print(main_msg + ending)
```

yields the following

```bash
> pytest -s -v
collected 10 items
test_prints[main_msg_is_nothing-?] PASSED       [ 10%]nothing?
test_prints[main_msg_is_nothing-!] PASSED       [ 20%]nothing!
test_prints[main_msg_is_world_str-?] PASSED     [ 30%]world?
test_prints[main_msg_is_world_str-!] PASSED     [ 40%]world!
test_prints[main_msg_is_whatfun-?] PASSED       [ 50%]what?
test_prints[main_msg_is_whatfun-!] PASSED       [ 60%]what!
test_prints[main_msg_is_greetings-who_is_world_str-?] PASSED [ 70%]hello world?
test_prints[main_msg_is_greetings-who_is_world_str-!] PASSED [ 80%]hello world!
test_prints[main_msg_is_greetings-who_is_you-?] PASSED [ 90%]hello you?
test_prints[main_msg_is_greetings-who_is_you-!] PASSED [100%]hello you!
```

You can also mark any of the argvalues with `pytest.mark` to pass a custom id or a custom "skip" or "fail" mark, just as you do in `pytest`. See [pytest documentation](https://docs.pytest.org/en/stable/example/parametrize.html#set-marks-or-test-id-for-individual-parametrized-test).

As you can see in the example above, the default ids are a bit more explicit than usual when you use at least one `fixture_ref`. This is because the parameters need to be replaced with a fixture union that will "switch" between alternative groups of parameters, and the appropriate fixtures referenced. As opposed to `fixture_union`, the style of these ids is not configurable for now, but feel free to propose alternatives in the [issues page](https://github.com/smarie/python-pytest-cases/issues). Note that this does not happen if you only use `lazy_value`s, as they do not require to create a fixture union behind the scenes.

Another consequence of using `fixture_ref` is that the priority order of the parameters, relative to other standard `pytest.mark.parametrize` parameters that you would place on the same function, will get impacted. You may solve this by replacing your other<EMAIL_ADDRESS>calls with `param_fixture`s so that all the parameters are fixtures (see [above](#param_fixtures).)

### passing a `hook`

As per version `1.14`, all the above functions now support passing a `hook` argument. This argument should be a callable. It will be called everytime a fixture is about to be created by `pytest_cases` on your behalf. The fixture function is passed as the argument of the hook, and the hook should return it as the result.

You can use this fixture to better understand which fixtures are created behind the scenes, and also to decorate the fixture functions before they are created. For example you can use `hook=saved_fixture` (from [`pytest-harvest`](https://smarie.github.io/python-pytest-harvest/)) in order to save the created fixtures in the fixture store.

## Main features / benefits

 * **Separation of concerns**: test code on one hand, test cases data on the other hand. This is particularly relevant for data science projects where a lot of test datasets are used on the same block of test code.

 * **Everything in the test or in the fixture**, not outside. A side-effect of<EMAIL_ADDRESS>is that users tend to create or parse their datasets outside of the test function. `pytest_cases` suggests a model where the potentially time and memory consuming step of case data generation/retrieval is performed *inside* the test node or the required fixture, thus keeping every test case run more independent. It is also easy to put debug breakpoints on specific test cases.

 * **Easier iterable-based test case generation**. If you wish to generate several test cases using the same function, `@cases_generator` makes it very intuitive to do so. See [here](./usage#case-generators) for details.

 * **User-friendly features**: easily customize your test cases with friendly names, reuse the same cases for different test functions by tagging/filtering, and more... See [Usage](./usage) for details.

## See Also

 - [pytest documentation on parametrize](https://docs.pytest.org/en/latest/parametrize.html)
 - [pytest documentation on fixtures](https://docs.pytest.org/en/latest/fixture.html#fixture-parametrize)
 - [pytest-steps](https://smarie.github.io/python-pytest-steps/)
 - [pytest-harvest](https://smarie.github.io/python-pytest-harvest/)

### Others

*Do you like this library ? You might also like [my other python libraries](https://github.com/smarie/OVERVIEW#python)*

## Want to contribute ?

Details on the github page: [https://github.com/smarie/python-pytest-cases](https://github.com/smarie/python-pytest-cases)


text:
---
title: '30 60 90 Days Gamified Sales Training Plan'
og_title: 30 60 90 Days Gamified Sales Training Plan
description: Plan and execute a perfect new hire sales training program with this 30-60-90 day plan
og_description: Plan and execute a perfect new hire sales training program with this 30-60-90 day plan
categories: ["ACM"]
id: 64
author:
  name: SmartWinnr
  email<EMAIL_ADDRESS>weight: -64
slug: "/30-60-90-days-gamified-sales-training-plan"
featured_image: "/images/blog-64/64.30-60-90-days-gamified-sales-training-plan.jpg"
isFeatured: false
date: '2020-01-23T10:00:32+08:00'
tags: ["On-boarding", "Sales Training"]
relatedBlogs : ["Pre-boarding Plan for new hires", "The Ultimate Sales Onboarding Checklist", "Top 10 CEOs who started as Sales Reps"]
---

Ask yourself, is your new hire training everything it needs to be to prepare your employees for today’s business challenges? If you have a feeling that your new hire training could be even a little bit better, consider these sobering statistics:

* Top executives say that “cutting the time it takes for new reps to close their first deals” is the number one challenge holding their sales organizations back.

* About 3 in 5 sales reps don’t fully ramp up for at least seven months – and about 1 in 5 takes more than a year to gain the skills and behaviors needed to succeed.

The solution to this is planning and executing a perfect new hire training program that helps in quickly ramping up your new hires to close deals.

Why is a new hire sales training program important:
A well-planned and an all-rounded new hire training program enables your sales reps to:

* Understand how their department and your company operates

* Learn what guidelines you use and policies you enforce

* Set up workstations with necessary tools and technology

* Familiarize themselves with their position’s requirements

To help you build this perfect training program, here we brought a proven and easy-to-execute model that has been used by many successful companies. This model breaks down into 3 simple phases:

* 1 - 30 days: Learn

* 30 - 60 days: Build

* 60 - 90 days: Do

### **Month #1: 1 - 30 days (Learn)**

The first month should be about the new hires getting started on the right foot. New hires should emerge from this month with knowledge of the product, pricing, competition, and existing collateral.

This is an extremely crucial phase in the new hire training as the employees will be exposed to a lot of new and crucial information. So, classroom training and seminars alone are not enough. In order to help them retain all the information that they learn in the classroom, supplement your classroom training with a  digital sales training platform. This training platform essentially breaks down the complex lengthy content into bite-sized information. This micro-content is sent to the new hires at regular intervals through an app. This helps in reinforcing whatever they have learned in their training sessions. Also, it enables the reps to access this information whenever and wherever they want. Also, you can conduct quizzes through the app to help them recall crucial information.

At the end of 30 days, assess your new hires by giving them a task to complete. This helps in determining how effective your first-month training was and how many of your new reps qualify to enter the second level of training.

Consider the experience level of all your reps before deciding on the task in order to keep it fair. Put the details of the task clearly in writing and send it to the new hires. Here is what to mention:

* What deliverables are expected?

* How success will be measured?

* Any resources that will help the new hires get his or her job done

**Example task**:

**Task**: Be able to concisely and effectively communicate the value of our product.

**Deliverable / Measurement of Success**: Pass the company “Pitch Competition,” which you will present in front of the Board of Advisors.

**Resources**: (Link to Pitch Deck Instructions)

### **Month #2: Day 31 - Day 60 (Build)**

Month #2’s focus should be on putting month #1’s learnings into action. It’s about building practical knowledge around the rep’s theoretical knowledge. Expectations should be reasonable, depending on your new hire’s level of experience. Take this opportunity to expand their company/product knowledge and selling skills through role-plays and mock demos.

 Leverage video coaching  here to automate this process. Make your reps record a video articulating a sales scenario and upload it. The trainers or managers can then review this video and provide their feedback. This instantly helps the reps to rectify their mistakes and improve their performance. This provides a safe environment for the reps to practice and prepare for the real sales world.

Similar to the previous month, set a task at the end of this month as well. This task should focus on developing their strategic planning and implementation. Here is an example of it:

**Task**: Speak to two existing customers in your territory and learn their pain points and favorite parts of the product.

**Deliverable / Measurement of Success**: A documented report talking about the pain points of the customers, parts of the product that they love and other findings.

**Resources**: The customer marketing and account management teams can help to connect with the customers

### **Month #3: Day 61 - Day 90 (Do)**

The third month should see salespeople springing into action. Goals should start to get more aggressive, as the rep should be reasonably armed for success at this point. This is the correct time to give the new hires some real-world sales exposure by making them connect with customers and partners.

In this phase create multiple tasks for the reps and set them as targets to be achieved throughout the third month. They should be measured according to these targets/KPIs, and they should understand they will be judged on outcomes as much as thinking and process. You can make it interesting by gamifying the process of achieving targets for them. The reps who achieve the highest target will be recognized and rewarded. Here are some example tasks that you can set in this phase:

**Task #1**: Reach out to ## of new contacts, converting 50% into the next stage of the buyer’s journey.

**Deliverable / Measurement of Success**: ## New Opportunities

**Resources**: The territory account executive and help the new hires to make new connections.

**Task #2**: Close one deal.

**Deliverable / Measurement of Success**: Number of opportunities closed-won or the number of opportunities that have come close to closed-won.

**Resources**: The territory account executive can help the new hires with the paperwork and negotiations.

Want to gamify your onboarding?

Games for new Hire Onboarding

Gamified Onboarding: The Secret Sauce to Effectively Onboard Millennials and Gen Z

Looking for strategies to make your new hires productive very quickly?

5 Strategies to Reduce Ramp-up Time for Your New Sales Recruits

Want to know how sales enablement helps to drive the new hire onboarding successfully?

How can sales enablement help to drive new hire onboarding?

### **Want to know how you can partner with your HR to streamline your onboarding process?**

**Read:** How to partner with HR to streamline your onboarding process?

Customer Success Story: Poly

Learn how Poly runs its new hire sales training program successfully through SmartWinnr

Looking for a sales gamification software that will run your new hire onboarding with gamification?

Explore SmartWinnr’s Learning and Gamification features and learn how to run a gamified new hire sales onboarding program that's repeatable, and takes only 10 min of your time.

Curious to learn more about it? Book a demo today!

license: MIT

repository: smartwinnr/site-smartwinnr

branch_name: refs/heads/master

extension: md

gha_language: CSS

gha_license_id: MIT

license_type: permissive

repo_name: smartwinnr/site-smartwinnr


text:
---
layout: work
title: Research
slug: /research
---
My research focuses on establishing whole-brain functional networks from
neuroimaging data (e.g. functional MRI, PET) and studying the structures of these networks.
Here are a few examples of what I have been doing:

  - **Multi-task co-activation patterns of young adolescents.**
    Multi-task co-activation patterns obtained from task-based functional MRI can reveal robust functional networks of the brain.
    Here, I am looking at these co-activation patterns in young adolescents and how they are related to risk of developing addictions. I am also studying how these patterns change with age.

  - **Metabolic networks of Alzheimer's disease.**
    Changes in the structure of whole-brain functional networks can be an indicator of diseases. In this project, I constructed
    brain metabolic networks from FDG-PET data and compared their structures between controls and Alzheimer's disease patients.

  - **Resting-state connectivity of healthy young adults.**
    Resting-state connectivity networks can be constructed from resting-state function MRI (rs-fMRI) data. The structure of this network
    is different between individuals and between different time points. I studied how the modular structure of these resting-state networks correlate with
    performances of a few cognitive tasks in healthy young adults.

license: ISC


text:
# Memory Maiden Events

| ID    | Name                    |
| ----- | ----------------------- |
| 10388 | Memory Maiden Mandara   |
| 10389 | Memory Maiden Shambala  |
| 10390 | Memory Maiden Jina      |
| 10391 | Memory Maiden Exilio    |
| 10392 | Vishnites Memory Maiden |
| 10393 | Brahman Memory Maiden   |
| 10394 | Shivan Memory Maiden    |

---

[![ko-fi](https://www.ko-fi.com/img/githubbutton_sm.svg)](https://ko-fi.com/T6T41JKMI)

source: `{{ page.path }}`

repository: slvdrvlc/Tantra

repo_name: slvdrvlc/Tantra


text:
# Contribute to GoShimmer

This document describes how to contribute to GoShimmer.

We encourage everyone with knowledge of IOTA technology to contribute.

Thanks! :heart:

Do you have a question :question:

If you have a general or technical question, you can use one of the following resources instead of submitting an issue:

- [**Developer documentation:**](https://docs.iota.org/) For official information about developing with IOTA technology
- [**Discord:**](https://discord.iota.org/) For real-time chats with the developers and community members
- [**IOTA cafe:**](https://iota.cafe/) For technical discussions with the Research and Development Department at the IOTA Foundation
- [**StackExchange:**](https://iota.stackexchange.com/) For technical and troubleshooting questions

Ways to contribute :mag:

To contribute to GoShimmer on GitHub, you can:

- Report a bug
- Suggest a new feature
- Build a new feature
- Contribute to the documentation

Report a bug :bug:

This section guides you through reporting a bug. Following these guidelines helps maintainers and the community understand the bug, reproduce the behavior, and find related bugs.

### Before reporting a bug

Please check the following list:

- **Do not open a GitHub issue for [security vulnerabilities](SECURITY.MD)**, instead, please contact us at [security@iota.org](mailto:security@iota.org).

- **Ensure the bug was not already reported** by searching on GitHub under [**Issues**](https://github.com/iotaledger/goshimmer/issues). If the bug has already been reported **and the issue is still open**, add a comment to the existing issue instead of opening a new one.

**Note:** If you find a **Closed** issue that seems similar to what you're experiencing, open a new issue and include a link to the original issue in the body of your new one.

### Submitting A Bug Report

To report a bug, [open a new issue](https://github.com/iotaledger/goshimmer/issues/new), and be sure to include as many details as possible, using the template.

**Note:** Minor changes such as fixing a typo can but do not need an open issue.

If you also want to fix the bug, submit a [pull request](#pull-requests) and reference the issue.

Suggest a new feature :bulb:

This section guides you through suggesting a new feature. Following these guidelines helps maintainers and the community collaborate to find the best possible way forward with your suggestion.

### Before suggesting a new feature

**Ensure the feature has not already been suggested** by searching on GitHub under [**Issues**](https://github.com/iotaledger/goshimmer/issues).

### Suggesting a new feature

To suggest a new feature, talk to the IOTA community and IOTA Foundation members in the #goshimmer-discussion channel on [Discord](https://discord.iota.org/).

If the GoShimmer team approves your feature, the team will create an issue for it.

Build a new feature :hammer:

This section guides you through building a new feature. Following these guidelines helps give your feature the best chance of being approved and merged.

### Before building a new feature

Make sure to discuss the feature in the #goshimmer-discussion channel on [Discord](https://discord.iota.org/).

Otherwise, your feature may not be approved at all.

### Building a new feature

To build a new feature, check out a new branch based on the `master` branch, and be sure to consider the following:

- If the feature has a public facing API, make sure to document it, using Godoc code comments

Contribute to the documentation :black_nib:

The GoShimmer documentation is hosted on https://docs.iota.org, which is built from content in the [documentation](https://github.com/iotaledger/documentation) repository.

Please see the [guidelines](https://github.com/iotaledger/documentation/CONTRIBUTING.md) on the documentation repository for information on how to contribute to the documentation.

Pull requests :mega:

This section guides you through submitting a pull request (PR). Following these guidelines helps give your PR the best chance of being approved and merged.

### Before submitting a pull request

When creating a pull request, please follow these steps to have your contribution considered by the maintainers:

- A pull request should have exactly one concern (for example one feature or one bug). If a PR addresses more than one concern, it should be split into two or more PRs.

- A pull request can be merged only if it references an open issue

    **Note:** Minor changes such as fixing a typo can but do not need an open issue.

### Submitting a pull request

The following is a typical workflow for submitting a new pull request:

1. Fork this repository
2. Create a new branch based on your fork. For example, `git checkout -b fix/my-fix` or ` git checkout -b feat/my-feature`.
3. Commit changes and push them to your fork
4. Run the `go fmt` command to make sure your code is well formatted
5. Target your pull request to be merged with `develop`

If all [status checks](https://help.github.com/articles/about-status-checks/) pass, and the maintainer approves the PR, it will be merged.

**Note:** Reviewers may ask you to complete additional work, tests, or other changes before your pull request can be approved and merged.

Code of Conduct :clipboard:

This project and everyone participating in it is governed by the [IOTA Code of Conduct](CODE_OF_CONDUCT.md).

repository: iotaledger/goshimmer

branch_name: refs/heads/develop

gha_language: Go

repo_name: iotaledger/goshimmer


text:
# tsu [![npm Version](http://img.shields.io/npm/v/tsu.svg?style=flat)](https://www.npmjs.org/package/tsu) [![Build Status](https://img.shields.io/travis/yuanqing/tsu.svg?style=flat)](https://travis-ci.org/yuanqing/tsu) [![Coverage Status](https://img.shields.io/coveralls/yuanqing/tsu.svg?style=flat)](https://coveralls.io/r/yuanqing/tsu)

> Utilities and functional wrappers over [`through2`](https://github.com/rvagg/through2).

## API

```js
var tsu = require('tsu');
```

All methods take an optional `opts` object which is passed to the `stream.Transform`. `opts` take the following keys:
- `objectMode` — Defaults to `true`.
- `toString` — Defaults to `true`. Converts each [`Buffer`](https://nodejs.org/api/buffer.html#buffer_class_buffer) in the stream to a string. Set to `false` to disable this behaviour.

### Utilities

- [`source`](#tsusourceopts--x)
- [`through`](#tsuthroughopts--transform-flush)
- [`flush`](#tsuflushopts--cb)
- [`noop`](#tsunoopopts)
- [`toArray`](#tsutoarrayopts--cb)

### Functional

- [`each`](#tsueachopts--fn)
- [`map`](#tsumapopts--fn)
- [`filter`](#tsufilteropts--fn)
- [`fold`](#tsufoldopts--acc-fn-cb)
- [`sort`](#tsusortopts-compare)

Each functional method also has a `.ctor` method (eg. `tsu.sort.ctor`) that returns a *constructor* for the custom `stream.Transform`.

---

#### tsu.through([opts, ] transform, [flush])

Convenience method that returns a [through](https://github.com/rvagg/through2) stream.

[↩](#api)

#### tsu.noop([opts])

Convenience method that returns a no-op through stream.

```js
var stream = tsu.noop();
```

[↩](#api)

#### tsu.source([opts, ] x)

Returns a [`stream.Readable`](https://nodejs.org/docs/latest/api/stream.html#stream_class_stream_readable) containing the elements of `x` or that returned by `x`. `x` can be an object or array of objects. `x` can also be a function that returns an object or array of objects.

```js
var fromArray = tsu.source(['x', 'y', 'z']);

var fromFunction = tsu.source(function() {
  return ['x', 'y', 'z'];
});
```

[↩](#api)

#### tsu.flush([opts, ] cb)

Returns a through stream where `transform` is a no-op, with the given `cb` called just before the stream ends. Call `this.push(chunk)` in `cb` to pass a chunk down the stream.

```js
var stream = tsu.source(['x', 'y', 'z']);
stream.pipe(tsu.flush(function() {
  this.push('foo');
})).pipe(tsu.toArray(function(arr) {
  console.log(arr);
  //=> [ 'x', 'y', 'z', 'foo' ]
}));
```

[↩](#api)

#### tsu.toArray([opts, ] cb)

Accumulates all the items in the stream into an array, and calls `cb` with said array. The signature of `cb` is `(arr)`. Call `this.push(chunk)` in `cb` to pass a chunk down the stream.

```js
var stream = tsu.source(['x', 'y', 'z']);
stream.pipe(tsu.toArray(function(arr) {
  console.log(arr);
  //=> [ 'x', 'y', 'z' ]
}));
```

[↩](#api)

#### tsu.each([opts, ] fn)

Calls `fn` with each item in the stream. The signature of `fn` is `(val, i)`. Call `this.push(chunk)` in `fn` to pass a chunk down the stream.

```js
var stream = tsu.source(['x', 'y', 'z']);
stream.pipe(tsu.each(function(val, i) {
  this.push(val); // pass `val` down the stream
  console.log(val, i);
  //=> 'x', 0
  //=> 'y', 1
  //=> 'z', 2
})).pipe(tsu.toArray(function(arr) {
  console.log(arr);
  //=> [ 'x', 'y', 'z' ]
}));
```

[↩](#api)

#### tsu.map([opts, ] fn)

Calls `fn` with each item in the stream. The signature of `fn` is `(val, i)`. `fn` must return the value to which `val` is to be mapped. Call `this.push(chunk)` in `fn` to pass a chunk down the stream.

```js
var stream = tsu.source(['x', 'y', 'z']);
stream.pipe(tsu.map(function(val, i) {
  this.push('foo'); // pass 'foo' down the stream
  return i;         // map values to their indices
})).pipe(tsu.toArray(function(arr) {
  console.log(arr);
  //=> [ 'foo', 0, 'foo', 1, 'foo', 2 ]
}));
```

[↩](#api)

#### tsu.filter([opts, ] fn)

Calls `fn` with each item in the stream. The signature of `fn` is `(val, i)`. `fn` must return a `falsy` value to remove `val` from the stream. Call `this.push(chunk)` in `fn` to pass a chunk down the stream.

```js
var stream = tsu.source(['x', 'y', 'z']);
stream.pipe(tsu.filter(function(val, i) {
  this.push('foo'); // pass 'foo' down the stream
  return i > 0;     // remove 'x' from the stream
})).pipe(tsu.toArray(function(arr) {
  console.log(arr);
  //=> [ 'foo', 'foo', 'y', 'foo', 'z' ]
}));
```

[↩](#api)

#### tsu.fold([opts, ] acc, fn, cb)

Calls `fn` with the `acc` accumulator and each item in the stream. The signature of `fn` is `(acc, val, i)`. `fn` must return the new value of `acc`.

Calls `cb` with the final value of `acc`.

Call `this.push(chunk)` in `fn` or `cb` to pass a chunk down the stream.

```js
var stream = tsu.source(['x', 'y', 'z']);
stream.pipe(tsu.fold({}, function(acc, val, i) {
  this.push('foo'); // pass 'foo' down the stream
  acc[val] = i;     // key is `val`, value is `i`
  return acc;
}, function(acc) {
  this.push(acc);   // pass `acc` down the stream
  console.log(acc);
  //=> { x: 0, y: 1, z: 2 }
})).pipe(tsu.toArray(function(arr) {
  console.log(arr);
  //=> [ 'foo', 'foo', 'foo', { x: 0, y: 1, z: 2 } ]
}));
```

[↩](#api)

#### tsu.sort([opts, compare])

Accumulates the items in the stream into an array, sorts the array using the `compare` function, before passing the sorted items back into the stream.

```js
var stream = tsu.source([1, 3, 2]);
stream.pipe(tsu.sort(function(x, y) {
  return x > y ? -1 : 1;
})).pipe(tsu.toArray(function(arr) {
  console.log(arr);
  //=> [ 3, 2, 1 ]
}));
```

[↩](#api)

## Installation

Install via [npm](https://npmjs.com/):

```
$ npm i --save tsu
```

## Changelog

- 0.0.1
  - Initial release

## License

[MIT](LICENSE.md)

repository: yuanqing/tsu

repo_name: yuanqing/tsu


text:
## Contributing

### Adding a new plugin to support (when approved in the next ECMAScript version)

#### Update [`pluginFeatures.js`](/data/pluginFeatures.js)

Example:

In you were going to add `**` which is in ES2016:

Find the relevant entries on [compat-table](kangax.github.io/compat-table/):

`exponentiation (**) operator`

Find the corresponding babel plugin:

`transform-exponentiation-operator`

Add add them in this structure:

```js
// es2016
"transform-exponentiation-operator": {
  features: [
    "exponentiation (**) operator",
  ],
},
```

#### Update [`plugins.json`](/data/plugins.json)

Until `compat-table` is a standalone npm module for data we are using the git url

`"compat-table": "github:kangax/compat-table#gh-pages",`

So we update and then run `npm run build-data`. If there are no changes, then `plugins.json` will be the same.

repository: jaruserickson/ytmusic-react

repo_name: jaruserickson/ytmusic-react


text:
## Amazon ECS Local Container Endpoints

A container that provides local versions of the [ECS Task IAM Roles endpoint](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) and the [ECS Task Metadata Endpoints](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint.html). This project will help you test applications locally before you deploy to ECS/Fargate.

This repository contains the source code for the project. To use it, pull the [amazon/amazon-ecs-local-container-endpoints:latest image from Docker Hub](https://hub.docker.com/r/amazon/amazon-ecs-local-container-endpoints/).

## Tutorial

[A Guide to Locally Testing Containers with Amazon ECS Local Endpoints and Docker Compose](https://aws.amazon.com/blogs/compute/a-guide-to-locally-testing-containers-with-amazon-ecs-local-endpoints-and-docker-compose/)

## Setting Up Networking

ECS Local Container Endpoints supports 3 endpoints:
* The [ECS Task IAM Roles endpoint](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html)
* The [Task Metadata V2 Endpoint](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v2.html)
* The [Task Metadata V3 Endpoint](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-metadata-endpoint-v3.html)

The Task Metadata V2 and Credentials endpoints require the Local Endpoints container to be able to receive requests made to the special IP Address, `<IP_ADDRESS>`.

There are two methods to achieve this.

#### Option 1: Use a User Defined Docker Bridge Network (Recommended)

If you launch containers into a custom [bridge network](https://docs.docker.com/network/bridge/), you can specify that the ECS Local Endpoints container will receive `<IP_ADDRESS>` as its IP address in the network. The endpoints will only be reachable inside this network, so all your containers must run inside of it. The [example Docker Compose file](examples/docker-compose.yml) in this repository shows how to create this network using Compose.

This method is the recommended way of using ECS Local Container Endpoints.

#### Option 2: Set up iptables rules

If you use Linux, then you can set up routing rules to forward requests for `<IP_ADDRESS>`. This is the option used in production ECS, as noted in the [documentation](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html). The following commands must be run to set up routing rules:

```
sudo sysctl -w net.ipv4.conf.all.route_localnet=1
sudo iptables -t nat -A PREROUTING -p tcp -d <IP_ADDRESS> --dport 80 -j DNAT --to-destination <IP_ADDRESS>:51679
sudo iptables -t nat -A OUTPUT -d <IP_ADDRESS> -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 51679
sudo iptables-save
```

These commands enable local routing, and create a rule to forward packets sent to `<IP_ADDRESS>:80` to `<IP_ADDRESS>:51679`.

Once you set up these rules, you can run the Local Endpoints container as follows:

```
docker run -d -p 51679:51679 \
-v /var/run:/var/run \
-v $HOME/.aws/:/home/.aws/ \
-e "ECS_LOCAL_METADATA_PORT=51679" \
--name ecs-local-endpoints \
amazon/amazon-ecs-local-container-endpoints:latest
```

## Configuration

### Credentials

The ECS Local Endpoints container uses the AWS SDK for Go, and thus it supports all of its [methods of configuration](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html). We recommend providing credentials via an AWS CLI Profile. To do this, mount `$HOME/.aws/` ([`%UserProfile%\.aws` on Windows](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)) into the container. As shown in the example Compose file, the container path of the volume should be `/home/.aws/` because the environment variable `HOME` is set to `/home` in the image. This way, inside the container, the SDK will be able to find credentials at `$HOME/.aws/`. To use a non-default profile, set the `AWS_PROFILE` environment variable on the Local Endpoints container.

### Docker

Local Endpoints responds to Metadata requests with real data about the containers running on your machine. In order to do this, you must mount the [Docker socket](https://docs.docker.com/engine/reference/commandline/dockerd/#daemon-socket-option) into the container. Make sure the Local Endpoints container is given a volume with source path `/var/run` and container path `/var/run`.

### Environment Variables

General Configuration:
* `ECS_LOCAL_METADATA_PORT` - Set the port that the container listens at. The default is `80`.

Task Metadata Configuration: while Local Endpoints returns real runtime information obtained from Docker in metadata requests, some values have no relevance locally and are mocked:
* `CLUSTER_ARN` - Set the 'cluster' name which is returned in Task Metadata responses. Default: `ecs-local-cluster`.
* `TASK_ARN` - Set ARN of the mock local 'task' which your containers will appear to be part of in Task Metadata responses. Default: `arn:aws:ecs:us-west-2:111111111111:task/ecs-local-cluster/37e873f6-37b4-42a7-af47-eac7275c6152`.
* `TASK_DEFINITION_FAMILY` - Set family name for the mock task definition which your containers will appear to be part of in Task Metadata responses. Default: `esc-local-task-definition`.
* `TASK_DEFINITION_REVISION` - Set the Task Definition revision. Default: `1`.

## Features

### Vend Credentials to Containers

The AWS CLI, and all of the AWS SDKs, will look for the environment variable `AWS_CONTAINER_CREDENTIALS_RELATIVE_URI` as part of their [default credential provider chain](https://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/credentials.html#credentials-default).

If the variable exists, then the SDKs will try to obtain credentials by making requests to `http://<IP_ADDRESS>$AWS_CONTAINER_CREDENTIALS_RELATIVE_URI`. The ECS Agent injects this environment variable into containers running on ECS, and responds to requests at the endpoint. This is how [IAM Roles for Tasks](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html) is implemented under the hood.

You can set AWS_CONTAINER_CREDENTIALS_RELATIVE_URI to two different values on your application container:
* `"/creds"` - With this value, Local Endpoints returns temporary credentials obtained by calling [sts:GetSessionToken](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_request.html#stsapi_comparison). These credentials will have the same permissions as the base credentials given to the Local Endpoints container.
* `"/role/{role name}"` - With this value, your application container receives credentials obtained via assuming the given role name. This could be a Task IAM Role, or it could be any other IAM Role.

**Note:** *We do not recommend using production credentials or production roles when testing locally. Modifying the trust policy of a production role changes its security boundary. More importantly, using credentials with access to production when testing locally could lead to accidental changes in your production account. We recommend using a separate account for testing.*

If you use the second option, make sure your IAM Role contains the following trust policy:
```
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "ARN of your IAM User/identity"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
```

You can obtain the ARN of your local IAM identity by running:
```
aws --profile default sts get-caller-identity
```

### Metadata

For both V2 and V3, Local Endpoints defines a local 'task' as all containers running in a single Docker Compose project. If your container is running outside of Compose, then all currently running containers on your machine will be considered to be part of one local 'task'.

#### Task Metadata V2

No additional configuration is needed beyond that which is mentioned in the [Configuration](#configuration) section.

#### Task Metadata V3

V3 Metadata uses the `ECS_CONTAINER_METADATA_URI` environment variable. Unlike V2 metadata and Credentials, the IP address does not have to be `<IP_ADDRESS>`. If you only use V3 metadata, then the Local Endpoints container could listen at any IP address. If you choose this option, replace the IP address in the following examples.

In most cases, you can set `ECS_CONTAINER_METADATA_URI` to `http://<IP_ADDRESS>/v3`.

However, in a few cases, this will not work. This is because the Local Endpoints container needs to be able to determine which container a request for V3 metadata came from. Local Endpoints attempts to use the IP address in the request to determine this. If you use the [example Docker Compose file](examples/docker-compose.yml) with a bridge network, then this IP lookup will work. However, if you use different network settings, then the Local Endpoints will not be able to determine which container a request came from. In this case, set `ECS_CONTAINER_METADATA_URI` to `http://<IP_ADDRESS>/v3/containers/{container name}`. The value for `container name` can be any unique substring of your container's name. By setting a custom request URL, the Local Endpoints container can determine which container a request came from.

## License

This library is licensed under the Apache 2.0 License.


text:
# Machine Learning
Awesome Lists of Machine Learning

## Common
* [Coding Train, Examples and experiments around ML for upcoming Coding Train videos](https://github.com/CodingTrain/Machine-Learning)
* [Deep Learning list by ChristosChristofidis, A curated list of awesome Deep Learning tutorials, projects and communities](https://github.com/ChristosChristofidis/awesome-deep-learning)
* [Machine Learning on Source Code, Cool links & research papers related to Machine Learning applied to source code](https://github.com/src-d/awesome-machine-learning-on-source-code)
* [Monthly Series - Machine Learning Top 10 Open Source Projects from MyBridge](https://github.com/Mybridge/machine-learning-open-source)

## Supervised Learning
* [Everything on Recurrent neural network](https://github.com/kjw0612/awesome-rnn)

## Unsupervised Learning

## Courses
* [Machine Learning - Tom Mitchell](http://www.cs.cmu.edu/~tom/10701_sp11/)
* [Linear Algebra - Prof. Gilbert Strang](https://ocw.mit.edu/courses/mathematics/18-06sc-linear-algebra-fall-2011/index.htm)
* [Multivariable Calculus - Prof. Denis Auroux](https://ocw.mit.edu/courses/mathematics/18-02-multivariable-calculus-fall-2007/)
* [Single Variable Calculus - Prof. David Jerison](https://ocw.mit.edu/courses/mathematics/18-01sc-single-variable-calculus-fall-2010/)

## Books
* [Deep Learning - Ian Goodfellow and Yoshua Bengio and Aaron Courville](https://www.deeplearningbook.org/)

repository: AwesomeBay/machine-learning

repo_name: AwesomeBay/machine-learning


text:
# Signstar

Provide a secure way to sign packages, arch iso's and pacman databases in an enclave.

## Requirements

- simple auditable and memory safe non-interpreted language aka rust
- runs as login shell accepting stdin and outputting a signature to stdout
- sandbox the whole process including seccomp filters
- simple logging facility: user, hash of input, date
- avoid any shellout and writing to harddisc if possible
- must not be possible to do anything else than signing an artifact###

## Threat model

### Obtaining GPG key

- Prevent extraction of the key by using a GPG smartcard or TPM.

### Unauthorized signing

- Restrict network access to a specific server to reduce exposure
- Restrict ssh access to very specific keys
- Restrict ssh key access to a dedicated user

### Considerations

- Think about ways to isolate inputs and not allow users/packagers to sign arbitrary date. However this will require sophisticated changes as repo database and package files can easily be changed before sending to the signing server. We would need to restrict it should tooling and workflow similar

## Architecture

For signing a dedicated user is set up on a secure enclave which only allows ssh logins from a specific server. A dedicated user on the source server can ssh into the signing server and retrieve a signed artefact back.

```bash
ssh<EMAIL_ADDRESS>< core.db.tar.xz > core.db.tar.xz.sig
```

The sshd_config is configured as:

```
Match user signer
    ForceCommand /usr/bin/signstar
```

repository: msgpo/signstar

repo_name: msgpo/signstar


text:
#Change Log
This project adheres to [Semantic Versioning](http://semver.org/).

This CHANGELOG follows the format listed at [Keep A Changelog](http://keepachangelog.com/)

## Unreleased

## 0.0.1 2016-02-06

- initial release

[Unreleased]: https://github.com/sensu-plugins/sensu-plugins-mailgun/compare/0.0.1...HEAD

repository: brendangibat/sensu-plugins-mailgun

repo_name: brendangibat/sensu-plugins-mailgun


text:
Given an integer n, find the minimal k such that

k = m! (where m! = 1 * 2 * ... * m) for some integer m;
k >= n.
In other words, find the smallest factorial which is not less than n.

Example

For n = 17, the output should be
leastFactorial(n) = 24.

17 < 24 = 4! = 1 * 2 * 3 * 4, while 3! = 1 * 2 * 3 = 6 < 17).

Input/Output

[execution time limit] 20 seconds (swift)

[input] integer n

A positive integer.

Guaranteed constraints:
1 ≤ n ≤ 120.

[output] integer

repository: wendyliga/algorithm-code-test

path: /Code Signal/Least Factorial/readme.md

gha_language: Swift

repo_name: wendyliga/algorithm-code-test


text:
# GitKraken Alfred Workflow

A simple workflow to open a specific directory in GitKraken.

## Customization Guide

The current config is setup to search in your user folder only. To change this:

1. Add the workflow to Alfred
2. Open the workflow
3. Double click the `gk` File Filter
4. Click the `Search Scope` tab
5. Add & Remove folders to search


text:
+++
author = ["Oliver Kuederle"]
title = "Web Sessions and Common User Workflows - A Foundation for Go-Based Websites"
linktitle = "Web Sessions and Users"
date = "2017-12-11T00:00:00Z"
series = ["Advent 2017"]
+++

Go is widely used to implement microservices and APIs. And for those wishing to set up a dynamic website without resorting to, say, Ruby or PHP, Go offers a lot of tools out of the box. The use of `net/http` and `html/templates` can get you very far already.

As soon as a user needs to be identified across multiple HTTP requests, you need to start thinking about web sessions. They can be thought of as storage units assigned to a user, which persist across requests. Some implementations store data in an encrypted cookie, others such as [JSON Web Tokens (JWT)](https://jwt.io/) are often held in local browser storage.

The most common method is to store a token, or session ID, in a browser cookie. Based on that token, the server then loads the session data from a data store. Over the years, a number of best practices have evolved that make cookie-based web sessions reasonably safe. The [OWASP](https://www.owasp.org) organization lists a number of [recommendations](https://www.owasp.org/index.php/Session_Management_Cheat_Sheet) aimed at reducing common attacks such as [session hijacking](https://en.wikipedia.org/wiki/Session_hijacking) or [session fixation](https://en.wikipedia.org/wiki/Session_fixation). Unfortunately, many Go packages for web sessions leave it up to the user to implement these recommendations or don't even provide the tools to do it.

### Web Sessions

We present [github.com/rivo/sessions](https://github.com/rivo/sessions), a Go package designed for cookie-based web sessions which implements OWASP recommendations. Its usage is quite simple:

```go
func MyHandler(response http.ResponseWriter, request *http.Request) {
  session, err := sessions.Start(response, request, true)
  if err != nil {
    panic(err)
  }
  fmt.Fprintln(response, "We have a session")
}
```

Now you can already store data which will be available during subsequent HTTP requests:

```go
session.Set("cart", items)
// ...
items := session.Get("cart", nil)
if items == nil {
  fmt.Println("No items in cart")
}
```

The sessions package takes care of everything for you in the background: sessions expire after a period of inactivity, session tokens are regenerated regularly, and remote IP addresses as well as user agent strings are examined for unauthorized changes, leading to session invalidation. All of these options can be customized to your needs. Naturally, you can also connect any session store of your choice.

For many interactives websites, instead of saving data in the session directly, you may wish to step up one abstraction level and attach a User object to the session:

```go
// Attach a user to the session.
session.LogIn(user, true, response)

// Remove the user from the session:
session.LogOut()
```

`User` is an interface so it imposes no specific structure on your existing user model (other than requiring a unique user ID). But help is provided with additional functions such as `sessions.CUID()`, a function that generates compact unique identifiers suitable for users, or `sessions.ReasonablePassword()` which implements [NIST SP 800-63B](https://pages.nist.gov/800-63-3/sp800-63b.html) guidelines for passwords.

Once you start implementing user account handling, you realize there are a lot of procedures that are common to most websites. In the interest of making these user accounts secure, it is probably not advisable to reinvent the wheel each time.

### Common User Workflows

To facilitate the creation of websites with user accounts, we present [github.com/rivo/users](https://github.com/rivo/users), a Go package which implements the following functions:

- User sign up and email verification
- Logging into a user account
- Logging out of a user account
- Checking if a user is logged in
- Forgotten password and password reset
- Email and password change

Like [github.com/rivo/sessions](https://github.com/rivo/sessions), it is not a framework but rather a collection of tools you can integrate into your existing application. It is also somewhat opinionated, in that users are identified by their email addresses which no one else has access to. It therefore requires that you have access to an SMTP email server. If your application follows a different model, you will probably not be able to use this package out of the box. But it may still be a good start to implement your own user workflows.

The users package follows a number of rules:

- New user accounts or accounts whose email address was changed must be verified by clicking on a link sent per email.
- Authentication requires the user's email and password.
- It must not be possible to find out if a specific email address belongs to an existing user account.
- Password strength is checked with `session.ReasonablePassword()` (see above).
- Forgotten passwords are reset by clicking on a temporary link emailed to the user.
- Users are in exactly one of three states: created, verified, and expired.

Using the package is very easy:

```go
if err := users.Main(); err != nil {
  panic(err)
}
```

This will start an HTTP server with handlers for the pages listed above. You can add your own handlers to the `http.DefaultServeMux` before the call to `users.Main()`. The forms produced by those pages look like this (you will, however, need to provide your own CSS):

![Forms of the github.com/rivo/users package](/postimages/advent-2017/web-sessions-and-users/users.png)

Alternatively, to start your own HTTP server, you can add all the package's handlers yourself, simply by copying the implementation of the `users.Main()` function into your own code:

```go
http.HandleFunc(users.Config.RouteSignUp, users.SignUp)
http.HandleFunc(users.Config.RouteVerify, users.Verify)
http.HandleFunc(users.Config.RouteLogIn, users.LogIn)
http.HandleFunc(users.Config.RouteLogOut, users.LogOut)
http.HandleFunc(users.Config.RouteForgottenPassword, users.ForgottenPassword)
http.HandleFunc(users.Config.RouteResetPassword, users.ResetPassword)
http.HandleFunc(users.Config.RouteChange, users.Change)

if err := http.ListenAndServe(users.Config.ServerAddr, nil); err != nil {
  panic(err)
}
```

The package's handlers use Golang templates to generate the HTML pages and the emails sent to the users. The HTML templates provided with the package contain the minimum HTML code to make the handlers work. When starting to work with this package, you will want to make a copy and adjusts the templates to the needs of your application. Support for internationalization is also included.

The `users.Config` variable holds a large number of configuration parameters allowing you to customize the package to your needs. You may choose any database for your user objects. (The default is a pure RAM store.) And just as in the [github.com/rivo/sessions](https://github.com/rivo/sessions) package, the `User` type is an interface with the functions needed by this package so you can bring your own user type.

### Conclusion

If you are planning to implement a dynamic website using Go, the two packages [github.com/rivo/sessions](https://github.com/rivo/sessions) and [github.com/rivo/users](https://github.com/rivo/users) can save you a lot of time. The business logic of secure web sessions and common user workflows can be deceivingly complex. Our goal is to provide these functions without imposing an entire framework, so you can focus on your core application.

Of course, there are cases where these two packages may not be useful. For example, if you don't use cookies to identify your sessions, most functions don't apply. If your application runs on multiple servers, you may be able to use these packages with load balancers that implement [sticky sessions](https://stackoverflow.com/a/13641836/2046109) but distributed sessions don't come out of the box. And obviously, if your user model is very different from the model presented above, the `users` package may not help.

At the time of writing, both packages have just been released to the public. We would like to hear your feedback and if you encounter any problems or have suggestions, feel free to open issues on GitHub.

repository: gopheracademy/gopheracademy-web

gha_license_id: NOASSERTION

repo_name: gopheracademy/gopheracademy-web


text:
# React textareas

This small React app was motivated by a need develop a frontend to an ancient
system that wants its textual input to be split to lines of  certain maximum
length. User gets some pre-determined text that can be edited. The text will
be printed in the end, so the textarea should emulate "paper" to some extent.

This Textarea component helps user in maintaining the proper line lengths
as the text is being edited.

The requirements were as follows:
* User can freely edit text
* The text word-wraps when line length exceeds a preset length
* The text de-word-wraps if lines decrease in length enough to fit the next word
* The user needs to be able to add empty paragraphs to help avoiding orphan lines
* Textarea should expand (add rows) and shrink (decrease rows) as needed

The application contains three textarea fields, each with the same input to start with:
* The topmost uses the word-wrapping function on each keystroke (onChange)
* The middle one uses word-wrapping function when user exits textarea (onBlur)
* The lowest one is plain textarea, with no word-wrapping (or manual word-wrapping)

## Available Scripts

In the project directory, you can run:

### `npm start`

Runs the app in the development mode.\
Open [http://localhost:3000](http://localhost:3000) to view it in the browser.

The page will reload if you make edits.\
You will also see any lint errors in the console.

repository: rikusarlin/playground

branch_name: refs/heads/main

repo_name: rikusarlin/playground


text:
# Learn To Paint [WIP]

Code for automated painting.

This a refactor of [ctmakro repository](https://github.com/ctmakro/opencv_playground).

# Run

Install requirements

    pip install numpy opencv-python

Run main function via

    painter_fun.py  -i input_dir -o out_put_dir --salience_path salience_dir -e nb_epochs

repository: vicelikedust/data-science-learning

repo_name: vicelikedust/data-science-learning


text:
# CityDashboard #

## Quickest Way to Find Out What's Happening Around You ##

## Summary ##

CityDashboard is the personalized dashboard you've been looking for. Need to see the weather? There's a widget for that. When's the next Bart coming? There's a widget for that. CityDashboard is a great source for quick info about what's happening near you.

## Problem ##
Sometimes a map or a yelp or a whatever is just too much damn hassle. Maybe you’re in a new city and just want something close or you’re downtown and just want to know what's nearby.  Sometimes we just need a centralized source of info about what's happening around us.

## Solution ##

*CityDashboard™* is a blindingly simple application that that displays customizable widgets which contain information about what's happening in your city. You can set preferences so that every time *CityDashboard* loads in a new tab you have all the info you need. And if CityDashboard doesn't do something you want it to, just whip up a widget!

## Quote from You ##

> A HUD for my city.

## How to Get Started ##
Go to [insert link here] and configure your CityDashboard!

## Customer Quote ##
> CityDashboard.

## Closing and Call to Action ##
Just go to [link] on your favorite browser, set CityDashboard to your homepage, and see how easy it is to find what you need.

repository: R-N-D-M/CityDashboard

gha_language: JavaScript

repo_name: R-N-D-M/CityDashboard


text:
# **pretty-easy**

### **pretty-easy** is a pack (bundle) of NodeJS modules for common tasks, such as:
  - getting the **dates** [ [**Git repository**](https://github.com/ognjenjevremovic/pretty-easy-dates), [**npm module**](https://www.npmjs.com/package/pretty-easy-dates) ],
  - displaying **logs** to the console (*including writing them to files*) [ [**Git repository**](https://github.com/ognjenjevremovic/pretty-easy-logs), [**npm module**](https://www.npmjs.com/package/pretty-easy-logs) ],
  - setting and reading **environment variables** [ [**Git repository**](https://github.com/ognjenjevremovic/pretty-easy-env-vars), [**npm module**](https://www.npmjs.com/package/pretty-easy-env-vars) ],
  - **CRUD operations** using MongoDB database collections [[**Git repository** - *in development*](https://github.com/ognjenjevremovic/pretty-easy-crud)],
  - **Crypting and decrypting** the data [(***planned for the later date***)],
  - easily **sending the mails** [(***planned for the later date***)]

## Still in development
Please do note that the module is ***still in development*** and not all of the features (planned for initial release) are yet implemented.
As such, the module is **NOT** intended for production yet and is not found on the npm repository because of the same reason.

If you're eager to see the module production ready, please consider making a pull request and contribute to the project.

### *What is pretty-easy-env-vars?*
***pretty-easy-env-vars*** *is a NodeJS module for setting and retrieving **environment-specific variables** from a file*.
It helps you store your sensitive information, such as database passwords or API keys in a file - either in default **'.envVars'** (UNIX hidden) file or from a custom **'.json'** or **'.txt'** file).
You are **strongly encouraged *NOT!* to** include the file containing environment-specific variables in the version control systems repository (such as ***Github***), but rather:

- create a *'.envFile'* on a deployment server,
- populate it with data and
- then require the module as early as possible in your application

### *Why use this module?*
Version control systems such as **Git** allows us to share our work with other like-minded developers and get their help in debugging and deploying our ideas (read *software*). But sometimes, we don't want our *sensitive information* (such as **passwords** and **API keys**) to be included in our public repositories and be seen by everyone.
However, removing those by hand each time we want to make a commit or defining a *commit task* (in build tools such as *Gulp* or *Grunt*) that would automate the process of masking sensitive info, is not an easy task.
But, we don't want our **passwords, IP addresses, port numbers, hashes and API keys** exposed; don't we?!

That's where this module comes in handy!

The file could either be a UNIX hidden file (with it's name prefixed with a dot) or you could just add the name of your file (that contains your sensitive information) to **'.gitignore'** file and exclude it from the repository.

### *How to use this module?*
By default the module requires ***'.envVars'*** file in the root of your project, populated with ***key=value*** pairs.
However, you could define another file (either in ***'.txt'*** or ***'.json'*** format) and pass it's name (and optionally **file path** - if it's not located in the root of your project; and **file extension** - if the file is not in *'.envVars'* extension) to the function call.
You're advised to set your environment variables from within your main entry point file (*'server.js'*, *'app.js'*, *'index.js'* or *'howeverYouCall_It.js'*) at the very beginning.

# Install
This is a [NodeJS](http://www.node.js) module available through the [npm](http://npmjs.org) registry. Installation is done using the **npm install** command:
```sh
$ npm install pretty-easy-env-vars
```

# Usage
After installing the module (locally in your project directory), in order to use it in your file you first need to require it.
```javascript
var envVars = require('pretty-easy-env-vars');
```

The module returns a function for you to call (with optional parameter to be passed< *Object literal || string* >) which then sets **environment-specific variables** from the file.

## Examples

### 1. Simple usage (no parameter)

The most simplest use is to call the function returned by the module (without any parameter being supplied to the function), which will then set **environment variables** for your working environment from :
- **'.envVars'** file,
- located in the **root** of your project

```javascript
//	Require the module
var envVars = require('pretty-easy-env-vars');

// 	Set environment variables, from within '.envVars' file
//	located in the root of the project (default filename, file path, file extension)
envVars();
```

### 2. Simple usage (string parameter)
If you'd like to store your environment variables in the file other than *'.envVars'*, you're more than welcome to.
However, there are few things to note:

- supported file formats are : ***'.envVars'***, ***'.txt'***, ***'.json'***,
- you should include the full filename (including the file extension) -> *i.e* ***'vars.txt'*** or default ***'envVars'*** extension will be used instead,
- file should be located in the root of your application,
- only files prefixed with a '.' (dot) are automatically excluded from the version control systems (such as *Git*); if however, you don't want to prefix your file with a dot, you'll need to put the filename to your **.gitignore** file, in order NOT to include it to version control system.

```javascript
//	Require the module
var envVars = require('pretty-easy-env-vars');

// 	Set environment variables, from within 'my-variables.txt' file
//	located in the root of the project (default file path)
envVars('my-variables.txt');
```

If you'd like to preserve the default file format (*'.envVars'*), but name your file rather differently ('myvars.envVars' for example) you can pass the filename only and *NOT* the file extension to the function call.
```javascript
//	Require the module
var envVars = require('pretty-easy-env-vars');

// 	Set environment variables, from within 'myvars.envVars' file
//	located in the root of the project (default file path, extension)
envVars('myvars');
```

***Important!***
When passing a string parameter, the file containing your *sensitive information* (that you want to set as an environment variable) **must** be located in the root of your application!
If you'd like to change the file path, you'll need to pass *Object literal* instead.

### 3. Object literal parameter supplied
When passing an Object literal parameter, the ***'fileName'*** property must be set on the Object, otherwise the default values are used instead.
Properties that are considered valid for the Object parameter passed:
- **fileName** - which defines the name of the file (full file name, including the extension or without the extension - if file extension is defined here, it will not be overwritten with a value from 'fileExtension' property),
- **fileExtension** - defining the extension of the file (supported files extensions are *envVars*, *txt*, *json*) - without a ***.*** (very important!),
- **filePath** - which defines the **relative** path to your file (from the *__dirname* perspective).

Default values for the properties of a JavaScript Object literal supplied to the function :"
- *fileName* === '' -> empty string,
- *fileExntesion* === 'envVars',
- *filePath* === root of your project

```javascript
//	Require the module
var envVars = require('pretty-easy-env-vars');

//	environment variables options
var envOptions = {};
envOptions.fileName = 'myvars';
envOptions.fileExtension = 'txt';

// 	Set environment variables, from within 'myvars.txt' file
//	located in the root of the project (default file path)
envVars(envOptions);
```

# Syntax
##### For *.envVars* and *.txt* files :

```sh
VARIABLE_NAME=VARIABLE_VALUE
ANOTHER_VARNAME=SOME_VALUE
```

Multiline variable values are allowed, when wrapped with **quotes** ("" || '').
```sh
MULTILINE_VAR='Multi
line
variable
value'
```

##### For *.json* files :

```js
{
	"VARIABLE_NAME" : "VARIABLE_VALUE",
	"ANOTHER_VARNAME" : "SOME_VALUE"
}
```

### Want to contribute?
**Great!**
Anyone can help make this project better - check out the [github](https://github.com/ognjenjevremovic/pretty-easy-dates) repository!

### License
Copyright (c) 2016 [Ognjen Jevremović](https://github.com/ognjenjevremovic)

Licensed under the [MIT](https://github.com/ognjenjevremovic/pretty-easy-dates/blob/master/LICENSE) License.

repository: ognjenjevremovic/pretty-easy-env-vars

repo_name: ognjenjevremovic/pretty-easy-env-vars


text:
# Webcirque Fundboard
A panel, for automatic fund statistics calculation.

Fully browser-side, only requires static server files to present.

## Status
[![Maintainability](https://api.codeclimate.com/v1/badges/b3bc87151c7791642bdd/maintainability)](https://codeclimate.com/github/webcirque/fundboard/maintainability)
[![Test Coverage](https://api.codeclimate.com/v1/badges/b3bc87151c7791642bdd/test_coverage)](https://codeclimate.com/github/webcirque/fundboard/test_coverage)

## Installing
No server-side configuration required, because it is only a set of static files. It even works with only GitHub/GitLab Pages!

Download ZIP or TGZ archives from the releases, and then extract them somewhere you wish.

## Configuration

repository: webcirque/fundboard

repo_name: webcirque/fundboard


text:
# with-rate-limit

`with-rate-limit` is a simple, lightweight and robust rate limiting tool. It supports in-memory or Redis
as a store for distributed operations.

## Installation

Add this line to your application's Gemfile:

```ruby
gem 'with_rate_limit'
```

And then execute:

    $ bundle install

Or install it yourself as:

    $ gem install with_rate_limit

## Basic Usage

```ruby
include WithRateLimit

interval = 1 # interval in seconds
rate_limit = 5 # number of operations within given interval
options = {
  cache_key: "daily_requests", # default: "[limit]-operations-per-[interval]"
  strategy: WithRateLimit::Strategy::Sleep, # default strategy, see #strategies
  cache: WithRateLimit::Cache::Memory, # default cache mechanism, see #cache-mechanism
}
with_rate_limit interval, rate_limit, options do
  # do something here
  # operation performed here will be rated limited
  # with `Sleep` strategy, if rate limit is hit, `with_rate_limit` will wait for the remainder of the interval.
end
```

### Multiple rate limits
If you need to set up multiple rate limits, i.e. 5000 requests/day **and** 5 requests/sec, you can nest `with_rate_limit` calls.

```ruby
include WithRateLimit

with_rate_limit 1.day.to_i, 5000 do
    with_rate_limit 1, 5 do
        # do something here
    end
end
```

### Strategies
**WithRateLimit::Strategy::Sleep**
Simply sleeps until the beginning of the next interval if rate limit is hit. Avoid `Sleep` with
large intervals with limit that are likely to exceeded early as it may block application requests.

**WithRateLimit::Strategy::RaiseError**
Raises an `WithRateLimit::LimitExceededError` with the number of second to wait until next interval.

```ruby
include WithRateLimit

with_rate_limit 1, 5 do
    # do something
rescue WithRateLimit::LimitExceededError => e
    # reschedule this task for `e.timeout` seconds from now.
end
```

Different strategies can be used in nested `with_rate_limit` calls.

### Cache

**WithRateLimit::Cache::Memory**
Stores cache data for `cache_key` in memory.

**WithRateLimit::Cache::Redis**
Stores cache data for `cache_key` in Redis so it can be shared in distributed systems.  Redis can be configured through
`WithRateLimit::Cache::Redis.configure` method.

```ruby
redis_cache = WithRateLimit::Cache::Redis.configure { |conf| conf[:redis_options] = {url: 'redis://localhost:6379'}}
with_rate_limit 1, 5, {cache: redis_cache} do
    # do something
end
```

Different cache mechanisms can be used in nested `with_rate_limit` calls too.

## Extending

After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake test` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).

## Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/aterletskiy/with_rate_limit. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [code of conduct](https://github.com/[USERNAME]/with_rate_limit/blob/master/CODE_OF_CONDUCT.md).

## License

The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).

## Code of Conduct

Everyone interacting in the WithRateLimit project's codebases, issue trackers, chat rooms and mailing lists is expected to follow the [code of conduct](https://github.com/[USERNAME]/with_rate_limit/blob/master/CODE_OF_CONDUCT.md).

repository: aterletskiy/with-rate-limit

repo_name: aterletskiy/with-rate-limit


text:
polargraph-py-com
=================

Version 0.1 alpha

polargraph python communicator and driver

The polargraph project can be found at http://polargraph.co.uk and is a wonderfull project

The Problem :
-------------
The polargraph controler is build with the java framework processing, wich is an amazing tool for art and rapid prototyping.

But :
	* it require to have a computer attached to the arduino to drive the polargraph
	* the gui is so heavy that it turns my macbook pro into an hoven. (cpu 100%)
	* i want to use a wifi router with openwrt and a usb port to wirelessly pilot the polargraph

The Solution :
--------------
As :
	* the communication protocol is damn simple and build upon the usb/serial of the arduino
	* the polargraph controler can export the serial commands in a file

	I just wrote this small python script which :
		* open a serial communication with the polargraph
		* send one line of a file for each 'READY' message, check the ACK and then send a EXEC
		* send a pen lift message at the end of file to be sure security (optional)

The tools :
-----------
	* a pivotal tracker roadmap is availlable here : https://www.pivotaltracker.com/projects/638973
	* a pivotal to github bridge is set so please add the id of the related story in pivotal in the comment of the commit ( [#000000] to link to a story and [fix #0000000] to mark it as fixed ) if you submit code to this project. You'll find more info in the API help section of pivotal tracker.

How it works ?
--------------
	* Install Python (2.x) ( http://python.org/ )
	* Install pySerial ( http://pyserial.sourceforge.net/ )
	* Open the polargraph controler as you usually do, create your whole commands queue and export it to a file
	* Open the _main.py file
	* Set the variables to your needs ( especially the port and polarfile )
	* open a terminal and launch the script ( $ python _main.py )
	* enjoy ( if you didn't set the debug var to True the script is silent while working )

Licence :
---------
	* The whole shit is released without any guarantee and is put under MIT licence ( this version -> http://opensource.org/licenses/MIT )

	(c)2012 - Edwin Joassart < edwin AT aethernet DOT eu > - aethernet.eu

repository: thytruong/polargraph-py-com

repo_name: thytruong/polargraph-py-com


text:
# rubiks-cube

[FreeCAD](https://www.freecadweb.org/) 3D model of a Rubik's Cube. The cube has 6 distinct parts.

| Part | Count |
| ---- | :---: |
| [core](https://github.com/jimmynguyen/rubiks-cube/blob/master/src/parts/core.FCStd) | 1 |
| [corner piece](https://github.com/jimmynguyen/rubiks-cube/blob/master/src/parts/cornerPiece.FCStd) | 8 |
| [edge piece](https://github.com/jimmynguyen/rubiks-cube/blob/master/src/parts/edgePiece.FCStd) | 12 |
| [face center](https://github.com/jimmynguyen/rubiks-cube/blob/master/src/parts/faceCenter.FCStd) | 6 |
| [screw](https://github.com/jimmynguyen/rubiks-cube/blob/master/src/parts/screw.FCStd) | 6 |
| [stem](https://github.com/jimmynguyen/rubiks-cube/blob/master/src/parts/stem.FCStd) | 6 |

Inspired by [http://lulabs.net/machining/ss-cube/](http://lulabs.net/machining/ss-cube/)

repository: jimmynguyen/rubiks-cube

repo_name: jimmynguyen/rubiks-cube


text:
# Dome9 SDK python

Author - Dome9 SRE Team<EMAIL_ADDRESS>
Dome9 Python SDK is a library the access Dome9 API V2. It enables you to manage Dome9 resources such as Cloud Account Onboarding, Security Groups management, Access Lease, IAM Safety and more.

Dome9 API documentation: https://api-v2-docs.dome9.com/

Quick Start
-----

### Installation
```bash
$ pip install git+https://github.com/dome9/dome9-sdk-python
```

### Import
Client can be imported from dome9_type_annotations layer to support IDE methods completion
```python
from dome9_type_annotations.client import Client
```
Client can also be imported directly
```python
from dome9 import Client
```

### Client Initialisation

Required parameters for client initiation (`access_id`, `secret_key`) can be passed directly:
```python
dome9_client = Client(access_id='ACCESS_ID', secret_key='SECRET_KEY')
```

Alternatively, If parameters are not provided, `Client` will seek and use `DOME9_ACCESS_ID` and `DOME9_SECRET_KEY` **environment variables**
```bash
export DOME9_ACCESS_ID = YOUR_ACCESS_ID
export DOME9_SECRET_KEY = YOUR_SECRET_KEY
```
```python
dome9_client = Client()
```

By default, client will use Dome9 production URL `https://api.dome9.com/v2/`. For development purposes, different URL can be provided:
```python
dome9_client = Client(base_url='DOME9_ENVIRONMENT_URL')
```

### Example - Create Role
```python
from dome9_type_annotations.client import Client
from resources.role import CreateRole

dome9_client = Client(access_id='ACCESS_ID', secret_key='SECRET_KEY')
payload = CreateRole(name='my-role', description='my-description')
response = dome9_client.role.create(body=payload)

print(response)
```

### Unimplemented Resources
You can view the yet implemented resources under `not_implemented_resources` folder. You are welcome to contact us and to request a specific resource to be prioritized.

gha_language: Python


text:
# Beyblade Dodge Game

Beyblade dodge game, as the name suggests it allows user to dodge the beyblades coming from other side. The game animation starts when you press SPACE key from the keyboard and UP ↑ key is there to make our beyblade jump.
This game is a simple javascript application, that make full use of the CSS animations and basic javascript methods. It has a counter that counts your score and resets to zero after each round.
I learnt the Chrome dinosaur game, before applying the same to it, Hope you like it 😇

## Screenshot

## Badges

[![MIT License](https://img.shields.io/apm/l/atomic-design-ui.svg?)](https://github.com/tterb/atomic-design-ui/blob/master/LICENSEs)

## Contributing

Contributions are always welcome!


text:
# async-as-promised

[![Build Status](https://travis-ci.org/AccaliaDeElementia/async-as-promised.svg?branch=master)](https://travis-ci.org/AccaliaDeElementia/async-as-promised)
[![NPM Version](https://img.shields.io/npm/v/async-as-promised.svg)](https://www.npmjs.com/package/async-as-promised)
[![Coverage Status](https://coveralls.io/repos/AccaliaDeElementia/async-as-promised/badge.svg?branch=master&service=github)](https://coveralls.io/github/AccaliaDeElementia/async-as-promised?branch=master)
[![Join the chat at https://gitter.im/AccaliaDeElementia/aplus](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/AccaliaDeElementia/aplus?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)

[![Dependency Status](https://david-dm.org/AccaliaDeElementia/async-as-promised/master.svg)](https://david-dm.org/AccaliaDeElementia/async-as-promised/master)
[![devDependency Status](https://david-dm.org/AccaliaDeElementia/async-as-promised/master/dev-status.svg)](https://david-dm.org/AccaliaDeElementia/async-as-promised/master#info=devDependencies)
[![optionalDependency Status](https://david-dm.org/AccaliaDeElementia/async-as-promised/master/optional-status.svg)](https://david-dm.org/AccaliaDeElementia/async-as-promised/master#info=optionalDependencies)

async-as-promised is a utility module that provides straight-forward, powerful functions for working with Promise based
JavaScript.

The functions contained within this module are modeled off the API provided by @caolan's excellent
[async](https://github.com/caolan/async) module. This module is intended to provide a similar API for working with
Promise based modules as async provides for callback based modules.

async-as-promised provides over twenty functions that include the usual 'functional' suspects (`map`, `reduce`,
`filter`, `each`…) as well as some common patterns for asynchronous control flow (`parallel`, `series`, `waterfall`…).

## Quick Examples
```
var fs = require('fs');
var async = require('async-as-promised');
var statPromise = async.promisify(fs, fs.stat);
var existsPromise = async.promisify(fs, fs.exists);

async.map(['file1', 'file2', 'file3'], statPromise).then(function (results){
	// results is now an array of stats for each file
});

async.parallel([
	function(){}, // Functions that return promises when called
	function(){},
	function(){}
]).then(function (results){
	// results is an array of the values the provided functions eventually resolved to.
});

async.series([ // Like async.parallel, except each function will be run only after the previous one has resolved
	function(){}, // Functions that return promises when called
	function(){},
	function(){}
]).then(function (results){
	// results is an array of the values the provided functions eventually resolved to.
});

```

## Binding context to a function

This section is really about bind, not about async-as-promised. If you are wondering how to make async-as-promised
execute your iterators in a given context, or are confused as to why a method of another library isn't working as an
iterator, study this example:

```
// Here is a simple object with an (unnecessarily roundabout) squaring method
var PromiseSquaringLibrary = {
  squareExponent: 2,
  square: function(number, callback){
    var result = Math.pow(number, this.squareExponent);
    return Promise.resolve(result);
  }
};

async.map([1, 2, 3], PromiseSquaringLibrary.square).then(function (result) {
  // result is [NaN, NaN, NaN]
  // This fails because the `this.squareExponent` expression in the square
  // function is not evaluated in the context of PromiseSquaringLibrary, and is
  // therefore undefined.
});

async.map([1, 2, 3], PromiseSquaringLibrary.square.bind(PromiseSquaringLibrary),).then(function(result) {
  // result is [1, 4, 9]
  // With the help of bind we can attach a context to the iterator before
  // passing it to async. Now the square function will be executed in its
  // 'home' PromiseSquaringLibrary context and the value of `this.squareExponent`
  // will be as expected.
});
```

## Download
The source is available for download from [GitHub](https://github.com/AccaliaDeElementia/async-as-promised).
Alternatively, you can install using Node package manager (`npm`):
```
npm install async-as-promised
```

## Using other Promise Libraries
By default async-as-promised uses the global default Promise object (falling back to
[promise-polyfill](https://www.npmjs.com/package/promise-polyfill) if there is no global Promise object). However
async-as-promised supports using any [promises/A+](https://promisesasync.com/) compliant promise library, such as
[bluebird](http://bluebirdjs.com/docs/getting-started.html)

To change the Promise library used async-as-promised use the `setPromise()` method as shown below:
```
var async = require('async-as-promised');
var bluebird = require('bluebird');

async.setPromise(bluebird);
// async-as-promised will now use bluebird promises for all functions

// to return to the default Promise type simply reset the Promise:
async.resetPromise();
```

repository: AccaliaDeElementia/async-as-promised

repo_name: AccaliaDeElementia/async-as-promised


text:
# Knowledge Discovery in Databases (KDD)
The following topics are covered in this lecture:
- The particular challenges of data mining on large sets of data.
- The technologies available for data analysis.
- Systems offering these technologies.
- The process of data mining.
- Applications.

Please note, that this lecture is an informal overview rather then a formal introduction into the topic.

# Lecture slides
1. [Prologue](https://karhunenloeve.github.io/KDD/pdfs/lecture1.pdf).
2. [Introduction](https://karhunenloeve.github.io/KDD/pdfs/lecture2.pdf).
3. [Data](https://karhunenloeve.github.io/KDD/pdfs/lecture3.pdf).
4. [Preprocessing](https://karhunenloeve.github.io/KDD/pdfs/lecture4.pdf).
5. [OLAP](https://karhunenloeve.github.io/KDD/pdfs/lecture5.pdf).
6. [Frequent patterns](https://karhunenloeve.github.io/KDD/pdfs/lecture6.pdf).
7. [Classification](https://karhunenloeve.github.io/KDD/pdfs/lecture7.pdf).
8. [Cluster analysis](https://karhunenloeve.github.io/KDD/pdfs/lecture8.pdf).
9. Outlier detection.

# References
1. Han Jiawei, Kamber Micheline, Pei Jian: Data Mining: Concepts and Techniques. 3rd ed. Waltham, M.A.: Morgan Kaufmann, 2012 (The Morgan Kaufmann Series in Data Management Systems).
2. Witten Ian, Frank Eibe, Hall Mark: Data Mining. Practical Machine Learning Tools and Techniques. 3rd ed. Burlington, M.A.: Morgan Kaufmann, 2011 (The Morgan Kaufmann Series in Data Management Systems).
3. Du Hongbo: Data Mining Techniques and Applications. Andover, UK: Cengage Learning, 2010.


text:
[![license](https://img.shields.io/badge/license-BSD%20-blue.svg)](https://raw.githubusercontent.com/yorickdewid/gocraw/master/LICENSE)

## gocraw

Webcrawler written in go. Retrieves webcontent and saves it to a file.

### Examples

```
gocraw https://github.com
```

Or load the config file

```
gocraw -file gocraw.conf
```

## Configuration

List the domains per line

```
# Some comment

https://github.com/
# http://www.facebook.com # Exclude this URL
https://www.google.com
http://www.golang.org/
```

repository: yorickdewid/gocraw

repo_name: yorickdewid/gocraw


text:
## K-th Symbol in Grammer
On the first row, we write a 0. Now in every subsequent row, we look at the previous row and replace each occurrence of 0 with 01, and each occurrence of 1 with 10.

Given row N and index K, return the K-th indexed symbol in row N. (The values of K are 1-indexed.) (1 indexed).
<code>
Examples:
Input: N = 1, K = 1
Output: 0

Input: N = 2, K = 1
Output: 0

Input: N = 2, K = 2
Output: 1

Input: N = 4, K = 5
Output: 1

Explanation:
row 1: 0
row 2: 01
row 3: 0110
row 4: 01101001

</code>

Note:
N will be an integer in the range [1, 30].
K will be an integer in the range [1, 2^(N-1)].

repository: shahbagdadi/py-algo-n-ds

repo_name: shahbagdadi/py-algo-n-ds


text:
---
layout: page
title: Install
permalink: /install/
icon: cloud_download
---

Add this line to your Jekyll site's `Gemfile`:

```ruby
gem "minimaterialize"
```

And add this line to your Jekyll site:'s `_config.yml`:

```yaml
theme: minimaterialize
```

And then execute:

```shell
bundle install
```

[Read more on GitHub](https://github.com/sh78/minimaterialize/).