text:
---
layout: default
title:  "Welcome to the OYMotion Community!"
---

---
## gForce Armband
gForce 100 Armband is a smart wearable [Human Interface Device][HID] for
[gesture recognition][GestureRecognition]. It recognizes gestures according
to the sEMG signals of human forearms, and as well as calculates orientation
data in quaternions or [Euler Angles][EulerAngles] from its built-in 6-axis
[IMU][IMU] and tri-axis [magnetometer][magnetometer].

### Documents
* [gForce 100 Manual][gForce100Manual] &
  [gForce 100 User Guide][gForce100UserGuide]

  The User Guide provides more detailed information than the Manual.

* [gForce 100 Embedded Suite User Guide][gForce100EmbeddedUserGuide]

  Provides guide of using gForce 100 in embedded devices such as robots and
  prosthetics.

* [gForce Data Protocol][gForceDataProtocol]

  The specification of gForce Data Protocol defines the details of gForce
  interacting with host computers of PC, AR and VR.

* [gForce EMG Raw Data][gForceEMGRawData]

  Provides more information about using EMG raw data.

### Open Source Software
* [gForce SDK for Arduino][gForceSDKArduino]

  The open source library with example code to illustrate how to connnect
  gForce to Arduino-alike devices.

* [gForce Data Protocol Sample][gForceDataProtocolSample]

  An open source simple example developed for Android to illustrate
  [gForce Data Protocol](doc/gForceDataProtocol).

* [gForce SDK][gForceSDK]

  The SDK for Windows and Android with Unity support.
  Internal testing, coming soon......

* [gForceApp][gForceApp]

  The **hub** application for other applications to interact with
  gForce. It also provides utilities for users setting, firmware upgrading and
  diagnosing gForce. Released APK is open for downloading.
  Internal testing, coming soon......

### Downloads
* [gForceApp for Android  gForceApp_v2.3.4-20171009.apk][gForceAPK]

    Pre-built releases of gForceApp for Android.

* [sEMG Raw Data Capture Utility][RawDataCaptureFor100]

    Only for gForce 100 with support for raw data capturing.

* [sEMG Raw Data Capture SDK][RawDataCaptureSDKFor100]

    Only for gForce 100 with support for raw data capturing.

### Examples
* [gForce Examples][gForceExample]

  The collection of gForce Armband application examples, like controlling a mechanical hand.

---
## gForce Neuron
### Documents
* [gForce Neuron User Guide](doc/gForceNeuronUserGuide)

### Open Source Software
* [sEMG Filters Library][EMGFilters]

  Provides some basic filter functions for sEMG digital signals.

[HID]: https://en.wikipedia.org/wiki/Human_interface_device
[GestureRecognition]: https://en.wikipedia.org/wiki/Gesture_recognition
[EulerAngles]: https://en.wikipedia.org/wiki/Euler_angles
[IMU]: https://en.wikipedia.org/wiki/Inertial_measurement_unit
[magnetometer]:https://en.wikipedia.org/wiki/Magnetometer
[gForceSDKArduino]: https://github.com/oymotion/gForceSDKArduino
[gForceDataProtocolSample]: https://github.com/oymotion/gForceDataProtocolSample
[EMGFilters]: https://github.com/oymotion/EMGFilters
[gForceSDK]: https://github.com/oymotion/gForceSDK
[gForceApp]: https://github.com/oymotion/gForceApp
[gForceAppForAndroid]: https://github.com/oymotion/gForceApp/releases
[gForceExample]: https://github.com/oymotion/gForceExample
[gForce100UserGuide]: ./gForce100/gForce100UserGuide.md
[gForce100EmbeddedUserGuide]: ./gForceEmbeddedSuit/gForce100EmbeddedSuiteUserGuide.md
[gForceEMGRawData]: ./gForceEMGRawData/gForceEMGRawData.md
[gForceAPK]: ./assets/downloads/gForceApp_v2.3.4-20171009.apk
[RawDataCaptureFor100]: ./assets/downloads/RawDataCapture.zip
[RawDataCaptureSDKFor100]:./assets/downloads/RawDataCaptureSDK.zip
[gForce100Manual]: ./assets/downloads/gForce100_manual_v1.1-eng.pdf
[gForceDataProtocol]: ./gForceDataProtocol/gForceDataProtocol.md

repository: zhoukaisspu/testing

repo_name: zhoukaisspu/testing


text:
# mypackage
---

This library is Python package that contain a function that returns the top number (top_n) of items in an array, in descending order.

## Building this package locally
----
python setup.py sdist

## Installing this package from Github
----
pip install git+https://github.com/bmqhamane/mypackage.git

### Updating this package from Github
----
pip install --upgrade git+https://github.com/bmqhamane/mypackage.git

License
MIT

license: MIT

repository: bmqhamane/mypackage

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: bmqhamane/mypackage


text:
# MKOAirdropActivityViewController
This is basically a **view hierarchy hack** of the UIActivityViewController to hide the sharing sections below the Airdrop field. With the introduction of sharing extensions in iOS8 it is currently not possible to hide those sections using the **excludedActivityTypes** property anymore.

I currently use it in a side project as an intermediate solution. It was tested with iOS9.

**Note:** This hack doesn't use any private API. But the view structure of UIActivityViewController might change with any future release, so it is **not recommended** to use this in production.

