text:
![LOGO](Docs/images/logo_full_color_h100.png)

Shepher is a management tool of ZooKeeper. In Xiaomi, we use it as the configuration management center. [Readme 中文版](README-zh.md)

## Features
- Visualized operation of ZooKeeper node
- Snapshot management of ZooKeeper node
- Modified Diff and Review function of ZooKeeper node
- Mail operation notification of ZooKeeper node
- Integrates CAS and LDAP log
- Authority management, reference to [Authority management instruction](Docs/Authority.md)

## Function comparison of similar products
Product | Introduction | Visualized operation of nodes | Snapshot management | Node modified Diff and Review function | Node operated mail notification | CAS and LDAP log | Authority management | Cascade delete | System status monitor
---|---|---|---|---|---|---|---|---|---
Shepher | ZooKeeper management | √ | √ | √ | √ | √ | √ |   |
TaoKeeper | ZooKeeper cluster monitor and statement |   |   |   |   |   |   |   | √
Zkdash | ZooKeeper management | √ | √ |   |   |   |   | √ |
Disconf | ZooKeeper management | √ | √ |   | √ |   | √ | √ | √
XDiamond | Configuration center | √ |   |   |   | √ | √ |   | √

## Screenshots
- Home
![Home](Docs/images/home.png)

- Node view
![Node view](Docs/images/node-view.png)

## Installation

### Environment requirements
- JDK 1.8
- Maven 3.2 +
- MySQL 5.6

### Basic configuration

- Modify `INSERT INTO user VALUES (1,'youradmin',now());` in `db/init.sql`, change `youradmin` into your administrator user name
- According to [Parameter instruction](Docs/Parameter.md), modify parameter configuration under the directory `shepher-web/src/main/resources`. If you are using a CAS login, you need to modify the CAS-related configuration and set the `server.login.type` to `CAS`; If you log in with LDAP, you will need to modify the LDAP-related configuration and set `server.login.type` to `LDAP`

### Development environment deployment

Development environment deployment includes local compilation deployment and Docker deployment, you can choose a deployment based on usage.

#### Compile
1. Modify parameter configuration of `conf/application*.properties` according to [Parameter instruction](Docs/Parameter.md)
2. Local compile

    ```sh
    $ mvn clean package
    $ cd shepher-packaging/target/shepher-packaging-{version}-bin
    $ ls
    bin/(all the shell scripts)
    conf/(configuration files)
    db/init.sql
    lib(required jar files)
    Dockerfile
    docker-compose.yml
    CHANGES.txt
    NOTICE.txt
    README.md
    README-zh.md
    VERSION
    ```
    Here, {version} refers to the current Shepher version.

#### Local deployment

1. Import `db/init.sql` in to MySQL
2. Enter install directories

    ```sh
    $ cd shepher-packaging/target/shepher-packaging-{version}-bin
    ```
3. Run the script, start Shepher service

    ```sh
    $ sh bin/run.sh start
    ```
4. Visit `http://localhost:8089` or self defined `server.url` (Reference to [Parameter instruction](Docs/Parameter.md))

#### Docker deployment

MySQL and ZooKeeper will be automatic integrated when Docker deployment is used, and automatically import `db/init.sql` into MySQL, no self installation is needed.