# Author
Mathias Köhnke [@mkoehnke](http://twitter.com/mkoehnke)

# License
MKOAirdropActivityViewController is available under the MIT license. See the LICENSE file for more info.

# Recent Changes
The release notes can be found [here](https://github.com/mkoehnke/MKOAirdropActivityViewController/releases).


text:
How to start and manage a JSON extension
----------------------------------------

Soon, we'll get a separate GitHub Organization. Pretend all this text refers to that organization.

Vote on the name by incrementing the tally!
- [ ] MolSciSchema
- [ ] MolecularScienceSchema

There will be a main repo `MolSciSchema-core` into which the core, approved, common, consensus schema goes.

To create an extension, create a new repo in this org, essentially registering your domain, eg.g. `MolSciSchema-nwchem`. Please be lowercase in your domain.

Within your repo, you have freedom of contents. Any keys you add should be prefixed and include a colon e.g., `nwchem:modes`. You have freedom of commit management. "Owners" of the repo will probably be you (and those with power to commit to the core schema repo). With respect to versioning, you are strongly encouraged to follow SchemaVer (remember viz and the like are depending on reading these).

As extension find common fields and utility and converge on a semi-proved structure for that utility, make a PR to the core schema repo. The PR is the time for community review. Some governance will merge PRs into core. Periodically, timed releases will be made aiming to follow SchemaVer.

Instance documents will contain a field for core version and an array with the version numbers for any used extensions. For instance a Psi4 output json doc will have 0.4.4 core ver and ['psi4': 2.2.2, 'avogadro': 1.1.1] where core contains basic molecule, psi4 extension contains molecule fragmentation, and vibrational modes are written out according to the avogadro extension. There will be a regularization of that version into a string (e.g., v0.4.4-psi4v2.2.2-avogadrov1.1.1).

Optional keys in JSON will be always allowed, but overlaps will be _effectively_ forbidden by requiring the namespace-colon for anything not in core.

Not strictly on the versioning topic but brought up
---------------------------------------------------

- Versioning of data absorbed by codes/schema (not strictly program) like basisset, element masses. Changes in basisset exchange lead to different results. Versioning will provide key information about changes. Use of CODATA fundamental constants, IUPAC Gold Book for naming conventions (including atom names for superheavies) and semantic meaning of terms (see their Gold Book).

- Adherence of codes, visualizers, etc. to schema: bronze, molden, silver, gold, platinum compliance levels that will change with core version

repository: mattwelborn/QCSchema

repo_name: mattwelborn/QCSchema


text:
# Crypto-Scrapers

This C++ program is intended to be a small guide or example to build a simple scrapers manager using cURL to make requests. If you are looking for a simple C++ example, threads and requests then you are in the right place.

You will find 2 basic entities and some utilities which are described below.

## Main entities

### Scraper class

This is the base entity of this program. A `Scraper` creates a thread as soon as it is built, and such thread will execute a `request` using a given requester method with some given `frequency`.

Everytime a request is made its response (the value of a cryptocurrency i.e.) will be sent to the given `callback` method. The scrapers can be stopped calling `stop()`.

### ScrapersManager class

The main entity is `ScrapersManager`, an instance of this class will control scrapers which are added using `addScraper()` and at the end of the execution you should always call `stopAll()`.

## Utilities

### Aliases

Scrapers expect a callback and a requester method, which should have the following "type":

```cpp
using Callback = function<void(const string&, const float)>;
using ValueRequester = function<float()>;
```

### SimpleRequest class

This is a simplified method to make GET requests using cURL, just pass the URL and a `string` which will be used as a buffer to save the response.

## Example

In main.cpp you will find an example for scraping `coinmarketcap.com` using the `SimpleRequester` and looking for the prices of Bitcoin, Ethereum y Tether with a `Scraper` for each one of them.

Output:
```
Welcome! You will see the value of some cryptocurrencies each 5 seconds.

* Press ENTER to stop the scrapers *

BTC: 10890.8
ETH: 315.53
Tether: 1
```

The prices will be printed each 5 seconds, but every scraper will request/update its value with the specified frequencies.

### Running the example

You will find a Makefile so just use `make run`.

That's it, give it a look :D

repository: helderthh/cpp-scrapers-manager

repo_name: helderthh/cpp-scrapers-manager


text:
# Introduction

pyTMHMM is a Python 3.5+ implementation of the transmembrane helix predictor using a
hidden Markov model ([TMHMM](http://www.cbs.dtu.dk/services/TMHMM/)) originally
described in:

E.L. Sonnhammer, G. von Heijne, and A. Krogh. **A hidden Markov model for
predicting transmembrane helices in protein sequences**. In J. Glasgow,
T. Littlejohn, F. Major, R. Lathrop, D. Sankoff, and C. Sensen, editors,
Proceedings of the Sixth International Conference on Intelligent Systems for
Molecular Biology, pages 175-182, Menlo Park, CA, 1998. AAAI Press. PMID [9783223](https://pubmed.ncbi.nlm.nih.gov/9783223/)

# Why?

[Dan Søndergaard](https://github.com/dansondergaard) is the original author of this
package and his repository is now [archived](https://github.com/dansondergaard/tmhmm.py). Dan wrote this code for a few reasons:

- the source code is not available as part of the publication
- the downloadable binaries are Linux-only
- the downloadable binaries may not be redistributed, so it's not possible to
  put them in a Docker image or a VM for other people to use
- the need to predict transmembrane helices on a large dataset, which rules
  out the Web service

This Python implementation includes a parser for the undocumented file format
used to describe the model and a fast Cython implementation of the
Viterbi algorithm used to perform the annotation. The tool will output files
similar to the files produced by the original TMHMM implementation.

# Incompatibilities

* The original TMHMM implementation handles ambigious characters and gaps in an
  undocumented way. However, `pyTMHMM` does not attempt to handle such
  characters at all and will fail. A possible fix is to replace those
  characters with something also based on expert/domain knowledge.

# Installation

This package supports Python 3.5 or greater. Install with:

    $ pip install pyTMHMM

# Usage

    $ pyTMHMM -h
      usage: pyTMHMM [-h] -f SEQUENCE_FILE [-m MODEL_FILE] [-p]

      optional arguments:
        -h, --help            show this help message and exit
        -f SEQUENCE_FILE, --file SEQUENCE_FILE
                              path to file in fasta format with sequences
        -m MODEL_FILE, --model MODEL_FILE
                              path to the model to use
        -p, --plot            plot posterior probabilies

The `-p`/`--plot` option will only be available if `matplotlib` is installed
and importable.

Say we have the following sequence in FASTA format in a file called `test.fa`:

    >B9DFX7|1B|HMA8_ARATH Copper-transporting ATPase PAA2, chloroplastic  [Arabidopsis thaliana ]
    MASNLLRFPLPPPSSLHIRPSKFLVNRCFPRLRRSRIRRHCSRPFFLVSNSVEISTQSFESTESSIESVKSITSDTPIL
    LDVSGMMCGGCVARVKSVLMSDDRVASAVVNMLTETAAVKFKPEVEVTADTAESLAKRLTESGFEAKRRVSGMGVAENV
    KKWKEMVSKKEDLLVKSRNRVAFAWTLVALCCGSHTSHILHSLGIHIAHGGIWDLLHNSYVKGGLAVGALLGPGRELLF
    DGIKAFGKRSPNMNSLVGLGSMAAFSISLISLVNPELEWDASFFDEPVMLLGFVLLGRSLEERAKLQASTDMNELLSLI
    STQSRLVITSSDNNTPVDSVLSSDSICINVSVDDIRVGDSLLVLPGETFPVDGSVLAGRSVVDESMLTGESLPVFKEEG
    CSVSAGTINWDGPLRIKASSTGSNSTISKIVRMVEDAQGNAAPVQRLADAIAGPFVYTIMSLSAMTFAFWYYVGSHIFP
    DVLLNDIAGPDGDALALSLKLAVDVLVVSCPCALGLATPTAILIGTSLGAKRGYLIRGGDVLERLASIDCVALDKTGTL
    TEGRPVVSGVASLGYEEQEVLKMAAAVEKTATHPIAKAIVNEAESLNLKTPETRGQLTEPGFGTLAEIDGRFVAVGSLE
    WVSDRFLKKNDSSDMVKLESLLDHKLSNTSSTSRYSKTVVYVGREGEGIIGAIAISDCLRQDAEFTVARLQEKGIKTVL
    LSGDREGAVATVAKNVGIKSESTNYSLSPEKKFEFISNLQSSGHRVAMVGDGINDAPSLAQADVGIALKIEAQENAASN
    AASVILVRNKLSHVVDALSLAQATMSKVYQNLAWAIAYNVISIPIAAGVLLPQYDFAMTPSLSGGLMALSSIFVVSNSL
    LLQLHKSETSKNSL

We can then run `pyTMHMM` on this file using the following command:

    $ pyTMHMM -f test.fa

This produces three files. One is the summary:

    $ cat B9DFX7|1B|HMA8_ARATH.summary
    0-444: outside
    445-467: transmembrane helix
    468-820: inside
    821-843: transmembrane helix
    844-852: outside
    853-870: transmembrane helix
    871-882: inside

An annotation in FASTA format:

    $ cat B9DFX7|1B|HMA8_ARATH.annotation
    >B9DFX7|1B|HMA8_ARATH Copper-transporting ATPase PAA2, chloroplastic  [Arabidopsis thaliana ]
    OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
    OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
    OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
    OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
    OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
    OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOMMMMMMMMMMMMMMMMMMMMMMMiiiiii
    iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
    iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
    iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
    iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
    iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiMMMMMMMMMMMMMMMMMMMMMMMoooooooooMMMMMMMMMMMMMMMM
    MMiiiiiiiiiiii

And finally a file containing the posterior probabilities for each label for
plotting.

    $ cat B9DFX7|1B|HMA8_ARATH.plot
    inside membrane outside
    0.20341044516 0.0 0.79658955484
    0.210104176071 2.77194446172e-08 0.78989579621
    0.189291062167 3.11365191554e-08 0.810708906697
    0.253334801857 7.17866017044e-07 0.746664480277
    0.126185012808 1.34197873962e-05 0.873801567405
    ...

If the `-p` flag is set a plot in PDF format will also be produced, following
the same naming scheme as the other output files.

# API

You can also use `pyTMHMM` as a library:

    import pyTMHMM
    annotation, posterior = pyTMHMM.predict(sequence_string)

This returns the annotation as a string and the posterior probabilities for
each label as a numpy array with shape `(len(sequence), 3)` where column 0, 1
and 2 corresponds to being inside, transmembrane and outside, respectively.

If you don't need the posterior probabilities set `compute_posterior=False`,
this will save computation:

    annotation = pyTMHMM.predict(
        sequence_string, compute_posterior=False
    )

repository: bosborne/pyTMHMM

branch_name: refs/heads/main

repo_name: bosborne/pyTMHMM


text:
# Provisioning webserver

In this guide we'll explain how to use the included provisioning script to install a Pipit generated application on a server.

## Requirements (webserver, aka ansible host)

The server should have these applications/packages installed:
- Linux (Ubuntu 20.04+ is preffered)
- Nginx
- uWSGI
- Python 3.8+
- PostgreSQL 12+
- PostGIS for PostgreSQL
- GDAL (required for PostGIS)
- Node 12+
- [PM2](https://pm2.io/)
- [psycopg2-binary](https://pypi.org/project/psycopg2-binary/) (this is required for the provision script that will create db and users)

Linux should have these users (with passwordless login using RSA keys):
- "root" - Used when provisioning web server
- "deploy" - Used for deployment

Configuration:
- Systemd jobs for Nginx, uWSGI and pm2
- Nginx configuration are stored at `/mnt/persist/nginx/conf.d/*`
- Node configuration are stored at `/mnt/persist/nodejs/*`
- Your web applications are stored at `/mnt/persist/www/*`
- The root user can access the psql shell without password

## Requirements (your computer, aka control node)

- A fully generated Pipit project
- Rsync installed
- A MacOS or Linux computer ([Ansible does not support Windows](http://blog.rolpdog.com/2020/03/why-no-ansible-controller-for-windows.html))
- Access to the webserver over ssh with both the "root" and "deploy" user

## Guide

- Begin by going to the deploy dir in your project and install [Ansible](https://www.ansible.com/)
    ```
    >>> cd deploy
    >>> python3 -m venv venv
    >>> . venv/bin/activate
    >>> pip install -r requirements.txt
    ```

- Make sure you can connect to the server by pinging it
    ```
    >>> ansible -i stages/stage.yml webservers -m ping
    stage1 | SUCCESS => {
        "ansible_facts": {
            "discovered_interpreter_python": "/usr/bin/python3"
        },
        "changed": false,
        "ping": "pong"
    }
    ```

- After this, we install [Ansistrano](https://ansistrano.com/):
    ```
    >>> ansible-galaxy install -r requirements.yml
    ```
- Now that we have everything installed, lets run the provisioning:
- For stage
    ```
    >>> ansible-playbook provision.yml -i stages/stage.yml
    ```
- For prod
    ```
    >>> ansible-playbook provision.yml -i stages/prod.yml
    ```
- This will script will run the necessary steps to make sure your application is ready to be deployed
- The next step is to run a deploy to sent our application to the server and start it
- For stage
    ```
    >>> ansible-playbook deploy.yml -i stages/stage.yml
    ```
- For prod
    ```
    >>> ansible-playbook deploy.yml -i stages/prod.yml
    ```
- Done!

## Note
- This script does not perform server provisioning, only application provisioning. But there are plenty of [guides on how to do this](https://clouding.io/hc/en-us/articles/360013788600-How-to-provision-Ubuntu-server-with-Ansible-scripts).

repository: marqpdx/Wagtail-Pipit

gha_language: Python

gha_license_id: MIT

repo_name: marqpdx/Wagtail-Pipit


text:
# Nota - The Note Taking App [Beta-1]

Nota is a simple and clean note taking app which gives you materially designed minimal note taking experience which helps you to stay focused.

---
## Features

Nota is minimal but is feature packed
1. Search your notes.
2. Sort your notes in three different manner.
    1. Alphabetically
    2. Last Edited
    3. Recently Drafted
3. Delete Note
4. Note Space:
Keeps all your notes at one place,  makes it available right when you need them.
5. Saves Notes on your Local Machine
6. 100% Secure - Your thoughts truely yours (No Cloud Connectivity)

& many more on it's way.

---

## Screen Shots [Web]
UI will be improved.
#### Home Screen:
![Image of Nota Home](https://github.com/cmulay/Notes-App/blob/master/assets/images/web_home.png)
#### Note Window:
![Image of Nota Home](https://github.com/cmulay/Notes-App/blob/master/assets/images/web_note.png)

## Screen Shots [Mobile]
User navigation bar coming soon and much more..
#### Home Screen:
![Image of Nota Home](https://github.com/cmulay/Notes-App/blob/master/assets/images/mob_home.png)
#### Note Window:
![Image of Nota Home](https://github.com/cmulay/Notes-App/blob/master/assets/images/mob_note.png)

## Third Party Libraries
[UUID](https://www.npmjs.com/package/uuid): To give each note a unique Note ID.

---
## License
This project is licensed under [MIT](https://github.com/cmulay/Notes-App/blob/master/LICENSE) license.

repository: cmulay/Notes-App

repo_name: cmulay/Notes-App


text:
# Node.js for Oracle NoSQL Database

## Overview

This is version 5.2 of the Node.js SDK for
the [Oracle NoSQL Database](https://www.oracle.com/database/technologies/related/nosql.html).
The SDK provides interfaces, documentation, and examples to develop Node.js
applications that use the
[Oracle NoSQL Database Cloud Service](https://cloud.oracle.com/nosqldatabase)
and the [On-Premise Oracle NoSQL Database](https://docs.oracle.com/en/database/other-databases/nosql-database/index.html).

## Prerequisites

* [Node.js](https://nodejs.org) 12.0.0 or higher, running on Linux, Windows or
Mac.
* [Node Package Manager (npm)](https://www.npmjs.com/get-npm) that is
installed with Node.js
* For use with the Oracle NoSQL Database Cloud Service:
  * An Oracle Cloud Infrastructure account
  * A user created in that account, in a group with a policy that grants the
  desired permissions.
* For use with the Oracle NoSQL Database On Premise:
  * [Oracle NoSQL Database](https://www.oracle.com/database/technologies/related/nosql.html).
See [Oracle NoSQL Database Downloads](https://www.oracle.com/database/technologies/nosql-database-server-downloads.html) to download Oracle NoSQL Database.  See
[Oracle NoSQL Database Documentation](https://docs.oracle.com/en/database/other-databases/nosql-database/index.html) to get started with Oracle NoSQL Database.
In particular, see the [Administrator Guide](https://docs.oracle.com/en/database/other-databases/nosql-database/20.3/admin/index.html) on how to install, configure and run Oracle
NoSQL Database Service.

## Installation

You may install this SDK either as a dependency of your project:

```bash
npm install oracle-nosqldb --save
```
or globally:

```bash
sudo npm install -g oracle-nosqldb
```

## Documentation

See the [API and user guide documentation](https://oracle.github.io/nosql-node-sdk/).

##Help

* Open an issue in the [Issues](https://github.com/oracle/nosql-node-sdk/issues) page.
* [Email to nosql\_sdk\_help\_grp<EMAIL_ADDRESS>* [Oracle NoSQL Developer Forum](https://community.oracle.com/community/groundbreakers/database/nosql_database)

When requesting help please be sure to include as much detail as possible,
including version of the SDK and **simple**, standalone example code as needed.

## Quickstart

For detailed information and API documentation about using the SDK in different
environments see the [documentation](https://oracle.github.io/nosql-node-sdk/)

The following is a quick start tutorial to run a simple program in the supported
environments. The same template source code is used for all environments. The
first step is to cut the program below and paste it into an editor for minor
modifications. The instructions assume that is stored as quickstart.js, but you
can use any name you like. The quickstart example supports 3 environments:
1. Oracle NoSQL Database Cloud Service
2. Oracle NoSQL  Cloud Simulator
3. Oracle NoSQL  Database on-premise, using the proxy server

See [running quickstart](#run_quickstart) for instructions on how to edit and
run the quickstart program in different environments.

```js
/*
 * A simple example that
 *   - creates a table
 *   - inserts a row using the put() operation
 *   - reads a row using the get() operation
 *   - drops the table
 *
 * To run:
 *  1. Edit for your target environment and credentials
 *  2. Run it:
 *       node quickstart.js cloud|cloudsim|kvstore
 *
 *  Use 'cloud' for the Oracle NoSQL Database Cloud Service
 *  Use 'cloudsim' for the Oracle NoSQL Cloud Simulator
 *  Use 'kvstore' for the Oracle NoSQL Database on-premise
 */
'use strict';

const NoSQLClient = require('oracle-nosqldb').NoSQLClient;
const Region = require('oracle-nosqldb').Region;
const ServiceType = require('oracle-nosqldb').ServiceType;

// Target table used by this example
const TABLE_NAME = 'NodeQuickstart';
const USAGE = 'Usage: node quickstart.js cloud|cloudsim|kvstore';

async function quickstart() {
    let client;
    try {
        const args = process.argv;
        let serviceType = args[2];
        if (!serviceType) {
            return console.error(USAGE);
        }
        // Set up access to the cloud service
        client = createClient(serviceType);
        console.log('Created NoSQLClient instance');
        await run(client);
        console.log('Success!');
    } catch (err) {
        console.error('  Error: ' + err.message);
        console.error('  from: ');
        console.error(err.operation.api.name);
    } finally {
        if (client) {
            client.close();
        }
    }
}

/*
 * This function encapsulates environmental differences and returns a
 * client handle to use for data operations.
 */
function createClient(serviceType) {

    switch(serviceType) {
    case 'cloud':
        return new NoSQLClient({
            /*
             * EDIT:
             * 1. use desired region id
             * 2. your tenancy's OCID, user's OCID
             * 3. privateKeyFile path
             * 4. fingerprint for uploaded public key
             * 5. optional passphrase. If your key has none, delete this
             * line (and the leading ',').
             */
            region: Region.<your-region-here>,
            auth: {
                iam: {
                    tenantId: 'your tenancy OCID',
                    userId: 'your user OCID',
                    fingerprint: 'your public key fingerprint',
                    privateKeyFile: 'path to private key file or private key',
                    passphrase: 'pass phrase if set for your private key'
                }
            }
        });
    case 'cloudsim':
        /*
         * EDIT: if the endpoint does not reflect how the Cloud
         * Simulator has been started, modify it accordingly.
         */
        return new NoSQLClient({
            serviceType: ServiceType.CLOUDSIM,
            endpoint: 'localhost:8080'
        });
    case 'kvstore':
        /*
         * EDIT: if the endpoint does not reflect how the Proxy
         * Server has been started, modify it accordingly.
         */
        return new NoSQLClient({
            serviceType: ServiceType.KVSTORE,
            endpoint: 'localhost:80'
        });
    default:
        throw new Error('Unknown service type: ' + serviceType);
    }
}

/*
 * Create a table, read and write a record
 */
async function run(client) {
    const createDDL = `CREATE TABLE IF NOT EXISTS ${TABLE_NAME} \
(cookie_id LONG, audience_data JSON, PRIMARY KEY(cookie_id))`;
    console.log('Create table ' + TABLE_NAME);
    let res = await client.tableDDL(createDDL, {
        tableLimits: {
            readUnits: 1,
            writeUnits: 5,
            storageGB: 1
        }
    });
    console.log('  Creating table %s', res.tableName);
    console.log('  Table state: %s', res.tableState.name);

    // Wait for the operation completion
    await client.forCompletion(res);
    console.log('  Table %s is created', res.tableName);
    console.log('  Table state: %s', res.tableState.name);

    // Write a record
    console.log('\nWrite a record');
    res = await client.put(TABLE_NAME, {
        cookie_id: 456,
        audience_data: {
            ipaddr: '10.0.00.yyy',
            audience_segment: {
                sports_lover: '2019-01-05',
                foodie: '2018-12-31'
            }
        }
    });
    if (res.consumedCapacity) {
        console.log('  Write used: %O', res.consumedCapacity);
    }

    // Read a record
    console.log('\nRead a record');
    res = await client.get(TABLE_NAME, { cookie_id: 456 });
    console.log('  Got record: %O', res.row);
    if (res.consumedCapacity) {
        console.log('  Read used: %O', res.consumedCapacity);
    }

    // Drop the table
    console.log('\nDrop table');
    const dropDDL = `DROP TABLE ${TABLE_NAME}`;
    res = await client.tableDDL(dropDDL);
    console.log('  Dropping table %s', res.tableName);

    // Wait for the table to be removed
    await client.forCompletion(res);
    console.log('  Operation completed');
    console.log('  Table state is %s', res.tableState.name);
}

quickstart();
```

###  Running Quickstart

#### Run Against the Oracle NoSQL Database Cloud Service

Running against the Cloud Service requires an Oracle Cloud account. See
[Configuring for the Cloud Service](https://oracle.github.io/nosql-node-sdk/tutorial-connect-cloud.html#configure_cloud) for information on getting an account and
acquiring required credentials.

1. Collect the following information:

* Tenancy ID
* User ID
* API signing key (private key file in PEM format
* Fingerprint for the public key uploaded to the user's account
* Private key pass phrase, needed only if the private key is encrypted

2. Edit *quickstart.js*  and add your information in the 'cloud' section of the
*createClient()* function.

3. Decide the region you want to use and add that in the same section in the
value for the *region* key.

4. Run the program:

```js
node quickstart.js cloud
```
If you would prefer to create a configuration file for credentials instead of
modifying the program put credentials in a file (see
[Using a Configuration File](https://oracle.github.io/nosql-node-sdk/tutorial-connect-cloud.html#config_file)). Then modify quickstart.js to use the file:

Replace

```ini
iam: {
    tenantId: 'your tenancy OCID',
    userId: 'your user OCID',
    fingerprint: 'your public key fingerprint',
    privateKeyFile: 'path to private key file or private key',
    passphrase: 'pass phrase if set for your private key'
}
```
with

```
iam: {
    configFile: 'path-to-config-file',
    profileName: 'DEFAULT'
}
```

#### Run Against the Oracle NoSQL Cloud Simulator

Running against the Oracle NoSQL Cloud Simulator requires a running Cloud
Simulator instance. See [Using the Cloud Simulator](https://oracle.github.io/nosql-node-sdk/tutorial-connect-cloud.html#cloudsim) for information on how to download
and start the Cloud Simulator.

1. Start the Cloud Simulator based on instructions above. Note the HTTP port
used. By default it is *8080* on *localhost*.

2. The *quickstart.js* program defaults to *localhost:8080* so if the Cloud
Simulator was started using default values no editing is required.

3. Run the program:

```js
node quickstart.js cloudsim
```

#### Run Against Oracle NoSQL on-premise

Running against the Oracle NoSQL Database on-premise requires a running
Oracle NoSQL Database instance as well as a running NoSQL Proxy server instance.
The program will connect to the proxy server.

See [Connecting to an On-Premise Oracle NoSQL Database](https://oracle.github.io/nosql-node-sdk/tutorial-connect-on-prem.html) for information on how to download
and start the database instance and proxy server. The database and proxy should
be started without security enabled for this quickstart program to operate
correctly. A secure configuration requires a secure proxy and more complex
configuration.

1. Start the Oracle NoSQL Database and proxy server  based on instructions above.
Note the HTTP port used. By default the endpoint is *localhost:80*.

2. The *quickstart.js* program defaults to *localhost:80*. If the proxy was started
using a different host or port edit the settings accordingly.

3. Run the program:

```js
node quickstart.js kvstore
```
## Examples

There are examples in the *examples* directory of the repository and in the
installed module. You can copy the *examples* directory (or files within it)
into a separate location. If you installed the SDK locally (as dependency of
your project), copy the examples into a location within your project so that
they can locate the SDK package (which should be installed in the
*node_modules* directory).  See
[Loading from node_modules Folders](https://nodejs.org/dist/latest-v12.x/docs/api/modules.html#modules_loading_from_node_modules_folders).
If you installed the SDK globally, you may copy the examples to the location
of your choice.

You can run the examples

* Against the Oracle NoSQL Database Cloud Service using your Oracle Cloud
account and credentials.
* Locally using the [Oracle NoSQL Database Cloud Simulator](https://docs.oracle.com/en/cloud/paas/nosql-cloud/csnsd/develop-oracle-nosql-cloud-simulator.html).
* Against the On-Premise Oracle NoSQL Database via the proxy.

These configuration files are provided in the examples directory:

* **cloud\_template.json** is used to access a cloud service instance and
allows you to customize configuration. See
[Supply Credentials to the Application](https://oracle.github.io/nosql-node-sdk/tutorial-connect-cloud.html#supply). Unused properties must be removed from
the template.
* **cloudsim.json** is used if you are running against the cloud simulator.
You may use this file directly as config file if you are running the cloud
simulator on localhost on port 8080. If the cloud simulator has been started on
a different host or port, change the endpoint.
* **kvstore_template.json** is used to access on-premise NoSQL Database via
the proxy.  Copy that file and fill in appropriate values as described in
[Configuring the SDK](https://oracle.github.io/nosql-node-sdk/tutorial-connect-on-prem.html#config).
If configuring for a not secure store the *auth* section should be removed.

Run an example by pointing to the config file. This command assumes
*my_config.json* is a copy of a config file template modified for your
environment:

`node basic_example.js my_config.json`

Alternatively, when using cloud service with default configuration as
described in
[Configuring the SDK](https://oracle.github.io/nosql-node-sdk/tutorial-connect-cloud.html#configure_cloud), you may run the example without providing JSON config
file.  This assumes that your credentials and your region identifier are
present in a file, *~/.oci/config*:

`node basic_example.js`

## License

Please see the [LICENSE](LICENSE.txt) file included in the top-level directory of the
package for a copy of the license and additional information.

The [THIRD\_PARTY\_LICENSES](THIRD_PARTY_LICENSES.txt) file contains third
party notices and licenses.

## Contributing
See [CONTRIBUTING](./CONTRIBUTING.md) for details.

## Security
See [SECURITY](./SECURITY.md) for details.


text:
# Overview

This tutorial covers the basic steps of deploying a Python application onto a public server using `uWSGI` and `nginx`. We will be using a sample project, a Flask REST API, for demonstration, however, the deployment process should remain similar for any other Python applications. Our sample project can be found here: [https://github.com/schoolofcode-me/stores-rest-api](https://github.com/schoolofcode-me/stores-rest-api).

In this tutorial, we will not cover how to set up a server on any hosting platforms, however, if you are looking for such a tutorial, you may take a look at this one: [DigitalOcean Tutorial](DigitalOcean%20Tutorial.md), in which you will learn the basics on setting up a server from the beginning on a cloud hosting platform called `DigitalOcean`. The procedure should be similar for setting up server on other platforms as well, such as `AWS` (Amazon Web Service).

# Quick links
In this tutorial, we will assume you have a server set up already, and we will introduce the deployment process in the following order:

- [Connecting to the server using `SSH`](How%20To%20Deploy%20Python%20App%20Using%20uWSGI%20And%20Nginx.md#connecting-to-our-server).
- [Creating and configuring a `UNIX` user](How%20To%20Deploy%20Python%20App%20Using%20uWSGI%20And%20Nginx.md#creating-another-user).
- [Setting up `PostgreSQL` database](How%20To%20Deploy%20Python%20App%20Using%20uWSGI%20And%20Nginx.md#configuring-postgres).
- [Getting project code from `GitHub`](How%20To%20Deploy%20Python%20App%20Using%20uWSGI%20And%20Nginx.md#getting-code-from-github).
- [Configuring `uWSGI` for our project](How%20To%20Deploy%20Python%20App%20Using%20uWSGI%20And%20Nginx.md#uwsgi).
- [Configuring `nginx` for our project](How%20To%20Deploy%20Python%20App%20Using%20uWSGI%20And%20Nginx.md#nginx).

If you are a first time learner, we highly recommend you to follow through the whole tutorial so that you can get familiar with it and may be less likely to run into error. However, if you are only looking for information on a specific subject, please feel free to use the above links to navigate to according sections.

# Connecting to our server

In order to connect to our server, we need to use a tool called `SSH` (Secure Shell). We can SSH our server using the command:

```
ssh root@<your server ip>
```

You will be asked for the root password (or the SSH key if you have set it up previously). Beware that `SSH` command only works on `UNIX`, not on `Windows`. However, there are plenty of software that you can use to SSH from Windows, [PuTTy](http://www.putty.org/) is a popular choice:

After connecting to our server and logging in as the `root` user, it is recommended to run the below command first to get all the available updates:

```
apt-get update
```

We can use the following command to install packages:

```
apt-get install <package1> <package2>
```

Note that this is a just an example to install different packages using one command, we will see real use cases in the following sections.

# Creating another user

Since the `root` user is the most powerful, essentially a root user can do everything on the server, so we may want to limit access to it to improve security. So in this section, we will create a new user and configure it to "act like" a `root` user but with certain limitations, and we will login as this user from then on. It is highly recommended to do so, but if you choose not to follow this practice and simply want to login as the `root` user anyway, you may click [here to skip to the next section](How%20To%20Deploy%20Python%20App%20Using%20uWSGI%20And%20Nginx.md#configuring-postgres).

## Hello John Doe

In this section, we will create a user named `johndoe`. You may choose any name you want, just remember to swap `johndoe` with your username for each command and configuration. We can create a new user `johndoe` with the following command:

```
adduser johndoe
```

You will be asked to enter and confirm the password for this user, and then provide some info about this user. Notice that you can leave the info sections blank if you want to. And if you entered unmatching passwords, just complete the info section and we can change the password later by using the command:

```
passwd johndoe
```

## Providing user with additional privilege

Since we will be logging in as `johndoe` for most of the time in the future, we will want it to have some "extra power", that is, temporarily acting as a super user. To do this, we need to run the command:

```
visudo
```

first, and we will see a text file popping up. Then we navigate to the lines containing:

```
# User privilege specification
root ALL=(ALL:ALL) ALL
```

You can do this with the arrow keys. We need to add a new line for our user in this section:

```
# User privilege specification
root ALL=(ALL:ALL) ALL
johndoe ALL=(ALL:ALL) ALL
```

Remember that the `ALL` has to be **all uppercase**, otherwise it will raise syntax error.

After adding this line, use `ctrl + o` to save and press `ENTER` to overwrite, then press `ctrl + x` to quit.

## Enable SSH for our new user

Next, we want to allow us to login as `johndoe` using SSH, and we may also want to disable login as `root` from SSH to make our server more secure. To do this, use the command:

```
vi /etc/ssh/sshd_config
```

And we will be prompted with another text file. Navigate to the section which contains:

```
# Authentication
PermitRootLogin yes
```

Press `i` on your keyboard to enter insert mode and change the `yes` to `no` to disallow login as root.

Next, look for a configuration called `PasswordAuthentication`:

```
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes
```

 **Important:** make sure to set it as `yes` so that you can use your password to login in the future. It should be set to `yes` already, however, there are some platforms that enforces SSH key authentication and set it to `no` instead.

Then go to the bottom of the file and add the following lines:

```
AllowUsers johndoe
```

For this section, if you already have other users on the server, make sure to include them as well. On AWS, for instance, a user named `ubuntu` is initialized and used to login for the first time. If you choose to create a new user, say `johndoe`, then you will need to add them together into `AllowUsers`:

```
AllowUsers johndoe ubuntu
```

Otherwise, you will no longer be able to login as `ubuntu` in the future.

Next, press `Esc` to quit insert mode, press `:` (colon) to enable the command function and enter `wq` to write and quit (after hitting `ENTER` to confirm).

Some other useful vi commands are: `:q` to quit without modification and `:q!` to force quit and discard changes.

Finally, we use the command:

```
service sshd reload
```

to enable our modifications.

Now we've created a new user `johndoe` and enabled both its super user privilege and SSH access. Next, we'll be learning to link this user to our PostgreSQL database.

# Configuring Postgres

Postgres allows from the start a user to access a database with its own name. Thus we must:

1. Create a `johndoe` user inside PostgreSQL.
2. Create a `johndoe` database in PostgreSQL.

Because we have a `johndoe` user in our server, it will automatically have permission to access the `johndoe` user in Postgres, and will be able to access the `johndoe` database.

## Installing PostgreSQL

```
apt-get install postgresql postgresql-contrib
```

## Creating a Postgres user

We use the following command to switch to a super user in Postgres named `postgres` and use it to create a Postgres user:

```
sudo -i -u postgres
createuser johndoe -P
```

After inputting and confirming the password, we now have created a Postgres user. Remember that we use the same username `johndoe` to create the Postgres user, since by default, Postgres only allows the UNIX user with the same name as its Postgres user to interact with it.

## Creating a PostgreSQL database for our user

After having created the Postgres user, we use the command

```
createdb johndoe
```

to create a database also name `johndoe`. Now, our UNIX user `johndoe` can directly interact with the PostgreSQL database named `johndoe` using the command:

```
psql
```

## Some useful Postgres commands

To see the current connection info, use:

```
\conninfo
```

To quit Postgres:

```
\q
```

## Improve security on our PostgreSQL database

However, notice that we've created a password for the Postgres user but never have to use it just because we used the same username in UNIX and Postgres. It is safer to require a password when connecting to the database. Use the below command to configure Postgres security options.

```
sudo vi /etc/postgresql/9.5/main/pg_hba.conf
```

Navigate to the bottom of the file, and we may see something like this:

```
# Database administrative login by Unix domain socket
local   all             postgres                                peer

# TYPE  DATABASE        USER            ADDRESS                 METHOD

# "local" is for Unix domain socket connections only
local   all             all                                     peer
# IPv4 local connections:
host    all             all             <IP_ADDRESS>/32            md5
# IPv6 local connections:
host    all             all             ::1/128                 md5
```

Change the line

```
local   all             all                                     peer
```

to

```
local   all             all                                     md5
```

to enable password authentication.

**Important:** SQLAlchemy will ***NOT*** work unless we do this modification.

# Getting code from GitHub

In this section, we will pull our code from `GitHub`, which integrates a popular VCS (Version Control System) called `Git`. `Git` is a very good tool to manage and access your code both locally and remotely.

## Setting up our app folder

First, we create a folder called `items-rest` for our app, since our sample project is a REST API which manages items of stores. We create this folder using the following command:

```
sudo mkdir /var/www/html/items-rest
```

The folder is owned by the `root` user since we used `sudo` to create it. We need to transfer ownership to our current user:

```
sudo chown johndoe:johndoe /var/www/html/items-rest
```

Remember that `johndoe` is the username in our tutorial, make sure you change it to yours accordingly. The same goes for `items-rest`.

Next, we get our app from `Git`:

```
cd /var/www/html/items-rest/
git clone https://github.com/schoolofcode-me/stores-rest-api.git .
```

Note that there's a trailing space and period (` .`) at the end, which tells `Git` the destination is the current folder. If you're not in this folder `/var/www/html/items-rest/`, remember to switch to it or explicitly specify it in the `Git` command. And for the following commands in this section, we all assume that we are inside the folder `/var/www/html/items-rest/` unless specified otherwise.

In order to store logs, we need to create a log folder, (under `/var/www/html/items-rest/`):

```
mkdir log
```

Then we will install a bunch of tools we need to set up our app:

```
sudo apt-get install python-pip python3-dev libpq-dev
```

Next, we will install `virtualenv`, which is a python library used to create virtual environment. Since we may want to deploy several services on one server in the future, using virtual environment allows us to create independent environment for each project so that their dependencies won't affect each other. We may install `virtualenv` using the following command:

```
pip install virtualenv
```

After it is installed, we can create a `virtualenv`:

```
virtualenv venv --python=python3.5
```

Note that `Ubuntu` usually comes with `Python3.5` and it is what we used in the sample code, if you choose to use different versions of `Python`, feel free to change it accordingly and it will be the Python version inside your `virtualenv`.

To activate `virtualenv`:

```
source venv/bin/activate
```

You should see `(venv)` appears at the start of your command line now. We assume that we are in `virtualenv` for all the following commands in this section unless specified otherwise.

Next, use the command below to install the specified dependencies:

```
pip install -r requirements.txt
```

`requirement.txt` is a text file that includes all the dependencies that we created in our `Git` folder. It's highly recommended to have a `requirements.txt` file with all libraries your project requires.

Note that when installing these requirements, we are inside the virtual environment `venv`, so all the libraries are installed into `venv`, and once we quit `venv`, these libraries won't take effect.

*Hint:* to quit virtual environment, use command:

```
deactivate
```

# uWSGI

In this section, we will be using `uWSGI` to run the app for us, in this way, we can run our app in multiple threads within multiple processes. It also allow us to log more easily. More details on `uWSGI` can be found [here](https://uwsgi-docs.readthedocs.io/en/latest/).

First, we define a `uWSGI` service in the system by:

```
sudo vi /etc/systemd/system/uwsgi_items_rest.service
```

And the content we are going to input is shown below:

```
[Unit]
Description=uWSGI items rest

[Service]
Environment=DATABASE_URL=postgres://johndoe:<johndoe_postgres_password>@localhost:5432/johndoe
ExecStart=/var/www/html/items-rest/venv/bin/uwsgi --master --emperor /var/www/html/items-rest/uwsgi.ini --die-on-term --uid johndoe --gid johndoe --logto /var/www/html/items-rest/log/emperor.log
Restart=always
KillSignal=SIGQUIT
Type=notify
NotifyAccess=all

[Install]
WantedBy=multi-user.target
```

We will explain the basic idea of these configs. Each pair of square brackets `[]` defines a `section` which can contain some properties.

The `Unit` section simply provides some basic description and can be helpful when looking at the logs.

The `Service` section contains several properties related to our app. The `Environment` properties defines all the environment variables we need in our code. In our sample code, we want to retrieve the DATABASE_URL from system environment. And this is the place where you should keep all your secrets, such as secret keys and credentials. Beware that the `DATABASE_URL` should follow the format:

```
<database_type>://<db_username>:<db_user_password>@localhost:<db_port>/<db_name>
```

If we want to add multiple environment variables, we just need to add multiple lines of the `Environment` entry following the syntax:

```
Environment=key=value
Environment=key=value
Environment=key=value
...
```

The `ExecStart` property informs `uWSGI` on how to run our app as well as log it.

At last, the `WantedBy` property in `Install` section allows the service to run as soon as the server boots up.

**Important:** remember to change the username, password, database name and service name/folder accordingly in your own code.

*Hint:* after editing the above file, press `ESC` to quit insert mode and use `:wq` to write and quit.

## Configuring uWSGI

Our next step is to configure `uWSGI` to run our app. To do so, we need to create a file named `uwsgi.ini` with the following content:

```
[uwsgi]
base = /var/www/html/items-rest
app = run
module = %(app)

home = %(base)/venv
pythonpath = %(base)

socket = %(base)/socket.sock

chmod-socket = 777

processes = 8

threads = 8

harakiri = 15

callable = app

logto = /var/www/html/items-rest/log/%n.log
```

Note that you should change the `base` folder accordingly in your own app. For the second entry, `run` is referred to the `run.py` in our sample app, which serves as the entry point of our app, so you may need to change it accordingly in your own project as well. We defined the `socket.sock` file here which will be required by the `nginx` later. The socket file will serve as the connection point between `nginx` and our `uWSGI` service.

We asked for 8 processes with 8 threads each for no particular reason, you may adjust them according to your server capacity and data volume. The `harakiri` is a Japanese word for suicide, so in here it means for how long (in seconds) will the `emperor` kill the thread if it has failed. This is also an advantage we have with `uWSGI`, it allows our service to be resilient to minor failures. And it also specifies the log location.

And at last, after saving the above file, we use the command below to run the `uWSGI` service we defined earlier:

```
sudo systemctl start uwsgi_items_rest
```

And we should be able to check the `uWSGI` logs immediately to make sure it's running by using the command:

```
vi /log/uwsgi.log
```

If anything is running normally, we should be seeing something like this:

But if there is any error in our code, it will also be reflected in the log.

# Nginx

`Nginx` (engine x) is an HTTP and reverse proxy server, a mail proxy server, and a generic TCP/UDP proxy server. In this tutorial, we use `nginx` to direct traffic to our application. `Nginx` can be really helpful in scenarios like running our app on multiple threads, and it performs very well so we don't need to worry about it slowing down our app. More details about `nginx` can be found [here](https://nginx.org/en/).

## Installing nginx

```
sudo apt-get install nginx
```

## Configure firewall to grant access to nginx

First, check if the firewall is active:

```
sudo ufw status
```

If not, we will enable it later. Before that, let's add some new rules:

```
sudo ufw allow 'Nginx HTTP'
sudo ufw allow ssh
```

**Important:** the second line, adding SSH rules, is not related to `nginx` configuration, but since we're activating the firewall, we don't want to get blocked out of the server!

If the UFW (Ubuntu Firewall) is inactive, use the command below to activate it:

```
sudo ufw enable
```

To check if `nginx` is running, use the command:

```
systemctl status nginx
```

Some other helpful command options for system controller are:

```
systemctl start <service_name>
systemctl restart <service_name>
systemctl reload <service_name>
systemctl stop <service_name>
```

## Configure nginx for our app

Before deploying our app onto the server, we need to configure `nginx` for our app. Use the below command to create a config file for our app:

```
sudo vi /etc/nginx/sites-available/items-rest.conf
```

Note that `items-rest` is what we named our service, you may change it accordingly, but remember to remain consistent throughout the configurations.

Next, we input the below text into `items-rest.conf` file. **Remember to change your service name accordingly in this file as well**.

```nginx
server {
  listen 80;
  real_ip_header X-Forwarded-For;
  set_real_ip_from <IP_ADDRESS>;
  server_name localhost;

  location / {
    include uwsgi_params;
    uwsgi_pass unix:/var/www/html/items-rest/socket.sock;
    uwsgi_modifier1 30;
  }

  error_page 404 /404.html;
  location = /404.html {
    root /usr/share/nginx/html;
  }

  error_page 500 502 503 504 /50x.html;
  location = /50x.html {
    root /usr/share/nginx/html;
  }
}
```

The above config allows `nginx` to send the request coming from our user's browser to our app. It also sets up some error pages for our service using `nginx` predefined pages.

And at last, in order to enable our configuration, we need to do something like this:

```
sudo rm /etc/nginx/sites-enabled/default
sudo ln -s /etc/nginx/sites-available/items-rest.conf /etc/nginx/sites-enabled/
```

We need to remove the default file since `nginx` will look at this file by default. We want `nginx` to look at our config file instead, thus we added a soft link between our config file and the `site-enabled` folder.

## Running our app

Finally, we can launch our app! We can do so by starting the `nginx` and `uWSGI` services we defined (we already started the `uWSGI` service in the previous section).

```
sudo systemctl start nginx
```

If any of these services is already running, you may use the below commands (taking `nginx` for example) to reload and restart it so that it has the latest changes:

```
sudo systemctl reload nginx
sudo systemctl restart nginx
```

# Deployment wrap-up

As the tutorial is very detailed, you may find it a bit hard to put the pieces together. Here's a quick wrap-up that may help you sort things out.

- We created a `UNIX` user and granted him some privilege.
- We set up `PostgreSQL` database and configured our user to interact with it.
- We used `uWSGI` to run our app multi-processly and multi-threadly.
- We used `nginx` to direct requests to our `uWSGI` service.

Thanks for reading!

url: https://raw.githubusercontent.com/Rebell-Leader/bg/616a40286fe1d34db2916762c477676ed8067cdb/REST/rest-api-sections-master/guides/How To Deploy Python App Using uWSGI And Nginx.md

repository: Rebell-Leader/bg

gha_language: Jupyter Notebook

repo_name: Rebell-Leader/bg


text:
# Myprysm Vert.x Web

Set of helpers to quickly bind endpoints to a Vert.x HTTP Server through a Router.

WebVerticle will lookup the classpath to find `Endpoint` (and `OpenAPI3Endpoint`) implementations and register/configure them.

Note that this is an experimental module at the moment, breaking changes can occur at every release.
The project will follow [SEMVER](https://semver.org/).

## Endpoint

An `Endpoint` is a bit like a [Service](../vertx-service/README.md), a lightweight component,
automatically instanciated during `WebVerticle` startup.

It expects to have a public default constructor and should be automatically initialized through
the `AbstractEndpoint` class (or directly implement `Endpoint` for some \[unreasonable\] reason...).

`AbstractEndpoint` (as well as `AbstractOpenAPIEndpoint`) can quickly `#setContentJson` on a request.

## Open API 3.0 Support

You can enable the Open API 3.0 support by toggling the flag `useOpenAPIRouter` to `true`
and provide a valid `specs` file (can be retrieved from remote URL, see Vert.x Web API Contract documentation).

Operations **must** extend `AbstractOpenAPIEndpoint`, the operation will be automatically bound to the
appropriate spec.

It will also expose the following route:

* `/swagger.json` the service specs

## Cross Origin Resource Sharing

Vert.x Cross Origin Resource Sharing options are fully supported with the `WebVerticle` options.
Toggle the flag `enableCors` along with your custom `cors` options.

## Monitoring path

You can customize the default monitoring path (`/__`) by providing a valid `monitoringPath`.
This will affect the routes described below.

## Metrics

Metrics are disabled by default. You can enable them with the flag `enableMetrics`.
This will instanciate a metrics handler that will register all the request path and measure the throughput
with the Vert.x Dropwizard `ThroughputTimer`.

Following paths are exposed:

* `/__/metrics/vertx` all the metrics exposed by vertx
* `/__/metrics/requests` [ThroughputTimer](https://vertx.io/docs/vertx-dropwizard-metrics/java/#throughput_timer) per endpoint
* `/__/metrics/hystrix` SSE stream for Hystrix Dashboard

This will expose also the monitoring endpoint.

## Health Checks

This will enable the endpoint for health checks configured with [vertx-service](../vertx-service/README.md).

The following route will be exposed:

* `/__/hc` service healthcheck

This will expose also the monitoring endpoint.

### Miscellaneous

No ordering is currently supported for `Endpoint` registration.
This will come in next releases.

No support currently for security handlers on OpenAPI 3.0. Next releases...

repository: myprysm/vertx-utils

repo_name: myprysm/vertx-utils


text:
# Use debconf and templates

Deb installation format has a support for user input during installation using [debconf](https://manpages.debian.org/testing/debconf-doc/debconf-devel.7.en.html).

To enable it inside `goreleaser` you need:

`templates` file, what to ask (all templates go into single file):

```none
Template: foo/like_debian
Type: boolean
Description: Do you like Debian?
 We'd like to know if you like the Debian GNU/Linux system.

Template: foo/why_debian_is_great
Type: note
Description: Poor misguided one. Why are you installing this package?
 Debian is great. As you continue using Debian, we hope you will
 discover the error in your ways.
```

Maintainer script file that will trigger questions, usually its `postinst` because all package files are already installed:

```sh
#!/bin/sh -e

# Source debconf library.
. /usr/share/debconf/confmodule

# Do you like debian?
db_input high foo/like_debian || true
db_go || true

# Check their answer.
# with db_get you load value into $RET env variable.
db_get foo/like_debian
if [ "$RET" = "false" ]; then
    # Poor misguided one...
    db_input high foo/why_debian_is_great || true
    db_go || true
fi
```

Include `templates` and `postinst` in `.goreleaser.yaml`:

```yaml
    overrides:
      deb:
        scripts:
          postinstall: ./deb/postinst
    deb:
      scripts:
        templates: ./deb/templates
```

Useful tutorial: [Debconf Programmer's Tutorial](http://www.fifi.org/doc/debconf-doc/tutorial.html)

repository: goreleaser/goreleaser

gha_language: Go

repo_name: goreleaser/goreleaser


text:
## LPNE feature extraction and classification pipeline

Code for preprocessing and building models with local field potentials.

See `feature_pipeline.py` and `prediction_pipeline.py` for usage.

#### Installation

```bash
$ git clone https://github.com/carlson-lab/lpne.git
$ cd lpne
$ pip install .
```

#### Dependencies
* [Python3](https://www.python.org/)
* [MoviePy](https://github.com/Zulko/moviepy)
* [PyTorch](https://pytorch.org)

### TO DO
1. add normalization options
2. n networks with n-class prediction?
4. remove bad windows
5. more unit tests
6. consolidate plot_factor.py and plot_power.py
7. add docstrings for channel maps
9. Add a Tucker decomposition model? <- could be a good way to separate
   between-mouse differences
10. PoE?
12. Manually remove regions from LFPs
17. Change q parameter to bandwidth in notch filters

repository: cpne-common/lpne

repo_name: cpne-common/lpne


text:
# Guidelines for deploying microservices to docker from the pipeline and dockerizing applications.

## Dockerfile
A Dockerfile file should be added at the root level of the project. This is a sample springboot default Dockerfile:

```
FROM frolvlad/alpine-oraclejdk8:slim
VOLUME /tmp
ADD "Replace this with the path to the jar file" app.jar
EXPOSE 8080
ENTRYPOINT [ "sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar" ]
```

The path to the output folder jar file should be properly added, for example: build/libs/new-project-0.0.1-SNAPSHOT.jar
The exposed port should match the port the applications is cofigured to listen too.

## .travis.yml file
Add the needed credentials using travis from the command line:
If travis is not installed or the command is not recognized, first install it with gem:

```gem install travis```

Then run:

```travis encrypt VAR_NAME="value to encrypt"```

For the variables DOCKER_USERNAME and DOCKER_PASSWORD as seen in the script below. These values can then be used throught the script.

Add the following script to the .travis.yml file in for the project and add the corresponding docker hub repo for the project. By default only master will be pushed but this can be configured to push depending on other conditions like git tags.

```yml
before_install:
  - echo "Testing Docker Hub credentials"
  - docker -v
  - docker login -u=$DOCKER_USERNAME -p=$DOCKER_PASSWORD
  - echo "Docker Hub credentials are working"

after_success:
  - export ACTUAL_BRANCH=$(if [ "$TRAVIS_PULL_REQUEST" == "false" ]; then echo $TRAVIS_BRANCH; else echo $TRAVIS_PULL_REQUEST_BRANCH; fi)
  - echo "Test Success - BranchActual($ACTUAL_BRANCH) Pull Request($TRAVIS_PULL_REQUEST) Tag($TRAVIS_TAG) PR($TRAVIS_PULL_REQUEST) Build($TRAVIS_BUILD_NUMBER)"
  - if [[ "$ACTUAL_BRANCH" == "master" ]]; then echo -e "Push Container to Docker Hub"; fi
  - docker login -u=$DOCKER_USERNAME -p=$DOCKER_PASSWORD
  - export REPO="ADD DOCKERHUB REPO"
  - export TAG=`if [ "$ACTUAL_BRANCH" == "master" ]; then echo "latest";else echo ""; fi`
  - docker build -f Dockerfile -t $REPO:$TAG .
  - docker push $REPO

```

## docker-compose

A docker-compose.yml file should be added to the applications root:
This is an example docker compose file which follow the structure:
* version:
    This field is always required.
* services:
    A list of the services needed for the application to run correctly.

The following example spins up mongodb, rabbitmq and the current application as docker containers.

By not specifying the host ports for the project services it is left to docker compose to figure out what available ports are left. The port assigned to it can be check running ```docker ps``` and checking the PORTS entry for the docker image.

For example: ```<IP_ADDRESS>:32777->8080/tcp``` means that host port 32777 is the port used by the container.

```yml
version: '3'
services:
  mongo:
    image: 'mongo:3.4.1'
    container_name: 'mongo'
    ports:
      - '27017:27017'
    volumes:
      - 'mongo:/data/db'
  rabbitmq:
    image: rabbitmq:management
    container_name: 'rabbitmq'
    ports:
      - "5672:5672"
      - "15672:15672"
  this-project:
    build: ./
    container_name: 'this-project'
    environment:
      - RABBIT_HOST=rabbitmq
      - MONGO_HOST=mongo
    ports:
      - '8080'
    depends_on:
      - rabbitmq
      - mongo
volumes:
  mongo:
```

repository: AITestingOrg/documentation

repo_name: AITestingOrg/documentation


text:
# HaproxyRest

Demonstration Gem meant to be run as a server daemon for querying and controlling HAProxy.

## Design
A single object represents HAProxy config

Another object represents HAProxy service daemon

Another object represents a listening server daemon.

The Listening server daemon only supports two operations, with three results.
 1. Get backend config, returns the HAProxy backend config
 2. Modify listening server, sets the HAProxy backend config and reloads HAProxy
 3. Invalid input, returns error.

## Installation

Add this line to your application's Gemfile:

```ruby
gem 'haproxy_rest'
```

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install haproxy_rest

## Usage

```
require 'haproxy_rest'
HaproxyRest.run()
```

## Contributing

1. Fork it ( https://github.com/[my-github-username]/haproxy_rest/fork )
2. Create your feature branch (`git checkout -b my-new-feature`)
3. Commit your changes (`git commit -am 'Add some feature'`)
4. Push to the branch (`git push origin my-new-feature`)
5. Create a new Pull Request


text:
---
layout: default
---

# 1996-04-17 - Re: Re[2]: What's the "Human Interaction Institute" at CMU For ???

## Header Data

From: "Perry E. Metzger"<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: fb543ba9da9f79134842ee06bce03ea781a9d9a04790eef51e917bbc04d02ba2

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1996-04-17 10:08:31 UTC

Raw Date: Wed, 17 Apr 1996 18:08:31 +0800

## Raw message

```
{% raw  %}From: "Perry E. Metzger"<EMAIL_ADDRESS>Date: Wed, 17 Apr 1996 18:08:31 +0800
To<EMAIL_ADDRESS>Subject: Re: Re[2]: What's the "Human Interaction Institute" at CMU For ???
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

<EMAIL_ADDRESS>writes:
>           Am I the only one worrying about the use of technology to
>           implement a "New World Order" ???

Yes. The rest of us are all part of the attempt to create such a world
order, and thus aren't worried about it because we will be in control
of the puny little lives of people such as yourself.

>           A similar concern could be made about biotechnology: with
>           gene splicing, it would be possible to create a race of "sub
>           humans" to do slave labor and fight wars.

Even now, my armies of genetic slaves are out there searching for
human blood...

Vlad "Genex" Metzger

{% endraw %}
```

## Thread

+ Return to [April 1996](/archive/1996/04)

+ Return to "["Perry E. Metzger" <perry@piermont.com>](/authors/perry_e_metzger_perry_at_piermont_com_)"
+ Return to "[Rabid Wombat <wombat@mcfeely.bsfs.org>](/authors/rabid_wombat_wombat_at_mcfeely_bsfs_org_)"
+ Return to "[ssalgaller@CCGATE.HAC.COM](/authors/ssalgaller_at_ccgate_hac_com)"

+ 1996-04-17 (Wed, 17 Apr 1996 18:19:51 +0800) - [Re[2]: What's the "Human Interaction Institute" at CMU For ???](/archive/1996/04/10227b4c2deda04fd69af6907f80ace3ba9f39619587a83c508d4f1b5f4558e7) -<EMAIL_ADDRESS>  + 1996-04-17 (Wed, 17 Apr 1996 18:08:31 +0800) - Re: Re[2]: What's the "Human Interaction Institute" at CMU For ??? - _"Perry E. Metzger"<EMAIL_ADDRESS>  + 1996-04-17 (Wed, 17 Apr 1996 23:23:59 +0800) - [[NOISE] was Re: Re[2]: What's the "Human Interaction Institute" at CMU For ???](/archive/1996/04/935d94e4c7ccc387d5383321baabf5708caaad17bb1d417ebf23414dceb9b7a7) - _Rabid Wombat<EMAIL_ADDRESS>


text:
# Subscription Test Result

Represents the details of a webhook subscription, including notification URL,
event types, and signature key.

## Structure

`Subscription Test Result`

## Fields

| Name | Type | Tags | Description |
|  --- | --- | --- | --- |
| `id` | `str` | Optional | A Square-generated unique ID for the subscription test result.
**Constraints**: *Maximum Length*: `64` |
| `status_code` | `int` | Optional | The status code returned by the subscription notification URL. |
| `payload` | `str` | Optional | An object containing the payload of the test event. For example, a `payment.created` event. |
| `created_at` | `str` | Optional | The timestamp of when the subscription was created, in RFC 3339 format.
For example, "2016-09-04T23:59:33.123Z". |
| `updated_at` | `str` | Optional | The timestamp of when the subscription was updated, in RFC 3339 format. For example, "2016-09-04T23:59:33.123Z".
Because a subscription test result is unique, this field is the same as the `created_at` field. |

## Example (as JSON)

```json
{
  "id": "id0",
  "status_code": 122,
  "payload": "payload6",
  "created_at": "created_at2",
  "updated_at": "updated_at4"
}
```

repository: square/square-python-sdk

gha_license_id: NOASSERTION

repo_name: square/square-python-sdk


text:
Go learning project. Simple implementation of a promo code generator and validator for giving reviewers access to in app purchase protected areas of an iOS app. Minimal query string based authentication and short, easy to type promo codes.

Uses MongoDB hosted via MongoHQ Heroku addon with mgo for persistence and gorilla/mux for routing.

Use
---

To create a new promo code:

`curl http://your-project.herokuapp.com/pc?p=yourpassword`

Outputs code as plain text, sans newline.

To redeem a promo code:

`curl http://your-project.herokuapp.com/promocodes/yourcode`

Outputs `true` or `false` sans newline.

To list valid and redeemed promo codes, visit:

`http://your-project.herokuapp.com/pcall?p=yourpassword`

Run Locally
-----------

Be sure mongodb is installed and running on default port (27017), then:

`PORT=5000 MONGOHQ_URL=mongodb://localhost/promocodes MONGOHQ_DB_NAME=promocodes PROMOPW=password go run web.go`

Deployment
----------

To create a Heroku instance with the Go Buildpack:

`heroku create -b https://github.com/kr/heroku-buildpack-go.git`

Install the MongoHQ Addon:

`heroku addons:add mongohq:sandbox`

Set the following env vars:

`heroku config:set PROMOPW=yourpassword MONGOHQ_DB_NAME=find-this-through-mongohq-web-interface MONGOHQ_URL=also-found-in-mongohq-web-interface`

And push:

`git push heroku master`

Be sure to run `go get` after making any changes to recompile your binary.

repository: danenania/go-promocodes

repo_name: danenania/go-promocodes


text:
Application imem
================

Release history with new or improved features and bugfixes

Version 1.2.3 (Release Date 04.09.2013)
=======================================

* spawn zipping of files on startup into separate process, avoid zip startup delays
* unzip goes into default snapshot directory, avoiding problems with temp directory
* delete orphan ddTable entry for drop table when table is dropped on MNESIA level
* remove logging of drop / truncate in imem_meta, reduce risk of call recursion
* use separate processes for purge and monitor, will allow logging in these functions
* improve variable binding in joins and support tuple values better

* fix permission problem for drop_table / truncate_table, used in dderl

* added virtual table ddSchema

Version 1.2.2 (Release Date 29.08.2013)
=======================================

* add ddTable record to user_properties (included in shnapshot)
* extend timeout for snapshots
* create table in restore using user_propertties if it does not exist
* implement nodef() formatter function for suppressing default values in SQL select columns
* add pseudocolumn expiry = time_of_partition_expiry()  to ddSize virtual table
* add pseudocolumn tte = time_to_partition_expiry() to ddSize virtual table
* add value owner to config entries and prevent different key owner from overwriting

* bad_rpc issue fixed in ddNodes evaluation
* ddSize typo fixed

* use os_mon / lager for system monitoring
* change logging from info to debug for drop_table, subscribem unsubscribe

* snapshot issues fixed
* snap for only local readable tables
* snap restore and backup one file at a time

Version 1.2.1 (Release Date 13.08.2013)
=======================================

* change dependencies to forked own versions (for reproducability)
* no functional changes

Version 1.2.0 (Release Date 08.08.2013)
=======================================

* configurable snapshot fun
* chunked streaming format for snapshot and restore
* configurable purge fun which can act based on available os memory limits
* memory usage column added to virtual table ddSize

* fixes for binary table names in security layer imem_sec
* clean and central parsing for time partitioned tables
* teardown of imem_if in case of MNESIA down signal
* improved zip-file handling for snapshots
* fix connection probe issue with accept_once

Version 1.1.2 (Release Date 23.07.2013)
=======================================

* using lager logging for low level imem functions
* configurable monitor extensions
* configurable monitor dump to file system

* fix lock situation in log partition rollover

Version 1.1.1 (Release Date 05.07.2013)
=======================================

* extended snapshotting functions and escript access
* ddSize virtual table with row count column for joins with table names

* fix for sorting issue

Version 1.1.0 (Release Date 02.07.2013)
=======================================

repository: imace/imem

repo_name: imace/imem


text:
# Using functions

Pattern matching, private functions, and normal use:

```
defmodule TestFunc do
	defp say( greeting, name ) do
		IO.puts greeting <> name
	end

	def say_hi( "chris" ) do
		IO.puts( "Slacker!" )
	end
	def say_hi( name ) do
		say( "hi" , name )
	end
	def say_hi( "paul" ) do
		IO.puts("it's paul!")
	end
end
```


text:
sphinx-serve
------------

Simple utility to easier preview your sphinx documentation.

After running the sphinx-serve command, it tries to detect the
sphinx build directory. It examines the current working directory
and if the build directory is not present, it tries to iterate
the parent paths. If a build directory is detected it launches
an http server.

The build directory name is configurable. It also supports serving
documentation from the html folder of the singlehtml folder.

Installation
------------

    pip install sphinx-serve

Usage
-----
Synopsis:

    usage: sphinx-serve [--help] [-v] [-h HOST] [-p PORT] [-b BUILD] [-s]

Arguments:

* `--help`: show help and exit
* `--version`, `-v`: show program version and exit
* `--host`, `-h`: listen to the given hostname (default: <IP_ADDRESS>)
* `--port`, `-p`: listen to the given port (default: 8081)
* `--build`, `-b`: sphinx build directory name (default: "_build")
* `--single`, `-s`: serve the single-html version instead of the normal one

Run with:

    sphinx-serve

repository: tlatsas/sphinx-serve

repo_name: tlatsas/sphinx-serve


text:
> [Go to French version](/fr/Règlements/Décrets,%20ordonnances%20et%20règlements%20statutaires/79/678.md)

# Order Granting Authority to Regulate the Marketing of Tender Fruit in Ontario

**SOR/79-678**

Enabling authorities:
- [AGRICULTURAL PRODUCTS MARKETING ACT](/en/Acts/Revised%20Statutes%20of%20Canada/A/A-6.md)

Date registered: 24 September 1979

----------

His Excellency the Governor General in Council, on the recommendation of the Minister of Agriculture, pursuant to section 2 of the [Agricultural Products Marketing Act](/en/Acts/Revised%20Statutes%20of%20Canada/A/A-6.md), is pleased hereby to revoke the Ontario Fresh Fruit Order, C.R.C., c. 187 and the Ontario Tender Fruit-for-Processing Order, C.R.C., c. 219, and to make the annexed Order granting authority to regulate the marketing of tender fruit in Ontario in substitution therefor.

## Short Title

**1** This Order may be cited as the Ontario Tender Fruit Order.

## Interpretation

**2** In this Order,

***Act*** means The Farm Products Marketing Act of Ontario; (*Loi*)

***Board*** means The Farm Products Marketing Board of Ontario, established pursuant to the Act; (*Régie*)

***Commodity Board*** means The Ontario Tender Fruit Producers’ Marketing Board, established pursuant to the Act; (*Office*)

***Plan*** means any plan for the marketing of tender fruit, established and amended from time to time pursuant to the Act, and any regulations made pursuant to the Act to give effect to any such plan; (*Plan*)

***processing*** means
- **(a)** the manufacture of tender fruit products or of juice, beverages, spirits or wine from tender fruit, and
- **(b)** the canning, bottling, distilling, fermenting, dehydrating, pitting, drying or freezing of tender fruit; (*transformation*)

***tender fruit*** means peaches, pears, plums, sour cherries and sweet cherries produced in Ontario. (*fruits tendres*)
> SOR/92-291, s. 1.

## Interprovincial and Export Trade

**3** The Commodity Board and the Board are each authorized to regulate the marketing of tender fruit in interprovincial and export trade and for such purposes may, with respect to persons and property situated within the Province of Ontario, exercise all or any powers like the powers exercisable by each of them in relation to the marketing of tender fruit locally within the Province under the Act and the Plan.
> SOR/86-100, s. 1.

## Levies

**4** The Commodity Board may, in relation to the powers granted to it under section 3 with respect to the marketing of tender fruit in interprovincial and export trade,
- **(a)** fix and impose by order and collect levies or charges on persons situated in the Province of Ontario who are engaged in the production or marketing of tender fruit and for that purpose classify such persons into groups and, by order, fix the levies or charges payable by the members of different groups in different amounts; and
- **(b)** use the levies or charges for the purposes of the Commodity Board and the Board, including the creation of reserves and payment of expenses and losses resulting from the sale or disposal of tender fruit and the equalization or adjustment among tender fruit producers of moneys realized from the sale of tender fruit during such period or periods of time as the Commodity Board and the Board may determine.
> SOR/86-100, s. 2.

repository: TravisMadill/CanadianLaws

path: /en/Regulations/Statutory Orders and Regulations/79/678.md

repo_name: TravisMadill/CanadianLaws


text:
# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## 0.35.0

- Jls 0.40.0
- Diagnostics are enabled by default

## 0.34.0

- Jls `0.39.0`
- Diagnostics are disabled by default

## 0.33.1

- Ensure every `package.json` `contributes.configuration` property has a default value. Resolves a weird parsing edge case for implied null values, and has the added benefit of making things more explicit (omitted values result in `null`, by default).

## 0.33.0

- Jls `0.38.0`
- Add initialization option `jedi.workspace.environmentPath`

## 0.32.0

- Jls `0.37.0`

## 0.31.1

- Jls `0.36.1`

## 0.31.0

- Jls `0.36.0`

## 0.30.1

- Jls `0.35.1`

## 0.30.0

- Jls `0.35.0`

## 0.29.15

- Remove usage of `--system-site-packages` because it caused `jedi-language-server` to be installed in the system Python for some users. Instead, we rely on maually modifying `pyvenv.cfg` after the virtualenv is created and `jedi-language-server` is installed. See: <https://github.com/pypa/pip/issues/1408> and <https://github.com/pappasam/coc-jedi/issues/48>

## 0.29.14

### Fix

- Remove usage of `--upgrade-deps`; that wasn't introduced until Python 3.9, which would be broken support for earlier Python versions.

## 0.29.13

- Jedi's virtualenv now explicitly has access to the system's site-packages. Resolves <https://github.com/pappasam/coc-jedi/issues/11> and <https://github.com/pappasam/coc-jedi/issues/35>.

## 0.29.12

- Jls `0.34.12`

## 0.29.11

- Jls `0.34.11`

## 0.29.10

- Jls `0.34.10`

## 0.29.9

- Jls `0.34.9`

## 0.29.8

- Jls `0.34.8`

## 0.29.7

- Jls `0.34.7`
- New option `completion.ignorePatterns`

## 0.29.6

- Jls `0.34.6`

## 0.29.5

- Jls `0.34.5`

## 0.29.4

- Jls `0.34.4`
- Support debugging message capability.

## 0.29.3

- Jls `0.34.3`

## 0.29.2

- Jls `0.34.2`

## 0.29.1

- Jls `0.34.1`

## 0.29.0

- Jls `0.34.0`

## 0.28.0

- Jls `0.33.0`

## 0.27.0

- Jls `0.32.0`

### Added

The following new options (documented in the README):

- jedi.hover.enable
- jedi.hover.disable.class.all
- jedi.hover.disable.class.names
- jedi.hover.disable.class.fullNames
- jedi.hover.disable.function.all
- jedi.hover.disable.function.names
- jedi.hover.disable.function.fullNames
- jedi.hover.disable.instance.all
- jedi.hover.disable.instance.names
- jedi.hover.disable.instance.fullNames
- jedi.hover.disable.keyword.all
- jedi.hover.disable.keyword.names
- jedi.hover.disable.keyword.fullNames
- jedi.hover.disable.module.all
- jedi.hover.disable.module.names
- jedi.hover.disable.module.fullNames
- jedi.hover.disable.param.all
- jedi.hover.disable.param.names
- jedi.hover.disable.param.fullNames
- jedi.hover.disable.path.all
- jedi.hover.disable.path.names
- jedi.hover.disable.path.fullNames
- jedi.hover.disable.property.all
- jedi.hover.disable.property.names
- jedi.hover.disable.property.fullNames
- jedi.hover.disable.statement.all
- jedi.hover.disable.statement.names
- jedi.hover.disable.statement.fullNames

## 0.26.2

- Jls `0.31.2`

## 0.26.1

- Jls `0.31.1`

## 0.26.0

- Jls `0.31.0`

## 0.25.3

- Jls `0.30.3`

## 0.25.2

- Jls `0.30.2`

## 0.25.1

- Jls `0.30.1`

## 0.25.0

- Jls `0.30.0`
- Add jedi.codeAction.nameExtractFunction and jedi.codeAction.nameExtractVariable configuration.

## 0.24.0

- Jls `0.29.0`

## 0.23.7

- Jls `0.28.8`

## 0.23.6

- Jls `0.28.7`

## 0.23.5

- Jls `0.28.6`

## 0.23.4

- Jls `0.28.5`

## 0.23.3

- Jls `0.28.4`

## 0.23.2

- Jls `0.28.3`

## 0.23.1

- Jls `0.28.2`

## 0.23.0

- Jls `0.28.1` (uses pydantic, should fix some long-standing bugs)

## 0.22.2

- Jls `0.27.2`

## 0.22.1

- Jls `0.27.1`

## 0.22.0

### Added

- jedi.workspace.symbols.ignoreFolders

### Changed

- Jls `0.27.0`
- jedi.workspace.maxSymbols change to jedi.workspace.symbols.maxSymbols

## 0.21.0

- Jls `0.26.0`
- Add jedi.workspace.maxSymbols configuration.

## 0.20.8

- Jls `0.25.7`

## 0.20.7

- Jls `0.25.6`

## 0.20.6

- Jls `0.25.5`

## 0.20.5

### Fixed

- coc-managed pip is now updated, along with jedi language server, to suppress pip warnings. See <https://github.com/pappasam/coc-jedi/pull/28>
- activation events now only run for Python files. See <https://github.com/pappasam/coc-jedi/pull/27>

## 0.20.4

- Jls `0.25.4`

## 0.20.3

- Jls `0.25.3`

## 0.20.2

- Jls `0.25.2`

## 0.20.1

- Jls `0.25.1`

## 0.20.0

- Jls `0.25.0` (better docstring markdown support!)

## 0.19.0

- Jls `0.24.0`
- Add configuration option `jedi.jediSettings.caseInsensitiveCompletion`.

## 0.18.1

- Jls `0.23.1`

## 0.18.0

- Jls `0.23.0`
- Add configuration option `jedi.completion.resolveEagerly`.

## 0.17.0

- Jls `0.22.0`
- Update documentation about executable command, resolving <https://github.com/pappasam/coc-jedi/issues/8>
- Reverse behavior for startupMessage, resolving <https://github.com/pappasam/coc-jedi/issues/16>

## 0.16.0

### Added

- `jedi.workspace.extraPaths`, add additional paths for Jedi's analysis.

### Changed

- Jls `0.21.0`

## 0.15.1

- Jls `0.20.1`

## 0.15.0

- Jls `0.20.0`

## 0.14.4

- Jls `0.19.5`

## 0.14.3

- Jls `0.19.4`

## 0.14.2

- Jls `0.19.3`

## 0.14.1

### Changed

- Jls `0.19.1`

## 0.14.0

### Changed

- Jls `0.19.0`

## 0.13.2

### Changed

- Jls `0.18.1`

## 0.13.1

### Fixed

- Array types in `package.json` are now accurately listed. Before, they caused linting errors.

## 0.13.0

### Changed

- Jls `0.18.0`

## 0.12.2

### Changed

- Jls `0.17.1`

## 0.12.1

### Changed

- Removed restarting on configuration change. Based on its behavior, it was more of a bug than a feature.

### Fixed

- `coc-settings.json` configuration types no longer cause linting errors

## 0.12.0

### Added

- Configuration option to automatically import big modules (like Numpy): `jedi.jediSettings.autoImportModules`

### Changed

- Jls `0.17.0`

## 0.11.0

### Added

- Configuration option to disable jedi snippets: `jedi.completion.disableSnippets`

### Changed

- Jls `0.16.0`

## 0.10.1

### Changed

- Updated package metadata / readme

## 0.10.0

### Changed

- Jls `0.15.0`
- Add `jedi.markupKindPreferred` configuration

## 0.9.1

### Changed

- Obtain the current jls version when obtaining the default jls environment. If the current version is not equal to the expected version, re-install. This should make updates seamless for people who are "git pulling" the latest changes and may not be deleting an existing venv.

## 0.9.0

### Changed

- Jls `0.14.0`

## 0.8.1

### Changed

- Replace `fs.rmdirSync` with `rimraf`; already available in coc engine / relied upon and supports older nodes.

## 0.8.0

### Added

- Link to GitHub repository link in `package.json`

### Changed

- Due to Coc limitations involving postinstall hooks (https://github.com/neoclide/coc.nvim/issues/1909), automatic installation of jedi-language-server now takes place on coc-startup without npm scripts

## 0.7.4

### Changed

- `python3` instead of `python` in install script to be more widely compatible

## 0.7.3

### Changed

- Jls `0.13.2`

## 0.7.2

### Changed

- Fixed option parsing for executable command and args

## 0.7.1

### Changed

- TIL: `npmignore` and `gitignore` are mutually exclusive for npm uploads.

## 0.7.0

### Added

- Now automatically installs `jedi-language-server` in managed virtual environment for non-Windows environments.

### Removed

- Reference to pipx for manual installation. That was a bandaid anyway.

## 0.6.0

### Added

- Manage specific jedi-language-server by relying on pipx. Otherwise, consider user configuration and path configuration to determine location of Python executable
- Improve startupMessage to help people debug their setup if they experience issues
- jedi-language-server version is now in package.json
- jedi-language-server name is not in package.json
- Configuration options:
  - `jedi.executable.command`: jedi-language-server executable. Coc-managed defaults if not specified
  - `jedi.executable.args`: args passed to jedi-language-server executable. Ignored if command is null
  - `jedi.startupMessage`: enables (or disables the startup message)

## 0.5.0

### Added

- Documentation for all config options here

### Changed

- Pass jedi-rooted configuration to initializationOptions
- `enabled` changed to `enable`. I see the option spelled this way in way more coc plugins and I'd like to be consistent with the ecosystem.

## 0.4.0

### Added

- `jedi.enabled` to disable extension without needing to uninstall
- `jedi.trace.server` for debugging

## 0.3.1

### Added

- basic "server started" message on server ready

## 0.3.0

### Removed

- Remove deprecated configuration options from `package.json`

## 0.2.1

### Removed

- Unnecessary executable checking. This ended up checking existence even when non-Python files were opened, which would be annoying for people working across multiple languages. This ended up removing a dependency (which) and relying on the better error message provided by coc out of the box.

## 0.2.0

### Added

- Support signatureHelp

### Changed

- Error message when missing jedi-language-server executable now prints as error

## 0.1.0

### Added

- This CHANGELOG
- Configuration helpers for diagnostic configuration

repository: justanotherdevel/config

repo_name: justanotherdevel/config


text:
---
title: "t.s. eliot"
feed: show
tags: writer
---

> [[dante]] and [[shakespeare]] divide the world between them. there is no third.

thomas stearns eliot (1888-1965) was a writer of [[poem]]s, plays, and [[literary critic]]. he was born in st. louis, missouri, spending summers in new england. his mother was very religious and wrote poetry as well. he took a [[classics]] track in high school, becoming acquainted with [[greek]] and [[latin]].

at harvard, he joined a few associations and clubs. he was not a particularly good student at first, and he almost got expelled early on due to his low grades.

he interacted with [[bertrand russell]], [[weiner]] and [[santayana]].

at some point, he moved to london and became an english citizen.

he was a francophile, interested in the work of [[bergson]].

eliot belongs to the movement of [[modern]].

his critical essays include

* "what Is a [[classic]]?"
* "tradition and the individual talent"
* "hamlet and his problems" about [[hamlet]]
* a review of [[ulysses]]

he also read about [[buddhism]].

### shakespeare and the stoicism of seneca

in this essay, eliot wants to stop people from seeing [[seneca]] in shakespeare.

> i propose a shakespeare under the influence of the stoicism of seneca. but i do not believe that shakespeare was under the influence of seneca... i wish mereley to disinfect the senecan shakespeare before he appears. my ambitions would be realized if i could prevent him, in so doing, from appearing at all.

eliot says shakespeare probably read seneca's tragedies but not his prose.

repository: ashwinreddy/blog

path: /_notes/Public/People/t.s. eliot.md

filename: t.s. eliot.md

repo_name: ashwinreddy/blog


text:
# Minimal Webpack setup for React with Typescript, Prettier and ESLint

Code to accompany our blog post about the current state of setting up a react app from scratch - [A minimal Webpack setup for React with Typescript, Prettier and ESLint](https://formwerdung.ch/blog/minimal-webpack-setup-react-typescript-prettier-eslint). Used as a basis for other React code examples.

Developed with `Node 12`, untested on other versions.

## Usage

Install dependencies with:

`npm i`

Start the dev server with:

`npm run develop`

Build package with:

`npm run build`

Perform a type check with Typescript

`npm run check-types`

Lint package with:

`npm run lint`

Autofix variant:

`npm run lint:fix`

repository: Formwerdung/code-examples

gha_language: JavaScript

repo_name: Formwerdung/code-examples


text:
---
layout: tool
title: VistaPoint
developer_github_account:
paper: https://www.ncbi.nlm.nih.gov/pubmed/11159318
paper_title: "VISTA : visualizing global DNA sequence alignments of arbitrary length."
doi: 10.1093/bioinformatics/16.11.1046
browser: http://pipeline.lbl.gov/cgi-bin/gateway2?selector=vistapoint
abstract: "SUMMARY: VISTA is a program for visualizing global DNA sequence alignments of arbitrary length. It has a clean output, allowing for easy identification of similarity, and is easily configurable, enabling the visualization of alignments of various lengths at different levels of resolution. It is currently available on the web, thus allowing for easy access by all researchers. AVAILABILITY: VISTA server is available on the web at http://www-gsd.lbl.gov/vista. The source code is available upon request."
citation: "Mayor C, Brudno M, Schwartz JR, Poliakov A, Rubin EM, Frazer KA, et al. VISTA : visualizing global DNA sequence alignments of arbitrary length. Bioinformatics. academic.oup.com; 2000;16: 1046–1047."
citation_count: 889
feature_type: ['segment sparse', 'segment contiguous', 'point sparse', 'point contiguous']
interconnection_type: ['no']
genome_layout: ['linear']
partition: ['segregated']
abstraction: ['no']
arrangement: ['no']
view: single
scale: single
focus: single
coordinate_systems: multiple
access_format: [web application]
user_documentation_availability: yes
user_documentation: http://pipeline.lbl.gov/vista_help/help.html#vistapoint
pub_year: 2000
license: unavailable
license_form: unknown
supported_files: ['fasta', 'other']
image: /assets/vistapoint.png
image_location: http://pipeline.lbl.gov/tbrowser/tbrowser/
notes:
---

repository: hms-dbmi/genocat

gha_language: HTML

repo_name: hms-dbmi/genocat


text:
# Socket.io Template :rocket:

## Purpose :dark_sunglasses:

The purpose of this repository is to understand how to utilize socket.io effectively later.

### User Stories :telescope:

1. Users will be able to look through the various examples and understand how to utilize socket.io well.

#### About Socket.io

- [ ] You can send and receive any events you want, with any data you want
- [ ] To send an event, implement io.emit()

```
io.on("connection", (socket) => {
  console.log("a user connected");
  // on a chat message
  socket.on("chat message", (msg) => {
    // emit the message
    io.emit("chat message", msg);
  });
  socket.on("disconnect", () => {
    console.log("user disconnected");
  });
});
```

- [ ] in index.html

```
    // This initalizes a client, exposing io global
      var socket = io();
      $(function () {
        var socket = io();
        $("form").submit(function (e) {
          e.preventDefault();
          socket.emit("chat message", $("#m").val());
          $("#m").val("");
          return false;
        });
        // on a chat message, append li tags around the message
        socket.on("chat message", function (msg) {
          $("#messages").append($("<li>").text(msg));
        });
      });
```

## Sprint :athletic_shoe:

| Done? | Component           | Priority | Estimated Time | Actual Time |
| ----- | ------------------- | :------: | :------------: | :---------: |
| x     | This checklist      |    H     |    30 mins     |   30mins    |
| x     | Read documentation  |    M     |    30 mins     |   10mins    |
| x     | Set up basic server |    M     |    30 mins     |   15 mins   |

### Daily Stand Up :hourglass:

## Issues and Resolutions :flashlight:

**ERROR**: :gear:
**RESOLUTION**: :key:

| Issue                | Where it occurs | Possible solution | Actual solution |
| -------------------- | :-------------: | :---------------: | :-------------: |
| Creating a checklist |        H        |       2hrs        |     2.5hrs      |

#### What is one thing that I learned from doing this project? :books:

#### Credits :recycle:

[Socket.io](https://socket.io/)

#### Contributing :round_pushpin:

Pull requests are welcome. For major changes, please open an issue first to discuss what you would like to change.
Not sure how? Learn [Github](https://www.youtube.com/watch?v=3RjQznt-8kE&list=PL4cUxeGkcC9goXbgTDQ0n_4TBzOO0ocPR)
Please make sure to update tests as appropriate.

#### License :memo:

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

repository: alexzclin/secretsauces

repo_name: alexzclin/secretsauces


text:
# overdrive-m4b

A dirty script to convert Overdrive audiobooks to a single m4b file. Use at your own peril.

## Install

```
brew tap pflouret/tap
brew install overdrive-m4b
```

or, if you want to use the official `ffmpeg` without libfdk_aac codec

```
brew tap pflouret/tap
brew install overdrive-m4b --without-fdk-aac
```

## Useful utilites to use in conjunction

- https://github.com/chbrown/overdrive Bash script to download overdrive books.
- https://bendodson.com/projects/itunes-artwork-finder Better artwork than the one supplied by overdrive. Put the downloaded 600x600bb.jpg in the same folder as the mp3s.
- User-agent switchers (to get around the OS X Catalina block)
    - https://chrome.google.com/webstore/detail/user-agent-switcher-for-c/djflhoibgkdhkhhcedjiklpkjnoahfmg?hl=en-US
    - https://addons.mozilla.org/en-US/firefox/addon/user-agent-switcher-revived/

## Usage

By default, all actions will be run (merge, add metadata tags, add chapters, add cover).
Specifying one or more specific action, will only run those.

Author and title will be pulled out of the mp3 tags if available. Override with options.

An `<author> - <title>.m4b` file will be left in the directory the command is run.

```
> overdrive-m4b --help
overdrive-m4b [options] <mp3-files>
    -g, --genre=GENRE
    -t, --title=TITLE
    -a, --author=AUTHOR
    -c, --codec=aac|libfdk_aac
    -v, --version
        --merge
        --tags
        --chapters
        --cover
```

```
overdrive-m4b --genre "Non Fiction" Some\ Audiobook/*.mp3
```

## License

Copyright © 2019 Pablo Flouret. [Apache 2.0](https://github.com/pflouret/overdrive-m4b/blob/master/LICENSE)

gha_language: Ruby


text:
For two rectangles, $$(x_1, y_1)-(x_2, y_2)$$ and $$(x_3, y_3)-(x_4, y_4)$$, not to intersect they must be aligned in one of the four ways:

- top to bottom: $$min(y_3, y_4) \ge max(y_1, y_2)$$,
- bottom to top: $$max(y_3, y_4) \le min(y_1, y_2)$$,
- left to right: $$min(x_3, x_4) \ge max(x_1, x_2)$$,
- right to left: $$max(x_3, x_4) \le min(x_1, x_2)$$.

Secondly, it's optimal to move the table only horizontally (for left-right alignment) or only vertically (for top-bottom alignment).

So we can firstly check if two tables fit together and, if they do, pick one of the four variants that's cheapest.

repository: akoprow/codeforces-editorials

repo_name: akoprow/codeforces-editorials


text:
# Light Sensing
This activity senses light in order to change the color and intensity of an LED. The brighter the light, the more intense it becomes and changes color from green to blue to red.

## This activity requires:
* LED: 1
* 100 ohm Resistors: 1
* Light Sensor: 1

## Layout
![Layout](https://github.com/unoacm/Arduino-Workshop/blob/master/activities/LightSensing/LightSensing.png)

repository: unoacm/Arduino-Workshop

repo_name: unoacm/Arduino-Workshop