1. Install Docker, take Ubuntu system for example, install [docker engine](https://docs.docker.com/engine/installation/#installation) and [docker-compose](https://docs.docker.com/compose/install/)
2. Enter install directories

    ```sh
    $ cd shepher-packaging/target/shepher-packaging-{version}-bin
    ```
3. Run the script, start Shepher service and waiting start of each container in Docker accomplish

    ```sh
    $ sh bin/docker-run.sh start
    ```
4. Visit `http://localhost:8089` or self defined `server.url` (Reference to [Parameter instruction](Docs/Parameter.md))

### Production environment deployment

The steps for production environment deployment is similar to local compiling deployment, but pay attention to the setting of data sources, CAS/LDAP and domain names. In addition, because each company's internal mail service is relatively closed, you need to implement your own `CustomMailSender` class, and set `mail.sender=customMailSender` in` conf/application.properties`, so that Shepher can use the mail service normally.

1. Import `db/init.sql` into MySQL
2. Create the file `conf/application-online.properties`, and modify the configuration according to [Parameter instruction](Docs/Parameter.md)
3. Run the command in the Shepher root directory

    ```sh
    $ mvn clean package
    ```
4. Copy `shepher-packaging/target/shepher-packaging-{version}-bin` to the production environment, and enter the directory

    ```sh
    $ cd shepher-packaging/target/shepher-packaging-{version}-bin
    ```
5. Run the command below, start Shepher

    ```sh
    $ sh bin/run.sh -c conf/application.properties,conf/application-online.properties start
    ```
6. Visit self defined `server.url` (Reference to [Parameter instruction](Docs/Parameter.md))

## Contributors

**Long Xie** ([@xielong](https://github.com/xielong)),
**Jinliang Ou** ([@oujinliang](https://github.com/oujinliang)),
**Chuanyu Ban** ([@banchuanyu](https://github.com/banchuanyu)),
**Chuyang Wei** ([@brianway](https://github.com/brianway)),
**Peng Zhang** ([@monsters-peng](https://github.com/monsters-peng)),
**Yaoli Liu** ([@iloayuil](https://github.com/iloayuil))

repository: monsters-peng/shepher

repo_name: monsters-peng/shepher


text:
# Table of Contents

* [mlagents.trainers.trainer.on\_policy\_trainer](#mlagents.trainers.trainer.on_policy_trainer)
  * [OnPolicyTrainer](#mlagents.trainers.trainer.on_policy_trainer.OnPolicyTrainer)
    * [\_\_init\_\_](#mlagents.trainers.trainer.on_policy_trainer.OnPolicyTrainer.__init__)
    * [add\_policy](#mlagents.trainers.trainer.on_policy_trainer.OnPolicyTrainer.add_policy)
* [mlagents.trainers.trainer.off\_policy\_trainer](#mlagents.trainers.trainer.off_policy_trainer)
  * [OffPolicyTrainer](#mlagents.trainers.trainer.off_policy_trainer.OffPolicyTrainer)
    * [\_\_init\_\_](#mlagents.trainers.trainer.off_policy_trainer.OffPolicyTrainer.__init__)
    * [save\_model](#mlagents.trainers.trainer.off_policy_trainer.OffPolicyTrainer.save_model)
    * [save\_replay\_buffer](#mlagents.trainers.trainer.off_policy_trainer.OffPolicyTrainer.save_replay_buffer)
    * [load\_replay\_buffer](#mlagents.trainers.trainer.off_policy_trainer.OffPolicyTrainer.load_replay_buffer)
    * [add\_policy](#mlagents.trainers.trainer.off_policy_trainer.OffPolicyTrainer.add_policy)
* [mlagents.trainers.trainer.rl\_trainer](#mlagents.trainers.trainer.rl_trainer)
  * [RLTrainer](#mlagents.trainers.trainer.rl_trainer.RLTrainer)
    * [end\_episode](#mlagents.trainers.trainer.rl_trainer.RLTrainer.end_episode)
    * [create\_optimizer](#mlagents.trainers.trainer.rl_trainer.RLTrainer.create_optimizer)
    * [save\_model](#mlagents.trainers.trainer.rl_trainer.RLTrainer.save_model)
    * [advance](#mlagents.trainers.trainer.rl_trainer.RLTrainer.advance)
* [mlagents.trainers.trainer.trainer](#mlagents.trainers.trainer.trainer)
  * [Trainer](#mlagents.trainers.trainer.trainer.Trainer)
    * [\_\_init\_\_](#mlagents.trainers.trainer.trainer.Trainer.__init__)
    * [stats\_reporter](#mlagents.trainers.trainer.trainer.Trainer.stats_reporter)
    * [parameters](#mlagents.trainers.trainer.trainer.Trainer.parameters)
    * [get\_max\_steps](#mlagents.trainers.trainer.trainer.Trainer.get_max_steps)
    * [get\_step](#mlagents.trainers.trainer.trainer.Trainer.get_step)
    * [threaded](#mlagents.trainers.trainer.trainer.Trainer.threaded)
    * [should\_still\_train](#mlagents.trainers.trainer.trainer.Trainer.should_still_train)
    * [reward\_buffer](#mlagents.trainers.trainer.trainer.Trainer.reward_buffer)
    * [save\_model](#mlagents.trainers.trainer.trainer.Trainer.save_model)
    * [end\_episode](#mlagents.trainers.trainer.trainer.Trainer.end_episode)
    * [create\_policy](#mlagents.trainers.trainer.trainer.Trainer.create_policy)
    * [add\_policy](#mlagents.trainers.trainer.trainer.Trainer.add_policy)
    * [get\_policy](#mlagents.trainers.trainer.trainer.Trainer.get_policy)
    * [advance](#mlagents.trainers.trainer.trainer.Trainer.advance)
    * [publish\_policy\_queue](#mlagents.trainers.trainer.trainer.Trainer.publish_policy_queue)
    * [subscribe\_trajectory\_queue](#mlagents.trainers.trainer.trainer.Trainer.subscribe_trajectory_queue)
* [mlagents.trainers.settings](#mlagents.trainers.settings)
  * [deep\_update\_dict](#mlagents.trainers.settings.deep_update_dict)
  * [RewardSignalSettings](#mlagents.trainers.settings.RewardSignalSettings)
    * [structure](#mlagents.trainers.settings.RewardSignalSettings.structure)
  * [ParameterRandomizationSettings](#mlagents.trainers.settings.ParameterRandomizationSettings)
    * [\_\_str\_\_](#mlagents.trainers.settings.ParameterRandomizationSettings.__str__)
    * [structure](#mlagents.trainers.settings.ParameterRandomizationSettings.structure)
    * [unstructure](#mlagents.trainers.settings.ParameterRandomizationSettings.unstructure)
    * [apply](#mlagents.trainers.settings.ParameterRandomizationSettings.apply)
  * [ConstantSettings](#mlagents.trainers.settings.ConstantSettings)
    * [\_\_str\_\_](#mlagents.trainers.settings.ConstantSettings.__str__)
    * [apply](#mlagents.trainers.settings.ConstantSettings.apply)
  * [UniformSettings](#mlagents.trainers.settings.UniformSettings)
    * [\_\_str\_\_](#mlagents.trainers.settings.UniformSettings.__str__)
    * [apply](#mlagents.trainers.settings.UniformSettings.apply)
  * [GaussianSettings](#mlagents.trainers.settings.GaussianSettings)
    * [\_\_str\_\_](#mlagents.trainers.settings.GaussianSettings.__str__)
    * [apply](#mlagents.trainers.settings.GaussianSettings.apply)
  * [MultiRangeUniformSettings](#mlagents.trainers.settings.MultiRangeUniformSettings)
    * [\_\_str\_\_](#mlagents.trainers.settings.MultiRangeUniformSettings.__str__)
    * [apply](#mlagents.trainers.settings.MultiRangeUniformSettings.apply)
  * [CompletionCriteriaSettings](#mlagents.trainers.settings.CompletionCriteriaSettings)
    * [need\_increment](#mlagents.trainers.settings.CompletionCriteriaSettings.need_increment)
  * [Lesson](#mlagents.trainers.settings.Lesson)
  * [EnvironmentParameterSettings](#mlagents.trainers.settings.EnvironmentParameterSettings)
    * [structure](#mlagents.trainers.settings.EnvironmentParameterSettings.structure)
  * [TrainerSettings](#mlagents.trainers.settings.TrainerSettings)
    * [structure](#mlagents.trainers.settings.TrainerSettings.structure)
  * [CheckpointSettings](#mlagents.trainers.settings.CheckpointSettings)
    * [prioritize\_resume\_init](#mlagents.trainers.settings.CheckpointSettings.prioritize_resume_init)
  * [RunOptions](#mlagents.trainers.settings.RunOptions)
    * [from\_argparse](#mlagents.trainers.settings.RunOptions.from_argparse)

# mlagents.trainers.trainer.on\_policy\_trainer

## OnPolicyTrainer Objects

```python
class OnPolicyTrainer(RLTrainer)
```

The PPOTrainer is an implementation of the PPO algorithm.

#### \_\_init\_\_

```python
 | __init__(behavior_name: str, reward_buff_cap: int, trainer_settings: TrainerSettings, training: bool, load: bool, seed: int, artifact_path: str)
```

Responsible for collecting experiences and training an on-policy model.

**Arguments**:

- `behavior_name`: The name of the behavior associated with trainer config
- `reward_buff_cap`: Max reward history to track in the reward buffer
- `trainer_settings`: The parameters for the trainer.
- `training`: Whether the trainer is set for training.
- `load`: Whether the model should be loaded.
- `seed`: The seed the model will be initialized with
- `artifact_path`: The directory within which to store artifacts from this trainer.

#### add\_policy

```python
 | add_policy(parsed_behavior_id: BehaviorIdentifiers, policy: Policy) -> None
```

Adds policy to trainer.

**Arguments**:

- `parsed_behavior_id`: Behavior identifiers that the policy should belong to.
- `policy`: Policy to associate with name_behavior_id.

# mlagents.trainers.trainer.off\_policy\_trainer

## OffPolicyTrainer Objects

```python
class OffPolicyTrainer(RLTrainer)
```

The SACTrainer is an implementation of the SAC algorithm, with support
for discrete actions and recurrent networks.

#### \_\_init\_\_

```python
 | __init__(behavior_name: str, reward_buff_cap: int, trainer_settings: TrainerSettings, training: bool, load: bool, seed: int, artifact_path: str)
```

Responsible for collecting experiences and training an off-policy model.

**Arguments**:

- `behavior_name`: The name of the behavior associated with trainer config
- `reward_buff_cap`: Max reward history to track in the reward buffer
- `trainer_settings`: The parameters for the trainer.
- `training`: Whether the trainer is set for training.
- `load`: Whether the model should be loaded.
- `seed`: The seed the model will be initialized with
- `artifact_path`: The directory within which to store artifacts from this trainer.

#### save\_model

```python
 | save_model() -> None
```

Saves the final training model to memory
Overrides the default to save the replay buffer.

#### save\_replay\_buffer

```python
 | save_replay_buffer() -> None
```

Save the training buffer's update buffer to a pickle file.

#### load\_replay\_buffer

```python
 | load_replay_buffer() -> None
```

Loads the last saved replay buffer from a file.

#### add\_policy

```python
 | add_policy(parsed_behavior_id: BehaviorIdentifiers, policy: Policy) -> None
```

Adds policy to trainer.

# mlagents.trainers.trainer.rl\_trainer

## RLTrainer Objects

```python
class RLTrainer(Trainer)
```

This class is the base class for trainers that use Reward Signals.

#### end\_episode

```python
 | end_episode() -> None
```

A signal that the Episode has ended. The buffer must be reset.
Get only called when the academy resets.

#### create\_optimizer

```python
 | @abc.abstractmethod
 | create_optimizer() -> TorchOptimizer
```

Creates an Optimizer object

#### save\_model

```python
 | save_model() -> None
```

Saves the policy associated with this trainer.

#### advance

```python
 | advance() -> None
```

Steps the trainer, taking in trajectories and updates if ready.
Will block and wait briefly if there are no trajectories.

# mlagents.trainers.trainer.trainer

## Trainer Objects

```python
class Trainer(abc.ABC)
```

This class is the base class for the mlagents_envs.trainers

#### \_\_init\_\_

```python
 | __init__(brain_name: str, trainer_settings: TrainerSettings, training: bool, load: bool, artifact_path: str, reward_buff_cap: int = 1)
```

Responsible for collecting experiences and training a neural network model.

**Arguments**:

- `brain_name`: Brain name of brain to be trained.
- `trainer_settings`: The parameters for the trainer (dictionary).
- `training`: Whether the trainer is set for training.
- `artifact_path`: The directory within which to store artifacts from this trainer
- `reward_buff_cap`:

#### stats\_reporter

```python
 | @property
 | stats_reporter()
```

Returns the stats reporter associated with this Trainer.

#### parameters

```python
 | @property
 | parameters() -> TrainerSettings
```

Returns the trainer parameters of the trainer.

#### get\_max\_steps

```python
 | @property
 | get_max_steps() -> int
```

Returns the maximum number of steps. Is used to know when the trainer should be stopped.

**Returns**:

The maximum number of steps of the trainer

#### get\_step

```python
 | @property
 | get_step() -> int
```

Returns the number of steps the trainer has performed

**Returns**:

the step count of the trainer

#### threaded

```python
 | @property
 | threaded() -> bool
```

Whether or not to run the trainer in a thread. True allows the trainer to
update the policy while the environment is taking steps. Set to False to
enforce strict on-policy updates (i.e. don't update the policy when taking steps.)

#### should\_still\_train

```python
 | @property
 | should_still_train() -> bool
```

Returns whether or not the trainer should train. A Trainer could
stop training if it wasn't training to begin with, or if max_steps
is reached.

#### reward\_buffer

```python
 | @property
 | reward_buffer() -> Deque[float]
```

Returns the reward buffer. The reward buffer contains the cumulative
rewards of the most recent episodes completed by agents using this
trainer.

**Returns**:

the reward buffer.

#### save\_model

```python
 | @abc.abstractmethod
 | save_model() -> None
```

Saves model file(s) for the policy or policies associated with this trainer.

#### end\_episode

```python
 | @abc.abstractmethod
 | end_episode()
```

A signal that the Episode has ended. The buffer must be reset.
Get only called when the academy resets.

#### create\_policy

```python
 | @abc.abstractmethod
 | create_policy(parsed_behavior_id: BehaviorIdentifiers, behavior_spec: BehaviorSpec) -> Policy
```

Creates a Policy object

#### add\_policy

```python
 | @abc.abstractmethod
 | add_policy(parsed_behavior_id: BehaviorIdentifiers, policy: Policy) -> None
```

Adds policy to trainer.

#### get\_policy

```python
 | get_policy(name_behavior_id: str) -> Policy
```

Gets policy associated with name_behavior_id

**Arguments**:

- `name_behavior_id`: Fully qualified behavior name

**Returns**:

Policy associated with name_behavior_id

#### advance

```python
 | @abc.abstractmethod
 | advance() -> None
```

Advances the trainer. Typically, this means grabbing trajectories
from all subscribed trajectory queues (self.trajectory_queues), and updating
a policy using the steps in them, and if needed pushing a new policy onto the right
policy queues (self.policy_queues).

#### publish\_policy\_queue

```python
 | publish_policy_queue(policy_queue: AgentManagerQueue[Policy]) -> None
```

Adds a policy queue to the list of queues to publish to when this Trainer
makes a policy update

**Arguments**:

- `policy_queue`: Policy queue to publish to.

#### subscribe\_trajectory\_queue

```python
 | subscribe_trajectory_queue(trajectory_queue: AgentManagerQueue[Trajectory]) -> None
```

Adds a trajectory queue to the list of queues for the trainer to ingest Trajectories from.

**Arguments**:

- `trajectory_queue`: Trajectory queue to read from.

# mlagents.trainers.settings

#### deep\_update\_dict

```python
deep_update_dict(d: Dict, update_d: Mapping) -> None
```

Similar to dict.update(), but works for nested dicts of dicts as well.

## RewardSignalSettings Objects

```python
@attr.s(auto_attribs=True)
class RewardSignalSettings()
```

#### structure

```python
 | @staticmethod
 | structure(d: Mapping, t: type) -> Any
```

Helper method to structure a Dict of RewardSignalSettings class. Meant to be registered with
cattr.register_structure_hook() and called with cattr.structure(). This is needed to handle
the special Enum selection of RewardSignalSettings classes.

## ParameterRandomizationSettings Objects

```python
@attr.s(auto_attribs=True)
class ParameterRandomizationSettings(abc.ABC)
```

#### \_\_str\_\_

```python
 | __str__() -> str
```

Helper method to output sampler stats to console.

#### structure

```python
 | @staticmethod
 | structure(d: Union[Mapping, float], t: type) -> "ParameterRandomizationSettings"
```

Helper method to a ParameterRandomizationSettings class. Meant to be registered with
cattr.register_structure_hook() and called with cattr.structure(). This is needed to handle
the special Enum selection of ParameterRandomizationSettings classes.

#### unstructure

```python
 | @staticmethod
 | unstructure(d: "ParameterRandomizationSettings") -> Mapping
```

Helper method to a ParameterRandomizationSettings class. Meant to be registered with
cattr.register_unstructure_hook() and called with cattr.unstructure().

#### apply

```python
 | @abc.abstractmethod
 | apply(key: str, env_channel: EnvironmentParametersChannel) -> None
```

Helper method to send sampler settings over EnvironmentParametersChannel
Calls the appropriate sampler type set method.

**Arguments**:

- `key`: environment parameter to be sampled
- `env_channel`: The EnvironmentParametersChannel to communicate sampler settings to environment

## ConstantSettings Objects

```python
@attr.s(auto_attribs=True)
class ConstantSettings(ParameterRandomizationSettings)
```

#### \_\_str\_\_

```python
 | __str__() -> str
```

Helper method to output sampler stats to console.

#### apply

```python
 | apply(key: str, env_channel: EnvironmentParametersChannel) -> None
```

Helper method to send sampler settings over EnvironmentParametersChannel
Calls the constant sampler type set method.

**Arguments**:

- `key`: environment parameter to be sampled
- `env_channel`: The EnvironmentParametersChannel to communicate sampler settings to environment

## UniformSettings Objects

```python
@attr.s(auto_attribs=True)
class UniformSettings(ParameterRandomizationSettings)
```

#### \_\_str\_\_

```python
 | __str__() -> str
```

Helper method to output sampler stats to console.

#### apply

```python
 | apply(key: str, env_channel: EnvironmentParametersChannel) -> None
```

Helper method to send sampler settings over EnvironmentParametersChannel
Calls the uniform sampler type set method.

**Arguments**:

- `key`: environment parameter to be sampled
- `env_channel`: The EnvironmentParametersChannel to communicate sampler settings to environment

## GaussianSettings Objects

```python
@attr.s(auto_attribs=True)
class GaussianSettings(ParameterRandomizationSettings)
```

#### \_\_str\_\_

```python
 | __str__() -> str
```

Helper method to output sampler stats to console.

#### apply

```python
 | apply(key: str, env_channel: EnvironmentParametersChannel) -> None
```

Helper method to send sampler settings over EnvironmentParametersChannel
Calls the gaussian sampler type set method.

**Arguments**:

- `key`: environment parameter to be sampled
- `env_channel`: The EnvironmentParametersChannel to communicate sampler settings to environment

## MultiRangeUniformSettings Objects

```python
@attr.s(auto_attribs=True)
class MultiRangeUniformSettings(ParameterRandomizationSettings)
```

#### \_\_str\_\_

```python
 | __str__() -> str
```

Helper method to output sampler stats to console.

#### apply

```python
 | apply(key: str, env_channel: EnvironmentParametersChannel) -> None
```

Helper method to send sampler settings over EnvironmentParametersChannel
Calls the multirangeuniform sampler type set method.

**Arguments**:

- `key`: environment parameter to be sampled
- `env_channel`: The EnvironmentParametersChannel to communicate sampler settings to environment

## CompletionCriteriaSettings Objects

```python
@attr.s(auto_attribs=True)
class CompletionCriteriaSettings()
```

CompletionCriteriaSettings contains the information needed to figure out if the next
lesson must start.

#### need\_increment

```python
 | need_increment(progress: float, reward_buffer: List[float], smoothing: float) -> Tuple[bool, float]
```

Given measures, this method returns a boolean indicating if the lesson
needs to change now, and a float corresponding to the new smoothed value.

## Lesson Objects

```python
@attr.s(auto_attribs=True)
class Lesson()
```

Gathers the data of one lesson for one environment parameter including its name,
the condition that must be fullfiled for the lesson to be completed and a sampler
for the environment parameter. If the completion_criteria is None, then this is
the last lesson in the curriculum.

## EnvironmentParameterSettings Objects

```python
@attr.s(auto_attribs=True)
class EnvironmentParameterSettings()
```

EnvironmentParameterSettings is an ordered list of lessons for one environment
parameter.

#### structure

```python
 | @staticmethod
 | structure(d: Mapping, t: type) -> Dict[str, "EnvironmentParameterSettings"]
```

Helper method to structure a Dict of EnvironmentParameterSettings class. Meant
to be registered with cattr.register_structure_hook() and called with
cattr.structure().

## TrainerSettings Objects

```python
@attr.s(auto_attribs=True)
class TrainerSettings(ExportableSettings)
```

#### structure

```python
 | @staticmethod
 | structure(d: Mapping, t: type) -> Any
```

Helper method to structure a TrainerSettings class. Meant to be registered with
cattr.register_structure_hook() and called with cattr.structure().

## CheckpointSettings Objects

```python
@attr.s(auto_attribs=True)
class CheckpointSettings()
```

#### prioritize\_resume\_init

```python
 | prioritize_resume_init() -> None
```

Prioritize explicit command line resume/init over conflicting yaml options.
if both resume/init are set at one place use resume

## RunOptions Objects

```python
@attr.s(auto_attribs=True)
class RunOptions(ExportableSettings)
```

#### from\_argparse

```python
 | @staticmethod
 | from_argparse(args: argparse.Namespace) -> "RunOptions"
```

Takes an argparse.Namespace as specified in `parse_command_line`, loads input configuration files
from file paths, and converts to a RunOptions instance.

**Arguments**:

- `args`: collection of command-line parameters passed to mlagents-learn

**Returns**:

RunOptions representing the passed in arguments, with trainer config, curriculum and sampler
configs loaded from files.

repository: simoninithomas/ml-agents

branch_name: refs/heads/master

extension: md

gha_language: C#

license_type: permissive

repo_name: simoninithomas/ml-agents


text:
# Volume Ingestion
This script is for static provisioning in csi-powerscale. You can manage volumes which exist on PowerScale but were created outside of CSI driver.
## Prerequisites
The NFS export corresponding to the directory needs to exist. It's ID would be used in the volumehandle as described below. It need not have the kubernetes nodes added as clients.

If Quotas are enabled in the driver, it is recommended that you add the Quota ID to the description of the NFS export in the following format:
CSI_QUOTA_ID:sC-kAAEAAAAAAAAAAAAAQEpVAAAAAAAA

The details of various Quotas can be obtained via the following REST API of OneFS:
GET
/platform/1/quota/quotas

Volume Handle is expected to be present in this pattern VolName + VolumeIDSeparator + exportID + VolumeIDSeparator + accessZone for ex. "demovol1=\_=\_=303=\_=\_=System"

## Running the script
Command Line inputs are taken in this order: volumename, volumehandle, storageclassname, accessmode, storage size, pvname, pvcname
## Examples
To provision a Volume named sample14 in access zone csi-zone having export-id as 6, volumehandle will be sample14=\_=\_=6=\_=\_=csi-zone. Here we are using a custom storage class named as customstorageclass1, access mode as ReadWriteMany, storage size as 500M, pv name as pv1, pvc name as pvc1, we will be running :

./ingestion_test.sh sample14 sample14=\_=\_=6=\_=\_=csi-zone customstorageclass1 ReadWriteMany 500M pv1 pvc1


text:
# Upgrading to a new Release

## Train -> Xena

If you're running centos7, this will be annoying. This involves a major openstack version upgrade, python2->python3 upgrade, and host-os upgrade.

### Backup

On the controller node, back up the following.

* `/etc/ansible`
* `/etc/kolla`
* your mysql DB

#### mariadb

[https://docs.openstack.org/kolla-ansible/latest/admin/mariadb-backup-and-restore.html](https://docs.openstack.org/kolla-ansible/latest/admin/mariadb-backup-and-restore.html#full)

```
./cc-ansible mariadb_backup
docker run --rm -it \
  -v mariadb_backup:/mariadb_backup:ro \
  -v /tmp/backup:/backup \
  ubuntu:latest bash

# copy the latest backup from `/mariadb_backup to /backup`
```

On the Deploy node, back up the following:

* your git checkout of `chi-in-a-box`
* your `site-config` directory, especially including the `vault_password`

### Clean up the controller nodes

#### Ubuntu 20.04

```
# Run these on your controller node, after making a backup.
mv /etc/ansible /etc/ansible.bak
mv /etc/kolla /etc/kolla.bak
```

### Check out new chi-in-a-box

Once you've backed up your `chi-in-a-box` directory, run the following commands to get the latest code, and clean up leftover files.

```
# Run this in your chi-in-a-box directory, AFTER MAKING A BACKUP!
cd </path/to/chi-in-a-box>
git fetch
git checkout stable/xena
rm -rf venv
rm -rf .facts
./cc-ansible bootstrap-servers
```

#### Update passwords.yml

We need to set some new passwords that the new version requires. The `kolla-mergepwd` command will pull in values that are set in `site-config.example`, but missing from your passwords file.

```
# backup your passwords.yml file
cp $SITE_CONFIG/passwords.yml $SITE_CONFIG/passwords.yml.bak

$CHI_IN_A_BOX/venv/bin/ansible-vault decrypt \
  --vault-password-file $SITE_CONFIG/vault_password \
  $SITE_CONFIG/passwords.yml

# merge new passwords that are needed
$CHI_IN_A_BOX/venv/bin/kolla-mergepwd \
  --old $SITE_CONFIG/passwords.yml \
  --new $CHI_IN_A_BOX/site-config.example/passwords.yml \
  --final $SITE_CONFIG/new_passwords.yml

# if the new file looks ok, run:
mv $SITE_CONFIG/new_passwords.yml $SITE_CONFIG/passwords.yml

$CHI_IN_A_BOX/venv/bin/ansible-vault encrypt \
  --vault-password-file $SITE_CONFIG/vault_password \
  $SITE_CONFIG/passwords.yml

# Finally, edit the resulting file to replace "null" with "".
# The empty values will be auto-populated.
cd $CHI_IN_A_BOX
./cc-ansible edit_passwords
```

each line that looks like: `key: null` should be modified to look like `key:`

#### Update inventory/hosts

```
# make a backup of your inventory
mv $SITE_CONFIG/inventory/hosts $SITE_CONFIG/inventory/hosts.bak

cp $CHI_IN_A_BOX/site-config.example/inventory/hosts \
   $SITE_CONFIG/inventory/hosts

# edit the groups at the top to put your controller node back
vim $SITE_CONFIG/inventory/hosts
```

### Get new containers, and deploy services

```
cd $CHI_IN_A_BOX
# Recreate the virtualenv, now that we've updated inventory/hosts
./cc-ansible bootstrap-servers

# pull new containers
./cc-ansible pull

# deploy the updated containers
./cc-ansible deploy
```

repository: ChameleonCloud/chi-in-a-box

branch_name: refs/heads/stable/xena

gha_language: Shell

repo_name: ChameleonCloud/chi-in-a-box


text:
+++
hook = "How we build minimal, platform deployable, Rack service stubs to take the pain out of developing applications that depend on an extensive service-oriented architecture."
location = "San Francisco"
published_at = 2013-06-03T17:22:11Z
title = "SOA and Service Stubs"
+++

[Service-oriented architecture](http://en.wikipedia.org/wiki/Service-oriented_architecture) (SOA) is a popular technique at a number of software development shops these days, each trying to avoid the age-old problem of the monolithic codebase. This includes us at Heroku, where the underlying kernel that supports the Heroku platform is fundamentally decomposed into a number of backend services, each of which having a well-defined set of responsibilities, and a team to operate it.

Despite us being happily well-invested in this architectural approach, SOA has a number of downsides, one of the foremost being that running a single application in isolation becomes difficult because it relies on so many external services.

A traditional solution for us has been to stub these services at a high-level to avoid making remote calls during development and testing. Here are some real examples from our codebase of what these service stubs looked like:

``` ruby
# Logplex stub
Logplex.stub(:create_token)

# Addons stub
Addons::Client.mock! if ENV["RACK_ENV"] == "test"

# Domain management service stub
Maestro::ResourceHandler.mock!

# Billing management service stub
def detect_handler
  return RealHandler.new if ENV.has_key?("CORE_SHUSHU_URL")
  MockHandler.new
end

# Process management service stub
return ServiceApi::MockHandler.new("https://psmgr.heroku-\#{name}.com") unless psmgr_url

# Resource provisioning
def api_calls_enabled?
  Utils.in_cloud? || RAILS_ENV == 'test' || ENV['API_CALLS_ENABLED'] # OMG HACK
end
response = handler.install(app, user, options) if api_calls_enabled?
```

## Progression (#progression)

Implementations varied as more services were added over time, and generally became more sophisticated as we learned the downsides of particular approaches and iterated on them. This progression eventually led to the _Rack service stubs_ we use today, and which are detailed in the next section.

The starting point was to simply use a stubbing framework for testing to stub out any methods that make a call to a remote service:

``` ruby
Logplex.stub(:create_token)
```

This approach will get tests passing, but couples your tests to the interface of the service handler, and prevents the handler itself from being exercised. What if handlers could be written that knew how to mock themselves?

``` ruby
Addons::Client.mock! if ENV["RACK_ENV"] == "test"
```

This works pretty well for testing, but leaves it up to the developer to find themselves a working staging version of the remote service that won't balk at being consumed by their development installation. This can work given a company-wide culture of well-documented and well-maintained staging environments, but even then, development can be slowed or blocked if a staging installation owned by another team breaks.

A possible next step is to build service handlers that will respond correctly in both development and testing environments:

``` ruby
def detect_handler
  return RealHandler.new if ENV.has_key?("CORE_SHUSHU_URL")
  MockHandler.new
end
```

Now we're getting somewhere! Our mocks should behave reasonably during development and testing, and switch over to the real handler when the code hits staging or production.

While this kind of stub generally works pretty well, it still leaves us with a large disparity between development and production in that two different handlers, and therefore two completely different code paths are run in the two environments. A problem caused by this gap would hopefully be caught in a high-fidelity staging environment before making it to production, but even in staging, debugging is harder and slower compared to a local production copy.

## Rack service stubs (#rack)

While re-approaching the application code for our API, we started experimenting with doing away with the variety of stub handlers, and tried replacing them with actual implementations of the foreign stubs written with Rack-compliant libraries. These Rack stubs are designed to implement only the subset of the foreign API required by the calling app, and are greatly simplified to provide the bare minimum of the requirements for a correct response (and do little else).

Here's an example Rack stub written for one of the API's backend services in Sinatra:

``` ruby
class IonStub < Sinatra::Base
  post "/endpoints" do
    status 201
    content_type :json
    MultiJson.encode({
      id:           123,
      cname:        "tokyo-1234.herokussl.com",
      elb_dns_name: "elb016353-1923944129.us-east-1.elb.amazonaws.com",
    })
  end
end
```

Because the stub is a fully functional application in its own right, it becomes immediately useful in both development and testing. A platform that trivializes deployment extends this use to cloud-hosted development and staging environments as well (i.e. you can `git push heroku master` this stub and to make it available for other apps to talk to).

## Testing (#testing)

Use of service stubs in tests is made simple by using [Webmock's](https://github.com/bblimke/webmock) excellent Rack support to intercept requests made to a particular URL and send them off to be processed by the stub. Here are some examples of simple helper methods that we use in the API:

``` ruby
# generic helper for use with any service
def stub_service(uri, stub, &block)
  uri = URI.parse(uri)
  port = uri.port != uri.default_port ? ":\#{uri.port}" : ""
  stub = block ? Sinatra.new(stub, &block) : stub
  stub_request(:any, /^\#{uri.scheme}:\/\/(.*:.*@)?\#{uri.host}\#{port}\/.*$/).
    to_rack(stub)
end

# One-liners specifically for a specific stubs, pointing to configured
# locations of each remote service. A configuration value might look like:
#
#<EMAIL_ADDRESS>#

def stub_addons
  stub_service(ENV["ADDONS_URL"], AddonsStub, &block)
end

def stub_ion(&block)
  stub_service(ENV["ION_URL"], IonStub, &block)
end
```

Now a stub can be initialized in a test and a remote service call made:

``` ruby
it "should make a call to ion" do
  stub_ion
  endpoint = IonAPI.create_endpoint!
end
```

This is particularly useful for tests that aim to exercise as many levels of application code as possible by stubbing at the level of HTTP calls rather than at a local service library, and ensuring that we're running as much production code as we can.

Error conditions from the remote service can be tested by extending stubs with Sinatra's widely-known DSL for particular test cases:

``` ruby
it "should raise an error on a bad ion response" do
  stub_ion do
    post("/endpoints") { 422 }
  end
  lambda do
    IonAPI.create_endpoint!
  end.should raise_error(IonAPI::Error)
end
```

## Development (#development)

By including a small snippet of conditional run code along with each stub, we ensure that each can be booted as an application in its own right:

``` ruby
class IonStub < Sinatra::Base
  ..
end

if __FILE__ == $0
  $stdout.sync = $stderr.sync = true
  IonStub.run! port: 5100
end
```

Sinatra will boot such a stub by simply invoking its filename:

``` bash
$ ruby test/test_support/service_stubs/ion_stub.rb
>> Listening on <IP_ADDRESS>:5100, CTRL+C to stop
```

Locally exporting an environmental variable ensures that the main app points to a booted stub in its development context:

```
ION_URL=http://localhost:5100
```

With the stub running and the proper configuration in place, the main app can be booted (in this example, the Heroku API):

``` bash
$ bundle exec puma --quiet --threads 8:32 --port 5000 config.ru
listening on addr=<IP_ADDRESS>:5000 fd=13
```

Requests to the app will call into the running service stub, allowing us to go a long way towards simulating a working service cloud with minimal setup required. In the example above, we've stubbed the API's infrastructure service, so we can pretend to provision an `ssl:endpoint`:

``` bash
$ export HEROKU_HOST=http://localhost:5000
$ heroku addons:add ssl:endpoint
$ heroku certs:add secure.example.org.pem secure.example.org.key
Adding SSL Endpoint to great-cloud... done
WARNING: ssl_cert provides no domain(s) that are configured for this Heroku app
great-cloud now served by tokyo-1234.herokussl.com
Certificate details:
Common Name(s): alt1.example.org
                alt2.example.org
                secure.example.org

Expires At:     2031-05-05 19:05 UTC
Issuer:         /C=US/ST=California/L=San Francisco/O=Heroku/CN=secure.example.org
Starts At:      2011-05-10 19:05 UTC
Subject:        /C=US/ST=California/L=San Francisco/O=Heroku/CN=secure.example.org
SSL certificate is self signed.
```

### Foreman (#foreman)

The process can be further streamlined by using [Foreman](https://github.com/ddollar/foreman) and adding stubs to the list of processes that should be started:

```
web:     bundle exec puma --quiet --threads 8:32 --port 5000 config.ru

# stubs
ionstub: bundle exec ruby service_stubs/ion_stub.rb
```

Put configuration in a place where Foreman can find it, like a local `.env`:

```
ION_URL=http://localhost:5100
```

With stub processes in place, issuing a `foreman start` results in something like the following:

```
18:18:22 web.1              | listening on addr=<IP_ADDRESS>:5000 fd=13
18:18:22 ionstub.1          | == Sinatra/1.3.5 has taken the stage on 5100 for development with backup from WEBrick
```

That convenience further compounds with the more service stubs that are added. Here's a sample of the boot process of the Heroku API:

```
18:20:38 web.1              | listening on addr=<IP_ADDRESS>:5000 fd=13
18:20:38 addonsstub.1       | == Sinatra/1.3.5 has taken the stage on 4101 for development with backup from WEBrick
18:20:38 apollostub.1       | == Sinatra/1.3.5 has taken the stage on 4111 for development with backup from WEBrick
18:20:38 eventmanagerstub.1 | == Sinatra/1.3.5 has taken the stage on 4102 for development with backup from WEBrick
18:20:38 ionstub.1          | == Sinatra/1.3.5 has taken the stage on 4103 for development with backup from WEBrick
18:20:38 paymentsstub.1     | == Sinatra/1.3.5 has taken the stage on 4109 for development with backup from WEBrick
18:20:38 psmgrstub.1        | == Sinatra/1.3.5 has taken the stage on 4107 for development with backup from WEBrick
18:20:38 maestrostub.1      | == Sinatra/1.3.5 has taken the stage on 4105 for development with backup from WEBrick
18:20:38 yobukostub.1       | == Sinatra/1.3.5 has taken the stage on 4114 for development with backup from WEBrick
18:20:38 logplexstub.1      | == Sinatra/1.3.5 has taken the stage on 4104 for development with backup from WEBrick
18:20:38 vaultstub.1        | == Sinatra/1.3.5 has taken the stage on 4112 for development with backup from WEBrick
18:20:38 vaultusagestub.1   | == Sinatra/1.3.5 has taken the stage on 4113 for development with backup from WEBrick
18:20:38 zendeskssostub.1   | == Sinatra/1.3.5 has taken the stage on 4115 for development with backup from WEBrick
```

A working example of this project is available at [brandur/service-stub-example](https://github.com/brandur/service-stub-example).

license: MIT

repository: brandur/sorg

gha_language: Go

gha_license_id: MIT

repo_name: brandur/sorg


text:
# SpeciesEvolver: evolve life in simulated landscapes

[![status](https://joss.theoj.org/papers/446f3d17d642682b234ffed2b53198f6/status.svg)](https://joss.theoj.org/papers/446f3d17d642682b234ffed2b53198f6)

Life evolves alongside landscapes by biotic and abiotic processes under complex
dynamics at Earth's surface. Researchers who wish to explore these dynamics can
use this component as a tool for them to build landscape-life evolution models.
Landlab components, including SpeciesEvolver are designed to work with a shared
model grid. Researchers can build novel models using plug-and-play surface
process components to evolve the grid's landscape alongside the life tracked by
SpeciesEvolver. The simulated life evolves following customizable processes.

## Documentation and installation

Landlab documentation is hosted on this [ReadTheDocs page](https://landlab.readthedocs.io/en/master), including Landlab installation instructions. SpeciesEvolver is installed with Landlab.

SpeciesEvolver documentation is located [here](https://landlab.readthedocs.io/en/master/reference/components/species_evolution.html).

## SpeciesEvolver tutorial

A tutorial of this component exists in the form of a Jupyter Notebook. It is
located in ``/landlab/notebooks/tutorials`` titled, ``Introduction_to_SpeciesEvolver.ipynb``.

A static version of the same tutorial can be viewed [here](https://nbviewer.jupyter.org/github/landlab/landlab/blob/master/notebooks/tutorials/species_evolution/Introduction_to_SpeciesEvolver.ipynb).

All Landlab tutorials can be launched from [this directory](https://mybinder.org/v2/gh/landlab/landlab/release?filepath=welcome.ipynb) using binder.

## Get or give help

[Open an Issue here](https://github.com/landlab/landlab/issues) where we can
respond to your questions, comments, issues, suggestions, or any identified
bugs related to Landlab including SpeciesEvolver.

repository: mwrossi/landlab

repo_name: mwrossi/landlab


text:
# Change Log

All notable changes to this project will be documented in this file.
See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.

## [0.0.38](https://github.com/reimagined/resolve/compare/v0.0.27...v0.0.38) (2017-10-20)

### Bug Fixes

* add middlewares with empty params to create-resolve-app ([0ca16af](https://github.com/reimagined/resolve/commit/0ca16af)), closes [#279](https://github.com/reimagined/resolve/issues/279)
* display compile-time errors from server-side in dev mode ([41c41fc](https://github.com/reimagined/resolve/commit/41c41fc)), closes [#265](https://github.com/reimagined/resolve/issues/265)
* fix default config and error handling for graphql resolvers ([2bfd3c2](https://github.com/reimagined/resolve/commit/2bfd3c2))
* fix template ([d70aa12](https://github.com/reimagined/resolve/commit/d70aa12))
* fix templates issues ([f2b065a](https://github.com/reimagined/resolve/commit/f2b065a)), closes [#321](https://github.com/reimagined/resolve/issues/321) [#318](https://github.com/reimagined/resolve/issues/318) [#315](https://github.com/reimagined/resolve/issues/315)
* fix tests ([6984880](https://github.com/reimagined/resolve/commit/6984880))
* use server bundling without node_modules for socket.io  ([13e99ff](https://github.com/reimagined/resolve/commit/13e99ff))

### Features

* add graphql endpoint ([826bf48](https://github.com/reimagined/resolve/commit/826bf48))
* implement multiple read-models and better error handling ([aff2d5f](https://github.com/reimagined/resolve/commit/aff2d5f))
* provide jwt on client side ([1df756d](https://github.com/reimagined/resolve/commit/1df756d)), closes [#270](https://github.com/reimagined/resolve/issues/270)

### BREAKING CHANGES

* view models are available without graphql via get-request with appropriate view-model name in format `/api/query/${read_model_name}` with mandatory eventTypes and/or aggregateIds field for on-demand query
* read-models are provided in configuration by array instead of one element
* any read-model has own name, which used in query API in format `/api/query/${read_model_name}`
* rename all eventHandlers to projection, since it can be free-form entity, which is supported by selected read-model adapter

## [0.0.27](https://github.com/reimagined/resolve/compare/v0.0.26...v0.0.27) (2017-09-20)

### Bug Fixes

* use only npm for installation ([#269](https://github.com/reimagined/resolve/issues/269)) ([7397b81](https://github.com/reimagined/resolve/commit/7397b81)), closes [#211](https://github.com/reimagined/resolve/issues/211)

### Performance Improvements

* deleting unnecessary template files ([d01e562](https://github.com/reimagined/resolve/commit/d01e562)), closes [#200](https://github.com/reimagined/resolve/issues/200)

## [0.0.26](https://github.com/reimagined/resolve/compare/v0.0.25...v0.0.26) (2017-09-08)

### Bug Fixes

* **resolve-scripts:** static content serving in production mode from dist directory ([9582382](https://github.com/reimagined/resolve/commit/9582382))

## 0.0.25 (2017-09-08)

### Bug Fixes

* **resolve-scripts:** disable ssr in dev mode (#233) ([255ede1](https://github.com/reimagined/resolve/commit/255ede1))

repository: konstantinbelyakov/resolve

repo_name: konstantinbelyakov/resolve


text:
---
layout: post
type: news
date: 2020-12-03 06:00:00 +0000
title: "Service Mesh Offers Promising Solution for Cloud Native Networking"
image: /assets/images/news/2020-12-03-service-mesh-offers-promising-solution-for-cloud-native-networking/service-mesh-performance-specification.png
eurl: http://www.enterprisenetworkingplanet.com/datacenter/datacenter-blog/service-mesh-cloud-native-networking.html
---

**Service mesh abstraction**

While having lots of different service mesh technologies is good for choice, it's not necessarily a good thing for simplicity or interoperability. That's where the concept of service mesh abstraction comes into play.

At the recent KubeCon NA 2020 virtual event, Lee Calcote, co-chair of the Cloud Native Computing Foundation (CNCF) Networking Special Interest Group (SIG) and founder of Layer5, outlined how the different service mesh abstraction technologies fit together.

The Service Mesh Interface (SMI) is a way for any compliant service mesh to plug into Kubernetes. The Service Mesh Performance (SMP) abstraction is all about providing visibility into service mesh performance though a common interface. The third key abstraction is known as Hamlet and it provides multi-vendor service interoperation and mesh federation capabilities.

**Service mesh benefits**

There are a number of different benefits that service meshes can bring, which are helping to accelerate adoption. Calcote explained that with a service mesh there is a decoupling of developer and operations teams such that each can iterate independently.

As such, operators can make changes to infrastructure independent of developers. DevOps is supposed to mean developer and operations teams work together, but the reality is often quite different and the ability to build application and infrastructure separately is why service mesh has been such a winning proposition for so many organizations.

"We live within a software defined network landscape, and service meshes in some respects are sort of a next-gen SDN," Calcote said.

**Read the full [article on Enterprise Networking Planet](https://www.enterprisenetworkingplanet.com/datacenter/datacenter-blog/service-mesh-cloud-native-networking.html)**


text:
# TravelBee the travel planer

## About the app
TravelBee is a personal travel planer App that helps to organize itineraries. By requesting APIs of different web services, it provides the user with additional information about their destination. The information get´s stored and viewed in the sections `#my trips`. By deleting and updating picklists and cards, the stored data can be managed.

## Install
All dependencies have been included within the package.json.

1. Clone the project from the git repository for local usage.
2. Use npm install and run bundle install from your shell.

```shell
$ git clone https://github.com/CrazyBee81/travel-app.git
$ npm install
```
## Usage

This project uses three public APIs, which are being accessed while performing a search. Please consider, that the access keys are not included after cloning the git hub repro.

To get started, it´s required to sign up for the following api services:
[geonames](http://www.geonames.org/export/web-services.html) to get geo data
[weatherbit](https://www.weatherbit.io/account/create) to get weather data
[pixabay](https://pixabay.com/api/docs/) to get weather data

Next step is, to declare the environment variables in the .env file.

```javascript
geoname_user='user_name'
pixabay_key='your-pixabay-api-id'
weatherbit_key='your-weatherbit-api-id'
```

**Production and Development Environment**
There are two different webpack.configs one for production and another one for development. Depending on the purpose, the state of the website can be changed to make development easier or to increase the performance of the website in the browser. That means when building the app with npm a user should relate to either build-dev or build-prod, e.g.

```shell
$ npm run build-dev
```

**Local storage and service workers**
Furthermore, it´s worth mentioning that the App uses local storage to store search data. When a user closes the page after performing a search and later revisit it, the result will reappear. The production environment makes also use of service workers, to allow offline usage. This way, a user sees a cached version of the site, even if the server is not running.

## Contributers
This apps has been build as part of the front-end developer nano degree of  Udacity, Inc. All the setup and configuration are based on the examples provided to me in this program.  Thank´s to all the great teachers and support staff!

## Contribution Guidelines
The code in this project has been written according to the Udacity style guidelines for writing code in JavaScript, CSS, and HTML. Before starting to contribute, please have a look at the following documents.

- [CSS Style Guide] (http://udacity.github.io/frontend-nanodegree-styleguide/css.html)
- [HTML Style Guide] (http://udacity.github.io/frontend-nanodegree-styleguide/index.html)
- [JavaScript Style Guide] (http://udacity.github.io/frontend-nanodegree-styleguide/javascript.html)

Most of the course requirements have been met. However, there are some additional tasks to extend the project which are still open. Your help is welcome to program the following features:
- Add end date and display length of trip.
- Pull in an image for the country from Pixabay API when the entered location brings up no results (good for obscure localities).
- Allow user to add multiple destinations on the same trip.
- Allow the user to add hotel and/or flight data.
- Integrate the REST Countries API to pull in data for the country being visited.
- Allow the user to remove the trip.
- Instead of just pulling a single day forecast, pull the forecast for multiple days.
- Allow user to Print their trip and/or export to PDF.

License
It is free software, and may be redistributed under the terms specified in the [LICENSE](https://github.com/CrazyBee81/travel-app/blob/main/LICENSE) file.

branch_name: refs/heads/main


text:
---
id: 478
title: Where are the Case Studies?
date: 2011-09-07T12:48:00+00:00
author: Admin
tumblr_simplystatistics_permalink:
  - http://simplystatistics.tumblr.com/post/9916013240/where-are-the-case-studies
tumblr_simplystatistics_id:
  -<PHONE_NUMBER>
dsq_thread_id:
  - 933945128
categories:
  - Uncategorized
tags:
  - Rant
slug: "where-are-the-case-studies"
---
Many case studies I find interesting don’t appear in JASA Applications and **Case Studies **or other applied statistics journals for that matter. Some because the technical skill needed to satisfy reviewers is not sufficiently impressive, others because they lack mathematical rigor. But perhaps the main reason for this disconnect is that many interesting case studies are developed by people outside our field or outside academia.

In this blog we will try to introduce readers to some of these case studies. I’ll start it off by pointing readers to Nate Silver’s FiveThirtyEight blog. Mr. Silver (yes, Mr. not Prof. nor Dr.) is one of my favorite statisticians. He first became famous for PECOTA; a system that uses data and statistics to predict the performance of baseball players. In FiveThirtyEight he uses a rather sophisticated meta-analysis approach to predicting election outcomes.

For example, for the 2008 election he used data from the primaries to calibrate pollsters and then properly weighed these pollsters’ predictions to give a more precise estimate of election results. He predicted Obama would win 349 to 189 with a 6.1% difference in the popular vote. The actual result was 365 to 173 with a difference of 7.2%. His website included graphs that very clearly illustrated the uncertainty of his prediction. These were updated daily and I had a ton of fun visiting his blog at least once a day. I also learned quite a bit, used his data in class, and gained insights that I have used in my own projects.

repository: rbind/simplystats

gha_language: HTML

repo_name: rbind/simplystats


text:
# Simplit

minimal parser for literate programming in `.js`, `.css`, `.html`.  easily extended for any programming language.  it scans a directory for files with the name  `file.js.md` or `file.html.md`, finds all the code fences matching the extension type, and concatenates them into a file named ie. `file.html`, `file.js` (the file is by default written next to the `.md` src).

---

## Use

1. `npm install -g simplit`
1. `cd somewhere`
1. `simplit`

you can additionally configure where it reads from and writes to;

- `simplit <src-path> <build-path>`

if a src path but not a build path is included, the src path will be used as the build path.

---

## Examples

this repo contains two example projects in [/examples](./examples).  clone this repo to give it a try

repository: colevandersWands/simplit

repo_name: colevandersWands/simplit


text:
# String_Length

`String_Length` returns the number of characters in the `source` string.

```csharp
String_Length (
	@source NVARCHAR (MAX),
	)
RETURNS INT
```

## Parameters

  - **source**: The source string.

## Returns

The number of characters in the `source` string.

## Example

```csharp
SELECT SQLNET::String_Length('This is a string.')
```

# String_Length4k

It is equivalent to `String_Length` except no NVARCHAR(MAX) parameters; it can be used when input data will never be over 4000 characters as this function offers better performance.

```csharp
String_Length4k (
	@source NVARCHAR (4000),
	)
RETURNS INT
```

## Example

```csharp
SELECT SQLNET::String_Length4k('This is a string.')
```

gha_license_id: NOASSERTION


text:
# TODO: Side projects
Ideas for side projects to implement if/when i have some free time.

# Motivation
This originally started at the begining of the covid pandimic, I've been working on re-writing a legacy system and even though it is a challenging problem, it did not provide me with any challenging coding exercises, (i.e understanding the old system is hard, implementitation is fairly straight forward). During the covid-10 lockdown my mental burnout got amplified. So this is my attempt to do some coding therapy :)

# Project Ideas
## Datastructures
- HashMap
- LRU Cache
- Bloom filter

## Algorithms
- Hash functions (at least two)
- HyperLogLog

## System
- Zeitgeist
- Counter Service
- Ad Server

## CLI Tools
- Find
- Grep

## App
- Rubber stamp canvase
- Flutter app
- [Write an Interperters in go](https://healeycodes.com/creating-the-golfcart-programming-language/)

## New Tech
- Idomatic unit tests in python
- Idomatic unit tests in go.
- Idomatic unit tests in Typescript/Javascript.
- Idomatic unit tests in for react (web ui)

## Implementations Deep dive
- [Guava Cache](https://github.com/google/guava/tree/master/guava/src/com/google/common/cache)
- Java ConcurrentHashMap
- Git
- Maps in Go

# Study Topics

## General
- Understand virtual method dispach.

## Books
- Algorithms

## Papers
- TBD

#### Videos
- [x] ***Mon 2020/04/06*** [It's Dangerous to go alone](https://www.youtube.com/watch?v=1i8ylq4j_EY)
  - Imposter syndrome awareness.
  - Have a support system to recover from burnouts.
  - Have some metrics, so you can objectively quantify your positives.
  - Fake it till you make it.

- [x] ***Sun 2020/04/05*** [The Myth of the Genius Programmer](https://www.youtube.com/watch?v=0SARbwvhupQ)
- [x] ***Sun 2020/04/05*** [How Open Source Projects Survive Poisonous People](https://www.youtube.com/watch?v=ZSFDm3UYkeE)

repository: ahodieb/todo-side-projects

repo_name: ahodieb/todo-side-projects


text:
# Jobster
Group 2 - Jobster: the Job application tracker

Link to live deployed app: https://jobster-group-2.herokuapp.com/aboutus

## Purpose
It can really be a pain to track all of your job applications, and we aim to alleviate this problem.

We have created a web app where, once signed up and logged in, users can track all of their applications in one place by submitting the appropriate information in our forms.  Just imagine not having to stress yourself over remembering details of each application!

Not only can users track all of their applications, but we also give the ability to upload resumes and cover letters.  Essentially a one stop shop to keep all job app related materials!

## Assignment
With your team, you’ll conceive and execute a design that solves a real-world problem. In creating your first collaborative full-stack application, you’ll combine a robust back end--with servers, databases, advanced APIs, and user authentication—-to an intuitive front end. You’ll continue to build on the agile development methodologies you’ve used throughout this course, like storing your project code in GitHub, managing your work with a project management tool, and implementing feature and bug fixes using the Git branch workflow and pull requests.

Instead of using the front end you developed for your first project, you should start from scratch.  Also, you’ve likely improved your skills since that first project, so with a stronger foundation now you can build a better application, using all of the additional practice you’ve had in the last several weeks.

## Technologies Used
This project was created and deployed using JavaScript, node.js (and associated packages), HTML, CSS, Handlebars, mySQL, Multer, Cloudinary, Figma, Dbdiagram.io, and Heroku.

## Demo!
Home Page: ![Jobster](https://user-images.githubusercontent.com/81654878/128737920-fc942f02-c014-412a-8509-558ae869f153.png)
Summary Page: ![Screenshot (422)](https://user-images.githubusercontent.com/81654878/128738082-a9f9dcd6-3d51-4250-aeef-81a3e7840289.png)
New Application Page: ![Screenshot (423)](https://user-images.githubusercontent.com/81654878/128738239-0bad1d3b-df23-46b6-9850-196defbe09b7.png)

## License
[MIT](https://choosealicense.com/licenses/mit/)

## Contact the contributors
Carlos Perez

https://github.com/cperezba

Christyn Garcia

https://github.com/christyns92

Harrison Kidd

https://github.com/hkidd

Joris Powathil

https://github.com/jorropowathil

Maryam Guppy

https://github.com/mguppy

repository: cperezba/Jobster

repo_name: cperezba/Jobster


text:
# SubZero Workshop

In this workshop you will create a continuously delivered serverless application that accepts, processes, and stores images using a variety of AWS services.

![](images/Application-Diagram.png)

## Resources

- [Serverless Application Model Documentation](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/what-is-sam.html)
- [Serverless Application Model Template Specification](https://github.com/awslabs/serverless-application-model/blob/master/versions/2016-10-31.md)

## Modules

The workshop is split across 6 modules over the course of the day. Each module will include a brief lecture, guided hands on activity, and challenges. At the start of a module copy the contents of the directory into your working repository as directed by the workshop leads.

All challenges revolve around modifying CloudFormation templates and resources - you are not required to know or write Python as a part of this workshop. If you do complete the challenges it is recommended you copy the files for the next module and overwrite your changes.

### Introduction and Setup (10:00 - 10:15 / 15 min)

Get setup and ready for the workshop.

### [Pipeline](1_Pipeline/) (10:15 - 11:00 / 45 min)

Create a pipeline for building and deploying the serverless application automatically on commits.

### [Base API](2_Base_API/) (11:00 - 11:45 / 45 min)

Update the template to create the base API Gateway and its Lambda functions.

### [Cognito](3_Cognito/) (11:45 - 12:00 / 15 min)

Secure access to the API Gateway using Cognito.

### Lunch (12:00 - 1:00)

### [Image Uploads](4_Image_Uploads/) (1:00 - 2:00 / 1 hr)

Update the API to accept image files and save them to a S3 bucket.

### [Image Processing](5_Image_Processing/) (2:00 - 3:00 / 1 hr)

Process uploaded images and record them to a DynamoDB table.

### [Monitoring](6_Monitoring/) (3:00 - 4:00 / 1 hr)

View metrics and set alerts using X-Ray and CloudWatch.

### Bonus Challenges

Use the remaining workshop time to ask questions and extend the service.

repository: brysontyrrell/SubZero-Workshop

gha_language: Python

repo_name: brysontyrrell/SubZero-Workshop


text:
# Docker Swarm

All Docker Swarm examples can be done using [Kubelab - Play With Docker](https://labs.play-with-docker.com/).

Follow instructions in [This guide](https://github.com/collabnix/dockerlabs/blob/master/intermediate/swarm/README.md) and choose 3 Managers and 2 Workers setup form instance templates.

repository: marekrein/dca-prep-kit

repo_name: marekrein/dca-prep-kit


text:
<h1 align="center" style="font-size:80px">
    Generation based Applications in NLP
</h1>

There are many generation based problems in NLP like language modelling, machine translation, text summarization, sequence to sequence problems like NER, POS tagging, Image Captioning, and many others. Here I will be exploring a few of the applications.

**Note: Please raise an issue for any suggestions, corrections, and feedback.**

# Language Modeling

What is a Language Model in NLP? Language modeling is central to many important natural language processing tasks. A language model learns to predict the probability of a sequence of words.

## Generating Names.ipynb

Given a starting character, generate a name starting with that character.

We’ll train LSTM character-level language models. That is, we’ll give the LSTM a huge chunk of names and ask it to model the probability distribution of the next character in the sequence given a sequence of previous characters. This will then allow us to generate new name one character at a time.

# Machine Translation

Machine Translation (MT) is the task of automatically converting one natural language into another, preserving the meaning of the input text, and producing fluent text in the output language. Ideally, a source language sequence is translated into target language sequence.

## Basic Machine Translation.ipynb

The most common sequence-to-sequence (seq2seq) models are encoder-decoder models, which commonly use a recurrent neural network (RNN) to encode the source (input) sentence into a single vector. In this notebook, we'll refer to this single vector as a context vector. We can think of the context vector as being an abstract representation of the entire input sentence. This vector is then decoded by a second RNN which learns to output the target (output) sentence by generating it one word at a time.

## Improved Machine Translation.ipynb

After trying the basic machine translation which has text perplexity `36.68`, following techniques have been experimented and a test perplexity `7.041`.

- GRU is used instead of LSTM
- Single layer
- Context vector is sent to decoder rnn along with decoder input embedding
- Context vector is sent to classifier along with the decoder hidden state

## Machine Translation with Bahdanau Attention.ipynb

The attention mechanism was born to help memorize long source sentences in neural machine translation (NMT). Rather than building a single context vector out of the encoder's last hidden state, attention is used to focus more on the relevant parts of the input while decoding a sentence. The context vector will be created by taking encoder outputs and the `previous hidden state` of the decoder rnn.

## Masking, Packing, Visualization, BLEU on MT.ipynb

Enhancements like masking (ignoring the attention over padded input), packing padded sequences (for better computation), attention visualization and BLEU metric on test data are implemented.

## Machine Translation with Transformer.ipynb

The Transformer, a model architecture eschewing recurrence and instead relying entirely on an attention mechanism to draw global dependencies between input and output is used to do Machine translation from German to English. A test perplexity of `5.677` was achieved with even lesser training time.


text:
# Accessing H2O Library #

Before you would want to access H2O you would need to make sure you have installed H2O properly. The link below will help you install in your desired environment:
 - [H2O Installation](https://github.com/Avkash/appliedml/blob/master/advance/h2o/h2o_install.md)

There are 2 key API to connect with H2O cluster from R or Python interface:
```
h2o.init()
h2o.connect()
```
Note:
  - If no IP address and PORT is give, default IP as localhost and defult port 54321 will be used.
  - You can use h2o.init() and h2o.connect() to connect any H2O instance started locally, Hadoop, YARN etc. API does not distinguish how H2O cluster was started.

### Difference between h2o.init() and h2o.connect() ###
 - ### h2o.init() ###
  - API will check first to see if H2O to running at default IP address and port
  - If H2O is running, then API will connect to running H2O instance
  - If H2O is not running, then API will try to start H2O on given IP address (Only apply to local IP Address/Localhost)
  - H2O cluser will not be started if startH2O parameter is set to FALSE (R)/ start = False/True for Python.
 - ### h2o.connect() ###
  - This option is use to connect with an H2O instance which is already running and available on an IP/PORT
  - You must provide IP and PORT with the parameter.

## Scala ##
You would be using Sparkling Water package with Spark to use with Scala. Once you have Sparkling Water prompt you can start the sparking shell as below:
```
 $ bin/sparklink-shell
```
Once sparkling shell is available from scala, you get the H2O context as below:
```
scala> import org.apache.spark.h2o._
import org.apache.spark.h2o._

scala> val hc = H2OContext.getOrCreate(spark)
......
......
Sparkling Water Context:
 * H2O name: sparkling-water-avkashchauhan_local-1509317501071
 * cluster size: 1
 * list of used nodes:
  (executorId, host, port)
  ------------------------
  (driver,<IP_ADDRESS>,54321)
  ------------------------

  Open H2O Flow in browser: http://<IP_ADDRESS>:54321 (CMD + click in Mac OSX)
```
After that you just connect to H2O from FLOW, R or Python, either way you want to.

## Accessing H2O EC2 Instance from your OSX/Windows Machine ##
- Setup H2O in EC2 instance. It can be a single machine running H2O or a cluster of machine running H2O cluster
- You need to make sure EC2 instance has security configuration opens IP address and port 54321/54323 (or other PORT configured to run H2O) so you can access from your windows or OSX machine
- At your OSX/Windows machine start R/Python
- Load H2O library
```
## R
library(h2o)
## Python
import h2o
```
- Initalize H2O
```
## R/python
h2o.init(ip="ip address of EC2 istance where H2O is running", port = PORT_VALUE)
```
- Validate the H2O cluster details
```
## R
h2o.clusterStatus()
## Python
h2o.cluster_status()
```

repository: Avkash/appliedml

repo_name: Avkash/appliedml


text:
# New York Times Article Search
A mini-project designed to create a readable New York Times Article Browser using jQuery, ajax, and the NYTimes API.

[Deployment](https://zekkxx.github.io/new-york-times-app/) || [Repository](https://github.com/zekkxx/new-york-times-app)

Designed by:
[Kieran Anthony](https://github.com/zekkxx),
[Mike Snyder](https://github.com/mikesnyder),
[Ivan Wijetunge](https://github.com/iwijetunge),
[Brian Lynn](https://github.com/Balynn077),
[Jeff Samuels](https://github.com/jeffsamuels)

## Technology:
Primary CSS Source from [Bootstrap](https://getbootstrap.com/). API from [The New York Times Developer Network](https://developer.nytimes.com/). This project utilizes jQuery and Ajax for requests. This project also stores information to localStorage on the browser.

<img src="assets/images/screenshot-main.png" height="300px">

## Utilization:

In order to use this project, you will need to have an API Key from the New York Times API. You can input this key using the button labeled as `Add API Key`. This will store the key to localMemory for future reference. You can check to see what API Key is currently applied by using the same button and reading the API Key that displays.

Searching works similarly to searching for results on google. Place a search term in the appropriate field, and then decide how many results max, up to 10, you want to recieve. You can choose to narrow your search results to a specific set of years using the `Start Year` and `End Year` fields. When you are ready, click on the `Search` button and the page will then inform you of your results and scroll down to highlight the articles found for you.

You can jump directly to the article on the New York Time's website by clicking on the title when the results are presented to you. Or you can continue to search according to the life of your API Key.

license: Unlicense

repository: zekkxx/new-york-times-app

repo_name: zekkxx/new-york-times-app


text:
---
layout: default
---

# 1996-12-03 - Dow-Jones Counsel Writes

## Header Data

From: John Young<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: c502de5055811f78427ac1c4520ed9155c8cb185dfc5fddf749e20e6bf2a2ba5

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1996-12-03 23:19:49 UTC

Raw Date: Tue, 3 Dec 1996 15:19:49 -0800 (PST)

## Raw message

```
{% raw  %}From: John Young<EMAIL_ADDRESS>Date: Tue, 3 Dec 1996 15:19:49 -0800 (PST)
To<EMAIL_ADDRESS>Subject: Dow-Jones Counsel Writes
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

---------

Date:    Mon, 2 Dec 1996 11:15:07 -0500
To<EMAIL_ADDRESS>From<EMAIL_ADDRESS>         (Legal Department - Dow Jones & Co. NYC)
Subject: Articles on Your Web Site

Hello.

I am an attorney with Dow Jones & Company, Inc.  I came
across your Web site recently and saw that you have
incorporated articles from The Wall Street Journal, which
is a publication of Dow Jones.  Dow Jones is pleased that
readers find information in The Wall Street Journal important
enough to communicate to other Web users.  The articles I've
seen are, or have been, located at

   http://jya.com/clash0.txt;
   http://jya.com/xpanix.txt;
   http://www.jya.com/peanut.txt;
   and http://www.jya.com/boomer.txt.

We also appreciate your encouraging others to take a look
at our articles.  The problem is that posting our copyrighted
material at your site violates copyright laws, even if you give
us credit, and even if you don't charge people to read the
posted material.  The same would be true if someone were to
republish material that you created without your permission.
You can, of course, recommend stories from The Wall Street
Journal at your site by citing the headline and the date of
the article and providing a brief description.  And those
articles can be viewed quite easily for a modest subscription
fee in The Wall Street Journal Interactive Edition, the Web
site of The Wall Street Journal (http://wsj.com).

While we hope you keep reading The Wall Street Journal, you
must remove our articles from any Web site you control as
soon as possible.

If you want to talk to me about this, you can reach me at
(212) 416-3108.

Many thanks.

Sincerely,

Hunter Farrell
Counsel
Dow Jones & Company, Inc.

---------

We thanked Mr. Farrell for his courteous note, promised
to keep WSJ articles off our site and read the paper.

{% endraw %}
```

## Thread

+ Return to [December 1996](/archive/1996/12)

+ Return to "[John Young <jya@pipeline.com>](/authors/john_young_jya_at_pipeline_com_)"

+ 1996-12-03 (Tue, 3 Dec 1996 15:19:49 -0800 (PST)) - Dow-Jones Counsel Writes - _John Young<EMAIL_ADDRESS>


text:
# API Guides

**Example (and primary use case)**:
[http://developer.radiumcrm.com](http://developer.radiumcrm.com)

`ApiGuides` is a simple static generator based off Docco. It is
specifically designed to handle writing documentation for HTTP APIs,
however it should be flexible enough to work in many other situations as
well. The generator will create HTML, CSS, an optional logo image inside
a directory. You can deploy the site using any web server or Heroku if
you like.

You should use this generator if you need want to create documenation
with these things in mind:

1. You want to write in Markdown.
2. You want syntax highlighting for a variety of langauges.
3. You want an automatic table of contents
4. You want an index of all the technical information
5. You want to provide examples of using your code in one or more
   different languages or frameworks.
6. You want to structure your documentation between different code
   repos or separate files.
7. You want to link to specific sections of documentation from within
   other sections of documentation.
8. You have **alot** of documentation to write. This generator all works
   well with small about of documentation as well.
9. You want something that looks pretty, is easy to read, and don't want
   to make any CSS decisions or worry presentational issues.

If you think most of those things sound good then read on.

## Structuring Documentation

Raw documenation is kept in XML files with content written in Markdown.
I've choosen XML because it is great at storing and organizing large
amounts of text. Don't worry, you won't have to mess with XML that much.

You can (and should) structure your documenation in separate files. You
can think of each file has a chapter in your documentation. You may have
one file that generally describes your program and a file for each
feature.

A document is composed of sections. A section is composed of textual
content written in markdown, a reference written in markdown, and zero,
one, or more examples written in markdown. Here is an example document.

```xml
<document>
  <title>introduction</title>
  <position>1</position>
  <section title="about">
    <docs>
      <![cdata[
      # write your markdown here
      ]>
    </docs>
    <reference title="about">
      <![cdata[
      # write some stuff describing your "about" interface
      ]]>
    </reference>
    <examples>
      <example language="ruby">
        <![cdata[
        # write some markdown for your ruby example
        ]]>
      </example>
      <example language="python">
        <![cdata[
        # write some markdown for your python example
        ]]>
      </example>
    </examples>
  </section>
</document>
```

There is a lot to take in from that example so let's break it down!

### The document Element

Is the root element and must contain a `title`, `position` and one or
more `sections`. A `<document>` signifys a new chapter of your
documentation. The `title` will be placed in a `h1` and subsequent
section titles will be placed in `<h2>`s. The `<position>` element
determines the order.

### The section Element

Sections are a way to group textual documentation, examples, and
technical documentation.
This will create a TOC entry under the parent `<document>`'s `<title>`.
You can omit `title` if you do not want a header or TOC entry generated.
You usually skip this for the first section since most of the time you
don't want a header right under another without any text in between. You
may include `<examples>` or `<reference>` if you wish, but you should
always include `<docs>`. The examples and reference material will always
be shown with the associated docs. You can omit `<docs>` but that
doesn't make any sense! Who's going to figure out what they're doing
without the docs.

### The reference Element

The Reference element contains technical documentation for the
associated docs. It may be a method signature or whatever you can think
of. The reference will always be shown with the associated docs and with
any examples. You may also give the `<reference>` a `title` attribute.
`<references>` with a `title` attribute will be included in the index.
You may omit the `title` if you do not want this to be indexed. You
should always include a reference!

### The example Element

Examples contain code for the language or framework specified in the
`language` attribute. An example will always be shown with the reference
and associated docs. You can `omit` the language if you want. If you do,
the example will be shown for **all** different languages.
You can write whatever you want for the content. It
can be text, lists, as well as code. The generator makes no assumption
about what will be in the example, just that it will be markdown. A
different version of the documentation will be generated for each
language specified in your documents.

### General Output

Your docs will always be show on the left. If a reference is present, it
will be shown exactly opposite of the docs. If examples are present,
they will be shown below the reference.

### Generating the Table of Contents

A TOC will be generated according to `<title>` elements inside the
`<document>` and `title` attributes on the `<section>` element. Here are
some example XML documents and generated table of contents.

```xml
<document>
  <title>Introduction</title>
  <position>1</position>
  <section>
    <docs>Foo</docs>
  </section>
  <section title="Overview">
    <docs>Bar</docs>
  </section>
  <section title="Response Codes">
    <docs>Bar</docs>
  </section>
</document>
```

```xml
<document>
  <title>Response Codes</title>
  <position>2</position>
  <section title="Success">
    <docs>Foo</docs>
  </section>
  <section title="Redirection">
    <docs>Bar</docs>
  </section>
  <section title="Failure">
    <docs>Bar</docs>
  </section>
</document>
```

1. Introduction
  1. Overview
  2. Reponse Codes
2. Rreponse Codes
  1. Success
  2. Redirection
  3. Failure

## Markdown

I love Markdown. It's mucher easy to read and write than textile.
[Redcarpet](https://github.com/tanoku/redcarpet) is used for parsing. It includes some more features like
fenced code blocks with language specification (yay!), tables, and a few
other tricks. You can read their documentation for the complete list of
available features. You may also include HTML inside the markdown,
however, you cannot use markdown inside the HTML. Common use case for
HTML is `<dl>`. Definition lists are part of PHP markdown extra and not
supported by Redcarpet.

[Pygments](http://pygments.org/) is used for syntax highlighting. The generator uses the
pygments webservice so you don't have to worry about installing anything
python related on your machine. It supports a very large variety of
different languages and the generator includes a theme to make all of
them look nice and pretty.

## Linking

You can also link to sections, documents, or references through out your
documentation. Each element will be given an ID which you can use to
create an anchor link for. They are prefaced with `d`, `s` or `r`
depending on what they are. This is to prevent duplication. The titles
are are dasherized aka permalinks. Here are some examples:

1. `<section title="Introduction and about">` -->
   "s-introduction-and-about"
2. `<reference title="Logging In">` --> "r-logging-in"
3. `<title>Messages: SMS, Email, & IM</title>` -->
   "d-messages-sms-email-im"

## Installation and Use

Firs thing you'll need to do is install ruby. I'm assuming you already
have this installed or know how to install for your operating system.
After that, you can simply install the gem.

```
gem install api_guides
```

The easiest way to generate the docs is from a rake task. Here is an
example. Assume your directory sturcture is like this:

```
|- source/
---------| guide1.xml
---------| guide2.xml
---------| guide3.xml
|- site/
|- Rakefile
```

Here is an example Rakefile:

```ruby
require 'bundler'
require 'api_guides'

task :generate do
  ApiGuides::Generator.new({
    :source_path => "#{File.dirname(__FILE__)}/source",
    :site_path => "#{File.dirname(__FILE__)}/site",
    :title => 'Cool API',
    :logo => "#{File.dirname(__FILE__)}/logo.png",
    :default => "ruby"
  }).generate
end

task :default => :generate
```

When ever you update your guides just run:

```bash
$ bundle exec rake
```

This will stick all the generated files into `site/`.
**Note**: Always deal with absolute paths for certanity.
**WARNING**: The contents of `site_path` will be deleted before
generation occurs. Don't put anything in there if you want to keep it.

### Options

The `ApiGuides::Generator` constructor takes a few options. Here are the
details.

* `:source_path`: Abosolute path to the directory containing all the XML
  documents.
* `:site_path`: Absolute path for the generated files
* `:title`: It goes in the navbar and the `<title>` in the finished HTML
* `:default`: Required if there are more than one lanauges. This sets
  the examples on the index page.
* `:logo`: _Optional_. Absolute path to an image to put in the navbar.

## Deploying

Since the generating documentation is just static HTML, CSS, and images
we can deploy to any web server very easily. This section shows you how
to write a simple [Rack](http://rack.rubyforge.org/) server so you can deploy it to Heroku.

First, create `config.ru` file in your directory. Here are the contents:

```ruby
require 'rack-rewrite'

use Rack::Rewrite do
  rewrite '/', '/index.html'
end

root = "#{Dir.pwd}/site"
run Rack::Directory.new("#{root}")
```

Make sure you update the `root =` line with whatever directory holds all
the files.

You can test it locally by running these commands:

```bash
$ gem install rack rack-rewrite
$ rackup -p 3000
```
Now open `http://localhost:3000` and you should see your documentation.

 CSS taken from source
  with some modifications.
* [Stripe](https://stripe.com/docs/api) - For inspiring more complex documentation and layout.
  Although, I think this came out better!
* [Rocco](https://github.com/rtomayko/rocco) - For demonstrating how to use Mustache
* [Twitter Boostrap](http://twitter.github.com/bootstrap) - For the navbar. I only took what I needed and
  repackaged them into the `#topbar` selector.

## Hacking

Feel free to hack on the code in your own fork. Send me a pull request
if you do cool stuff.

## Documentation

Documentation is written for Rocco. You can read the annotated source
[here](http://threadedlabs.github.com/api_guides).

## License

MIT.


text:
# Juniper

The juniper header designation has the following format:

```
target:: juniper [filter name] {inet|inet6|bridge}
filter name: defines the name of the juniper filter.
inet: specifies the output should be for IPv4 only filters. This is the default format.
inet6: specifies the output be for IPv6 only filters.
bridge: specifies the output should render a Juniper bridge filter.
```

When inet4 or inet6 is specified, naming tokens with both IPv4 and IPv6 filters
will be rendered using only the specified addresses.

The default format is `inet4`, and is implied if not other argument is given.

## Juniper
The juniper header designation has the following format:
```
target:: juniper [filter name] {inet|inet6|bridge} {dsmo} {not-interface-specific}
```
  * _filter name_: defines the name of the juniper filter.
  * _inet_: specifies the output should be for IPv4 only filters. This is the default format.
  * _inet6_: specifies the output be for IPv6 only filters.
  * _bridge_: specifies the output should render a Juniper bridge filter.
  * _dsmo_: Enable discontinuous subnet mask summarization.
  * _not-interface-specific_: Toggles "interface-specific" inside of a term.
  * _direction_: The direction of the filter on an interface (optional). Use when a term needs this signal.
  * _interface_: The type of interface on which the filter will be applied (optional). Use when a term needs this signal.
When _inet4_ or _inet6_ is specified, naming tokens with both IPv4 and IPv6 filters will be rendered using only the specified addresses.
The default format is _inet4_, and is implied if not other argument is given.
## Term Format
* _action::_ The action to take when matched. See Actions section for valid options.
* _address::_ One or more network address tokens, matches source or destination.
* _restrict-address-family::_ Only include the term in the matching address family filter (eg. for mixed filters).
* _comment::_ A text comment enclosed in double-quotes.  The comment can extend over multiple lines if desired, until a closing quote is encountered.
* _counter::_ Update a counter for matching packets
* _destination-address::_ One or more destination address tokens
* _destination-exclude::_ Exclude one or more address tokens from the specified destination-address
* _destination-port::_ One or more service definition tokens
* _destination-prefix::_ Specify destination-prefix matching (e.g. source-prefix:: configured-neighbors-only)
* _destination-prefix_except::_ Specify destination-prefix exception(TODO:cmas Fill in more).
* _dscp_except::_ Do not match the DSCP number.
* _dscp_match::_ Match a DSCP number.
* _dscp_set::_ Match a DSCP set.
* _ether_type::_ Match EtherType field.
* _expiration::_ stop rendering this term after specified date. [YYYY](YYYY.md)-[MM](MM.md)-[DD](DD.md)
* _filter-term::_ Include another filter
* _flexible-match-range Filter based on flexible match options.
* _forwarding-class::_ Specify the forwarding class to match.
* _forwarding-class_except::_ Do not match the specified forwarding classes.
* _fragement-offset::_ specify a fragment offset of a fragmented packet
* _hop-limit::_ Match the hop limit to the specified hop limit or set of hop limits.
* _icmp-code::_ Specifies the ICMP code to filter on.
* _icmp-type::_ Specify icmp-type code to match, see section [ICMP TYPES](PolicyFormat#ICMP_TYPES.md) for list of valid arguments
* _logging::_ Specify that this packet should be logged via syslog.
* _loss-priority::_ Specify loss priority.
* _name::_ Name of the term.
* _next-ip::_ Used in filter based forwarding.
* _option::_ See platforms supported Options section.
* _owner::_ Owner of the term, used for organizational purposes.
* _packet-length::_ specify packet length.
* _platform::_ one or more target platforms for which this term should ONLY be rendered.
*_platform-exclude:: one or more target platforms for which this term should NEVER be rendered.
* _policer::_ specify which policer to apply to matching packets.
* _port::_ Matches on source or destination ports. Takes a service token.
* _port-mirror::_ Sends copies of the packets to a remote port, boolean value is used to render this config.
* _precedence::_ specify precedence of range 0-7.  May be a single integer, or a space separated list.
* _protocol::_ the network protocols this term will match, such as tcp, udp, icmp, or a numeric value.
* _protocol\_except::_ allow all protocol "except" specified.
* _qos::_ apply quality of service classification to matching packets (e.g. qos:: af4)
* _routing-instance::_ specify routing instance for matching packets.
* _source-address::_ one or more source address tokens.
* _source-exclude::_ exclude one or more address tokens from the specified source-address.
* _source-port::_ one or more service definition tokens.
* _source-prefix::_ specify source-prefix matching (e.g. source-prefix:: configured-neighbors-only).
* _source-prefix-except::_ specify destination-prefix exception(TODO:cmas Fill in more).
* _traffic-class-count::_
* _traffic-type::_ specify traffic-type
* _ttl::_ Matches on TTL.
* _verbatim::_ this specifies that the text enclosed within quotes should be rendered into the output without interpretation or modification.  This is sometimes used as a temporary workaround while new required features are being added.
## Sub Tokens
### Actions
* _accept_
* _deny_
* _next_
* _reject_
* _reject-with-tcp-rst_
### Option
* _.*::_ wat
* _established::_ Only match established connections, implements tcp-established for tcp and sets destination port to 1024- 65535 for udp if destination port is not defined.
* _first-fragment::_ Only match on first fragment of a fragmented pakcet.
* _sample::_ Samples traffic for netflow.
* _tcp-established::_ Only match established tcp connections, based on statefull match or TCP flags. Not supported for other protocols.
* _tcp-initial::_ Only match initial packet for TCP protocol.

repository: google/capirca

repo_name: google/capirca


text:
# jupyter-notebook-quick-look

Preview jupyter notebooks in quick look.

## Installation

Build qlgenerator using Xcode and then move jupter-notebook-quick-look.qlgenerator to /Library/QuickLook __(Note: Make sure to move it to this system-wide folder NOT the user folder ~/Library/Quicklook ! )__.

## Dependencies

Python 3 with jupyter installed.

Check out also [Jupyter App](www.github.com/jendas1/jupyter-notebook-quicklook-plugin) for opening jupyter notebooks right from Finder!

repository: blomadam/jupyter-notebook-quick-look

repo_name: blomadam/jupyter-notebook-quick-look


text:
![Demo1](https://user-images.githubusercontent.com/1910783/39823101-d7e1fd22-53de-11e8-9bb2-b4db1ad04292.png)

---

**AVGPlus** is an cross-platform engine that aims to AVG/ADV, Galgame, Audiobooks, etc. It provides a way to quickly build games for Windows, Linux and macOS, completely in JavaScript. You will get many simple APIs to build power game that had better performance from the engine.

## Getting Started
`avg.renderer` dependent on `avg.engine`.

First of all, clone engine project:
```shell
git clone https://github.com/avg-plus/avg.engine
```

And make it to a local package for dependency with `npm`:
```shell
$ cd avg.engine
$ yarn install
$ yarn link
```

## Development
Get renderer source and run the following shell in `avg.renderer` folder:
```shell
git clone https://github.com/avg-plus/avg.renderer
cd avg.renderer
yarn install
yarn link "avg-engine"
yarn start
```

Open another terminal session to launch game window:
```shell
yarn electron:test
```

You will get the world.

## Features & Todo
- [x] Text & Characters
- [x] Input Handle & Variables
- [x] Backgrounds
- [x] Image Widgets & Text Widgets (Subtitle)
- [x] Sounds (BGM, BGS, SE, Voice)
- [x] Game Flow Control & Clock Handle
- [x] Scripting
- [x] Advanced Animations (In Progress)
- [x] Camera Effects & Particle Effects (In Progress)
- [ ] Plugins & Rendering Extensions
- [ ] Archive (In Progress)

## Known Bugs
- Please link `avg.engine` again when you add or remove NPM packages.

gha_language: JavaScript


text:
---
layout: post
title: My favorite tips for economics PhD students
date: 2020-07-18 14:00:00 +0000
description: Gold nuggets shared with me while meeting seminar speakers
tags: tips

---
I often meet with seminar speakers. At both PSE and Monash, I had the privilege of meeting amazing researchers, including faculty from MIT, Harvard, Stanford, Berkeley, etc.

The researchers were very kind to share tips with me and here are some "gold nuggets" I think all economics PhD students should know.

"Look towards local knowledge for inspiration. You know things about the world around you that nobody else knows."

"You need to be working on what will be in journals two years from now. Not what is currently in the literature."

"The academic job market is one unique chance where you can advertise your work. No other times do you have the same opportunity."

 If you write one page per day, that will be two new papers per year. If you don't do at least two new papers a year, you won't get tenure."

"Read outside of economics for inspiration. People don't do that enough."

"There are a lot of bullshitters out there, and simple rule to separate them is: _Can you publish?_"

"When you give an empirical seminar, your audience will remember one number. You need to decide what that number will be in advance. You give your motivation so that they will want that number, then you provide it, and your robustness is always relative to this number. Finally, your conclusion brings home the number."

"Does your research answer an interesting question, or are you _seeing what happens if_. Your research must be driven by something that is interesting for the world, not manipulating existing models."