text:
---
title: Netlify CMS and Cloudinary
date: '2019-06-08'
---

With [Netlify CMS](https://www.netlifycms.org/) bundled alongside [Netlify](https://www.netlify.com); the service is able to directly converse with your GitHub repo, making it an incredibly powerful way to create and manage content. This includes managing dependencies, environment variables, posts, pages, media - basically anything you can throw at it.

With my normal go-to website framework of choice; [Gatsby](https://www.gatsbyjs.org/), building a production-version of my projects is pretty seamless. In a recent project however, I realized I was frequently going over Netlify's 15 minute build-time limit; which caused deploy failures. Because this project had a variety of collection-types and contributors, the types of content (and media) were pretty diverse. After a bit of investigation, I determined the reason being over 100MB of media stored directly in the repo; which was being populated by Netlify CMS's built-in file uploader. This meant:

1. Pulling down the repo was a pretty resource-intensive task for the Netlify service to do; wasting time.
1. Transforming each image through Gatsby; while decently fast, also added build-time.
1. Netlify's default file system does not provide much validation or any optimization; so images were being uploaded at their full, often enormous, sizes.

With the help of [gatsby-transformer-sharp](https://www.gatsbyjs.org/packages/gatsby-transformer-sharp/) we weren't feeling the effects on the production-site, but it was clear this was an unsustainable way to manage media.

After [bringing a bit more sanity to Netlify CMS configuration](/articles/consolidating-netlify-cms/), it was clear I needed to look into other media providers that could work alongside Netlify CMS. Luckily, [Cloudinary](https://cloudinary.com/invites/lpov9zyyucivvxsnalc5/ixrpudbpiex8vwuwzdnp?kind=twitter&t=demo); a service I've used for several years, also has an [integration with Netlify CMS](https://www.netlifycms.org/docs/cloudinary/). Cloudinary not only provides cloud storage and CDN delivery for your media, but also has a powerful, on-demand transformation service.

Setting up Cloudinary was very straight-forward:

```js
import CMS from 'netlify-cms-app';
import cloudinary from 'netlify-cms-media-library-cloudinary';

CMS.registerMediaLibrary(cloudinary);

CMS.init({
  config: {
    load_config_file: false,
    backend: {
      name: 'github',
      repo: 'your/repo',
      branch: 'master',
      squash_merges: true, // @NOTE Beta feature
    },
    media_library: {
      name: 'cloudinary',
      config: {
        cloud_name: 'your_name',
        api_key: 'YOUR_API_KEY_HERE',
        default_transformations: [
          [
            {
              width: 2000,
              quality: 80,
              crop: 'limit',
            },
          ],
        ],
      },
    },
    media_folder: '/static/uploads',
    public_folder: '/uploads',
    collections: [
      ...
    ]
  },
});
```

I was also able to setup default transformations that would be applied to images chosen from the built-in interface within the Netlify CMS. To help with optimizations on upload, I also created an [upload preset](https://support.cloudinary.com/hc/en-us/articles/360004967272-Upload-Preset-Configuration); which keeps my usage of the Cloudinary service as small as possible. This also meant that less training was needed for contributors about optimizing images before upload; as well as the service fitting perfectly within the Netlify CMS interface.

After moving the existing media over, I was able to **decrease build-times from 15-20 minutes to about 4-5 minutes**. This not only solves the issue of intermittent build failures, but also allows content contributors to preview and publish their work faster.


text:
---
layout: post
title:  "Leetcode 153 : Find Minimum in rotated sorted array"
date:   2020-01-29 5:30:00 +0530
categories: leetcode-medium leetcode binarysearch array
---

Solution to [Find Minimum in Rotated Sorted Array][leetcode].

# Approach 1

In this approach you apply two rules during the search process.

Rule 1: If mid element is less than element at mid-1, that means mid element is the pivot element. If you think about it, the array being sorted and rotated, the pivot element is the only place a transition happens from high to low.

Rule 2: If mid element is greater than the last element in the array, then we need to search for smallest element in the second half.

While going through the code, have a look at the diagram in [this link][theoryofprogramming] to get a grasp on how we are picking the right partition during each iteration.

{% highlight java %}
class Solution {
    public int findMin(int[] nums) {
        int low=0, high=nums.length-1;

        if (nums.length == 1)
            return nums[0];

        if (nums.length == 2)
            return nums[0] < nums[1] ? nums[0] : nums[1];

        // handle [1,2,3,4,5] kind of inputs
        if (nums[low] < nums[high])
            return nums[low];

        while(low<=high) {
            int mid = low + (high - low)/2;
            // if current element is less than previous element
            // that means, current element is the pivot-element/min.
            if (nums[mid] < nums[mid-1]) {
              return nums[mid];
            } else if (nums[mid] > nums[high]) {
                // if current mid element is greater than last element
                // we need to search for smallest element in the second half.
                // Use the diagram in this link to understand why its so -
                // http://theoryofprogramming.com/2017/12/16/find-pivot-element-sorted-rotated-array/
                low = mid + 1;
            }
            else {
                high = mid;
            }
        }

        return -1;
    }
}
{% endhighlight %}

# Approach 2

The code for approach 2 is very simple and does not require additional checks for edge case handling. This solution was given by @JJH11 in the [leetcode discussion thread][simpler-solution].

Two key rules to help understand the solution.

Rule 1: When you sort and rotate an array, you create two parts of the array, one part will be sorted and another part will be unsorted. You can determine whether a part is sorted by comparing the first and last element of that part. For ex: if nums[low] > nums[mid], that means elements from low to mid are not sorted.

Rule 2: The min element will be in the unsorted part of the sorted and rotated array.

{% highlight java %}
    public int findMin(int[] nums) {
        int low = 0, high = nums.length-1;
        while(low < high){
            int mid = (low + high) / 2;
            //check if the first half is unsorted
            if(nums[low] > nums[mid]) {
                high = mid;
            //check if the second half is unsorted
            }else if(nums[mid] > nums[high]) {
                low = mid + 1;
            }else {
                //return the first item in the remaining list
                // since now both half of the items are sorted.
                return nums[low];
            }
        }

        return nums[low];
    }
{% endhighlight %}

[leetcode]: https://leetcode.com/problems/find-minimum-in-rotated-sorted-array/
[simpler-solution]: https://leetcode.com/problems/find-minimum-in-rotated-sorted-array/discuss/489830/very-simple-and-clean-java-solution-beats-100/439632
[theoryofprogramming]: http://theoryofprogramming.com/2017/12/16/find-pivot-element-sorted-rotated-array/

branch_name: refs/heads/master

extension: md

gha_language: HTML

license_type: permissive


text:
# Kava

Kava is a collateralized debt position system built on Cosmos.

## Background

Measured by encumbered collateral, debt issuance for the purpose of leveraged exposure has been the most succesful secondary financial usecase of cryptocurrencies. MakerDao, and the associated DeFi ecosystem on Ethereum, represent arguably the best example of product-market fit for any blockchain product or service that is not a base-layer protocol. While the number of users of these products is generally small, the potential for synthetic asset issuance (USD pegged stablecoins, or debt denominated in a stable basket of goods) that spans jurisdictions and runs largely autonomously is large.

Cosmos (Gaia) is a new blockchain protocol that uses Tendermint BFT for consensus and is designed with a hub-and-spoke model of cross-blockchain interoperabilty that emphasizes composability and self-sovereignty of application specific blockchains. We believe one of the primary financial usecases for the Cosmos ecosystem will be the the issuance of decentralized pegged assets like pegged Bitcoin (https://github.com/nomic-io/bitcoin-peg/blob/master/bitcoinPeg.md), as well as other pegged crpyto-native and traditional financial assets.

We are building a blockchain on the cosmos-sdk for the purpose of issuing Collateralized Debt Positions (CDPs) for assets in the cosmos ecosystem. The design of the CDP zone is inspired by Multi-Collateral Dai (https://github.com/makerdao/dss) and will allow users to lock their assets as collateral and draw a dollar-denominated debt off of their collateral. We believe this zone is a useful addition to the Cosmos ecosystem, providing a native way for users to gain leveraged exposure to a basket of assets in the cosmos ecosystem, as well as to create a collateral-backed stablecoin that is native to Cosmos.

## Design

There are 4 modules that make up the system:

* Pricefeed
* Auction
* CDP
* Liquidator

### [Pricefeed](../blockchain/x/pricefeed/doc.go)
The pricefeed module implements a simple price oracle where a group of white-listed oracles post prices for various assets in the system. The median price of all valid oracle prices is taken as the current price in the system. Adding and removing of assets and oracles is controlled by governance proposals.

#### Messages and Types

``` go
// Asset struct that represents an asset in the pricefeed
type Asset struct {
	AssetCode   string `json:"asset_code"`
	Description string `json:"description"`
}

// Oracle struct that documents which address an oracle is using
type Oracle struct {
	OracleAddress string `json:"oracle_address"`
}

// CurrentPrice struct that contains the metadata of a current price for a particular asset in the pricefeed module.
type CurrentPrice struct {
	AssetCode string  `json:"asset_code"`
	Price     sdk.Dec `json:"price"`
	Expiry    sdk.Int `json:"expiry"`
}

// PostedPrice struct represented a price for an asset posted by a specific oracle
type PostedPrice struct {
	AssetCode     string  `json:"asset_code"`
	OracleAddress string  `json:"oracle_address"`
	Price         sdk.Dec `json:"price"`
	Expiry        sdk.Int `json:"expiry"`
}

// MsgPostPrice struct representing a posted price message.
// Used by oracles to input prices to the pricefeed
type MsgPostPrice struct {
	From      sdk.AccAddress // client that sent in this address
	AssetCode string         // asset code used by exchanges/api
	Price     sdk.Dec        // price in decimal (max precision 18)
	Expiry    sdk.Int        // block height
}
```

### [Auction](../blockchain/x/auction/doc.go)

The Auction module implements three distinct auction types that control the supply of bad debt and surplus in the CDP system.

**Forward Auction** A standard auction where a seller takes increasing bids for an item. Each bid increments the price, as well as the duration of the auction. This auction type is used when there is a surplus of collected fees in the system. The surplus is converted to stablecoins and sold for governance tokens.

**Reverse Auction** An auction where a buyer solicits decreasing bids for a particular item or lot of items. This auction type is used when governance tokens are sold (minted) in exchange for stablecoins, to cover shortfalls after failed collateral auctions.

**Forward Reverse Auction** An auction where a buyer solicits increasing bids for a lot of goods, up to some ceiling. After the ceiling is reached, each bid lowers the amount of goods being sold for the ceiling  price. This type of auction is used when collateral is siezed from a risky CDP and sold for stablecoins to cover the debt.

#### Messages and Types

``` go
// Auction is an interface to several types of auction.
type Auction interface {
	GetID() ID
	SetID(ID)
	PlaceBid(currentBlockHeight endTime, bidder sdk.AccAddress, lot sdk.Coin, bid sdk.Coin) ([]bankOutput, []bankInput, sdk.Error)
	GetEndTime() endTime // auctions close at the end of the block with blockheight EndTime (ie bids placed in that block are valid)
	GetPayout() bankInput
	String() string
}

// BaseAuction type shared by all Auctions
type BaseAuction struct {
	ID         ID
	Initiator  sdk.AccAddress // Person who starts the auction. Giving away Lot (aka seller in a forward auction)
	Lot        sdk.Coin       // Amount of coins up being given by initiator (FA - amount for sale by seller, RA - cost of good by buyer (bid))
	Bidder     sdk.AccAddress // Person who bids in the auction. Receiver of Lot. (aka buyer in forward auction, seller in RA)
	Bid        sdk.Coin       // Amount of coins being given by the bidder (FA - bid, RA - amount being sold)
	EndTime    endTime        // Block height at which the auction closes. It closes at the end of this block
	MaxEndTime endTime        // Maximum closing time. Auctions can close before this but never after.
}

type ID uint64
type endTime int64
// ForwardAuction type for forward auctions
type ForwardAuction struct {
	BaseAuction
}
// ReverseAuction type for reverse auctions
type ReverseAuction struct {
	BaseAuction
}
// ForwardReverseAuction type for forward reverse auction
type ForwardReverseAuction struct {
	BaseAuction
	MaxBid      sdk.Coin
	OtherPerson sdk.AccAddress
}

// MsgPlaceBid is the message type used to place a bid on any type of auction.
type MsgPlaceBid struct {
	AuctionID ID
	Bidder    sdk.AccAddress // This can be a buyer (who increments bid), or a seller (who decrements lot) TODO rename to be clearer?
	Bid       sdk.Coin
	Lot       sdk.Coin
}
```

### [CDP](../blockchain/x/cdp/doc.go)

The CDP module is a factory for creating CDPs and storing the global state of the debt system. It allows users to create, modify, and close CDPs for any collateral type in the pricefeed module. It also sets the global parameters of the system, which can be altered by governance proposals. These parameters include the global debt limit (the total amount of stablecoins that can be in circulation), the debt limit for each collateral type, and the collateralization ratio for each collateral type.

#### Messages and Types

``` go
// CDP is the state of a single Collateralized Debt Position.
type CDP struct {
	//ID             []byte                                    // removing IDs for now to make things simpler
	Owner            sdk.AccAddress `json:"owner"`             // Account that authorizes changes to the CDP
	CollateralDenom  string         `json:"collateral_denom"`  // Type of collateral stored in this CDP
	CollateralAmount sdk.Int        `json:"collateral_amount"` // Amount of collateral stored in this CDP
	Debt             sdk.Int        `json:"debt"`              // Amount of stable coin drawn from this CDP
}

// CollateralState stores global information tied to a particular collateral type.
type CollateralState struct {
	Denom     string  // Type of collateral
	TotalDebt sdk.Int // total debt collateralized by a this coin type
	//AccumulatedFees sdk.Int // Ignoring fees for now
}

// MsgCreateOrModifyCDP creates, adds/removes collateral/stable coin from a cdp
type MsgCreateOrModifyCDP struct {
	Sender           sdk.AccAddress
	CollateralDenom  string
	CollateralChange sdk.Int
	DebtChange       sdk.Int
}
```
### [Liquidator](../blockchain/x/liquidator/doc.go)

The liquidator module tracks the status of CDPs based on prices in the pricefeed module and is responsible for siezing collateral from CDPs whose collateralization ratio is below the threshold set for that collateral type and sending it to the auction module.

#### Messages and Types

``` go
type SeizedDebt struct {
	Total         sdk.Int // Total debt seized from CDPs.
	SentToAuction sdk.Int // Portion of seized debt that has had a (reverse) auction was started for it.
	// SentToAuction should always be < Total
}

type MsgSeizeAndStartCollateralAuction struct {
	Sender          sdk.AccAddress // needed to pay the tx fees
	CdpOwner        sdk.AccAddress
	CollateralDenom string
}

type MsgStartDebtAuction struct {
	Sender sdk.AccAddress // needed to pay the tx fees
}
```

### Kava - Governance and Staking Token

The system is secured by Kava, a staking and governance token. Staked Kava tokens receive inflationary block rewards and are eligible to create and vote on governance proposals. Fees for transactions and for closing and liquidating CDPs are also collected in Kava tokens. Fees associated with CDPs are auctioned as part of the `auction` module.

### Liquidation and Recolateralization
In the event of a CDP falling below the required collateral ratio, that CDP will be siezed by the liquidator module. When a `lot` of collateral has been siezed due to liquidations, that collateral is auctioned by the auction module for stable tokens using a forward reverse auction.

In the event collateral auctions fail to raise the requisite amount of stable tokens, Kava tokens are auctioned by the auction module for stable tokens using a reverse auction until the global collateral ratio is reached. In this way, the Kava token serves as a lender of last resort in times of under-collateralization.

repository: wepobid/kava-devnet

repo_name: wepobid/kava-devnet


text:
# API

## esformatter.format(str[, opts]):String

`format()` method receives a string containing the code that you would like to
format and the configuration options that you would like to use and returns
a string with the result.

```js
var esformatter = require('esformatter');
var fs = require('fs');
var codeStr = fs.readFileSync('path/to/js/file.js').toString();

// for a list of available options check "lib/preset/default.js"
var options = {
  indent: {
    value: '  '
  },
  lineBreak: {
    before: {
      // at least one line break before BlockStatement
      BlockStatement: '>=1',
      // only one line break before DoWhileStatementOpeningBrace
      DoWhileStatementOpeningBrace: 1,
    // ...
    }
  },
  whiteSpace: {
    // ...
  }
};

// return a string with the formatted code
var formattedCode = esformatter.format(codeStr, options);
```

### Custom Parser

Since v0.7 we started to use [espree](https://github.com/eslint/espree) because
it supports ES6 and JSX syntax and produces an AST that is similar to
[esprima](http://esprima.org). On v0.9 we replaced the parser with
[babylon](https://www.npmjs.com/package/babylon) and
[acorn-to-esprima](https://www.npmjs.com/package/acorn-to-esprima). To override
the parser you can do:

```js
var esprima = require('esprima');
// function used by `rocambole` to parse the program
esformatter.format.parseFn = esprima.parse;
// the `this` value inside the `parseFn`
esformatter.format.parseContext = esprima;
// options passed to the parser
esformatter.format.parseOptions = {
  // we need range, comment and tokens info to build the rocambole AST
  range: true,
  tokens: true,
  comment: true
};
```

## esformatter.transform(ast[, opts]):AST

or you can use the `transform()` method to manipulate an AST in place (allows
pipping other tools that manipulates the AST). - so far only supports
[rocambole](https://github.com/millermedeiros/rocambole) generated ASTs, but we
will work to fix this limitation in the future (see [issue #86](https://github.com/millermedeiros/esformatter/issues/86)).

```js
var inputAST = rocambole.parse('var foo=123;');
// you can also pass the formatting options as second argument like the
// `format` method
var outputAST = esformatter.transform(inputAST);
assert(outputAST === inputAST, 'edits AST in place');
assert(outputAST.toString() === 'var foo = 123;', 'formats input');
```

## esformatter.diff

esformatter is also able to check if files are formatted properly and return
pretty diffs.

### esformatter.diff.chars(str[, opts, fileName]):String

Gets a colored char diff if file is not formatted properly. Otherwise it
returns an empty string.

```js
var diff = esformatter.diff.chars(code);
console.log(diff);
```

### esformatter.diff.unified(str[, opts, fileName]):String

Gets a colored unified diff if file is not formatted properly. Otherwise it
returns an empty string.

```js
var diff = esformatter.diff.unified(code);
console.log(diff);
```

### esformatter.diff.unifiedNoColors(str[, opts, fileName]):String

Gets an unified diff if file is not formatted properly. Otherwise it returns an
empty string.

```js
var diff = esformatter.diff.unifiedNoColors(code);
console.log(diff);
```

## esformatter.rc([filePath], [customOptions]):Object

Used by task runners and/or plugin authors to retrieve the configuration stored
on `.esformatter` and `package.json` files relative to the `filePath`, `cwd` or
global config file (`~/.esformatter`) if it can't find any config file until
the root path.

You can also pass an object with `customOptions` to override the default
options.

`rc` will merge the options from multiple [config files](./config.md).

```js
// will start search from the "foo/bar" directory
var baseConfig = esformatter.rc('foo/bar/baz.js');
// will start the search from cwd
var otherConfig = esformatter.rc();
// merge some custom options to the user settings
var override = esformatter.rc({
  indent: { value: '\t' }
});
```

## esformatter.register(plugin)

Register a [plugin](./plugins.md) module.

```js
var plugin = {
  nodeAfter: function(node) {
    // called once for each node, after the esformatter manipulation
  }
};
esformatter.register(plugin);
```

## esformatter.unregister(plugin)

Remove [plugin](./plugins.md) from the execution queue.

```js
esformatter.unregister(pluginObject);
```

## esformatter.unregisterAll()

Remove all the registered [plugins](./plugins.md) from the execution queue;
useful in case you want to edit multiple files using different plugins each
time.

license: MIT

repository: luozhihua/sublime-vue-formatter

gha_language: JavaScript

repo_name: luozhihua/sublime-vue-formatter


text:
# Adding a security policy with Istio
Note that in our setting, any microservice can access any other microservice. If any of the microservices is compromised, it can attack all the other microservices.
In this learning module we will add a [security policy](https://istio.io/docs/reference/config/istio.mixer.v1.config.html) that states that only _reviews_ microservice can access _ratings_ microservice.

1. Let's see that without a security policy, our _sleep_ microservice can call the _ratings_ microservice.
   ```bash
   kubectl exec -it $(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}') -- curl http://ratings:9080/ratings/7
   ```

   We will get `{"id":7,"ratings":{"Reviewer1":5,"Reviewer2":4}}` as an output

2. Let's define a security policy (a whitelist) that will allow only the _reviews_ microservice to access the _ratings_ microservice:
   ```bash
   istioctl create -f whitelist-for-ratings.yaml
   ```

3. Now let's see that the _sleep_ microservice cannot access the _ratings_ microservice, as expected:
   ```bash
   kubectl exec -it $(kubectl get pod -l app=sleep -o jsonpath='{.items[0].metadata.name}') -- curl http://ratings:9080/ratings/7
   ```

   This time we will get the following error: `NOT_FOUND:whitelist-for-ratings.listchecker.default:sleep is not whitelisted`, as expected.

4. Access the webpage of the application and check that it works as expected. It will mean that the _reviews_ microservice can still access the _ratings_ microservice, as expected.


text:
# LSL-LiveAmp
LSL connector for the LiveAmp device from Brain Products.

To download, please click on the 'Latest release' link to the right for the latest versions.

Please note that you may need to install the Microsoft C++ redistributable packages for Visual Studio 2012 ([here](https://my.visualstudio.com/Downloads?pid=1452)) in order to run the executables.

# Getting Started
If you are new to using LSL, you might want to read the [Quick Start guide](https://labstreaminglayer.readthedocs.io/info/getting_started.html) on the LabStreamingLayer main repository.

For measuring impedances, ensuring good signal quality, and troubleshooting basic amplifier functionality, it is always recommended to use [BrainVision Recorder](https://www.brainproducts.com/downloads.php?kid=2) and to consult the amplifier manual.

You can also find a useful (free) LSL viewer on the Brian Products website: [BrainVision LSL Viewer](https://www.brainproducts.com/downloads.php?kid=40&tab=3).

# Usage

Make sure that you have correctly installed the drivers for your amplifier, and that the amplifier dongle (or dongles in the case of a 64 channel system) is plugged in. Alternatively, with a <=32 channel device, you may be able to connect to a LiveAmp via your PC's built in bluetooth device---which must be enabled.  Make sure that the device is turned on, and that batteries are charged. It is always good to read the manual before operation.

  * Start the LiveAmp Connector app. You should see a window like the following.
> ![liveamp.png](liveamp.png)

## Device Settings

### Device Number

If you know the serial number of the amplifier you want to connect with, you may enter it manually in the 'Device Number' field. Otherwise, you can scan for amplifiers using the 'Scan' button at the bottom of the GUI. After scanning, the 'Available Devices' combo box will be populated with all available devices. The 'Device Number' field will automatically be filled with the number of the first device found. Whichever device is referred to here will be the device that is connected with at the 'Link' action.

It is highly recommended, when connecting with more than one device, to turn one device on at a time and connect before attempting to connect with another device. The 'Scan' action will not find any device that is alread connected by the 'Link' action.

### EEG/Aux Channels

You can adjust the number of EEG, and AUX channels that the device enables during Link action. Note that if the 'Overwrite on Channel Change' box is checked, changing these values will change the labels in the Channel Labels text box on the left side of the GUI. See the section on Channel Labels below for more information.

### Enable ACC Sensors

Check this box if you wish to include the LiveAmp accelerometer data in your data stream.

### Sample Counter in EEG

When this box is checked, the last channel in the device stream will be a number that increases by 1 at every sample.

### Chunk Size

For most EEG experiments you can ignore the Chunk Size setting, but if you are developing a latency-critical real-time application (e.g., a P300 speller BCI), you can lower this setting to reduce the latency of your system.

### Sampling Rate

The LiveAmp device has 3 available sampling rates: 250, 500, and 1000Hz. Note that for 64 channel systems, it is not recommended to use the 1000Hz sampling rate.

## LSL Trigger Output Style

These check boxes determine the way that this app handles device triggers in LSL.

Note that it is possible to enable neither, one of, or both trigger output styles simultaneously. They are not mutually exclusive.

### Unsampled String Markers

If 'Unsampled String Markers' is checked, the app will create a Marker stream on 'Link' that will forward the triggers received at the 1-bit trigger input on the hardware device. This stream will have the name of 'LiveAmpSN-xxxxxx-xxxx-DeviceTrigger' and its sampling rate is 0, i.e. it is a Marker stream

If the STE box is connected, there will be two Marker streams created. One for the 1-bit amplifier trigger and one for the STE box trigger input. The STE Marker stream will have the name 'LiveAmpSN-xxxxxx-xxxx-STETriggerIn'.

If the STE box is connected and the STE Out Mode is set to 'Sync' there will be a third Marker outlet that corresponds to the hardware triggers sent from the trigger out of the STE box. The name of this Marker stream will be 'LiveAmpSN-xxxxxx-xxxx-STESync'. Note that this is not recommended for 'Unsampled String Markers' as it creates a large number of string markers (one per sample) which is not the intended use of LSL Marker outlets.

### EEG Channel

If this box is checked, extra channels will be added to the EEG/Bipolar/AUX/ACC stream corresponding to the requested trigger outputs. Rather than unsampled markers, these channels will output -1 if no trigger is available, else the value corresponding to the triggers in; and, in the case of the STE box in 'Sync' mode, the sync stream presented at the DSub output of the STE box.

### Further Information

Please see the file [explanation_of_trigger_marker_types.pdf]( https://github.com/brain-products/LSL-LiveAmp/blob/master/explanation_of_trigger_marker_types.pdf) for more details.

## STE Out Mode

This settings group controls the setup of the STE box's trigger outputs and how the LSL streams will correspondingly behave.

In 'Default' mode, nothing comes out of the STE box's output port and there is no corresponding LSL stream. In 'Mirror' mode, whatever is at the STE trigger input will be forwarded (in hardware) to the STE box's trigger output port. Since one has the option of recording triggers into the STE box, there is no reason to create an LSL Marker stream or extra EEG channel corresponding to these trigger events. In 'Sync' mode, a TTL pulse goes out of pin 1 of the STE box's output port. The sync frequency is adjustable and a corresponding LSL Marker stream and/or extra EEG channel will be created depending on the chosen 'LSL Trigger Output Style' settings.

### STE/Triggers and LiveAmp64

Please note that in the case of LiveAmp 64, Aux channels can be connected via STE through either the Master (channels 1-32) or Slave (channels 33-64) but triggers will only be read from the STE box connected to the Master device. This is also true for device triggers (i.e. mini headphone jack triggers). If 2 STE boxes are connected, only the Aux channels connected to the Master will be read.

 ## Link

 When pressed, the Link button will attempt to connect to the device specified in the 'Device Number' field. This may take a few moments due to Bluetooth handshaking. When complete, the button text will change to 'Unlink' and all other GUI widgets will be disabled. An error message will pop up if no devices are available.

 When the Connector is linked to the LiveAmp, LSL streams will be created according to the settings set in the GUI. Please note that settings can be saved in a configuration file (see below) for ease of repetition.

## Scan For Devices

When 'Scan' is pressed, the app will search for available LiveAmps. When 1 or more LiveAmps is found, the Serial Numbers of these devices will populate the 'Available Devices' combo box. The first device found will automatically be placed in the 'Device Number' field. When devices are available in the 'Available Devices' box, the user may choose from the available devices in the combo box by interacting with the combo box itself. The chosen device will be forwarded to the 'Device Number' field. If the selected device is unavailable at 'Link', the app will notify the user with an error message. The enumerated devices will also report the type of LiveAmp found (8, 16, 32, or 64 channel).

The LiveAmp device has a simulator mode which can be activated with the 'Use Simulator' checkbox.

## Configuration file

The configuration settings can be saved to a .cfg file (see File / Save Configuration) and subsequently loaded from such a file (via File / Load Configuration). Importantly, the program can be started with a command-line argument of the form "LiveAmp.exe -c myconfig.cfg", which allows to load the config automatically at start-up. The recommended procedure to use the app in experiments is to make a shortcut on the experimenter's desktop which points to a previously saved configuration customized to the study being recorded to minimize the chance of operator error.

## Channel Labels

If the `Overwrite Channel Labels` box is checked, the channel label field will automatically update when you change the number of channels. The chosen channel label is simply an integer number corresponding to the channel number. You can change the channel labels by editing the `Channel Labels` text field directly.

The latest version of the LiveAmp Connector uses [INI](https://en.wikipedia.org/wiki/INI_file) style configuration files (see above) to store preferred settings between sessions. Easier and less error prone than adjusting channel labels in the App's GUI, is to set the channel labels by editing a config file in a text editor and then loading the updated config file. To do so, in the chosen config file simply create a [section](https://en.wikipedia.org/wiki/INI_file#Sections) called `channels` then create a [key](https://en.wikipedia.org/wiki/INI_file#Keys_(properties)) called `labels` with the corresponding labels for each channel separated by commas. For example, a 32 channel 10-20 layout may look like this:

`[channels]`
`labels=Fp1, Fp2, F7, F3, Fz, F4, F8, FC5, FC1, FC2, FC6, T7, C3, Cz, C4, T8, TP9, CP5, CP1, CP2, CP6, TP10, P7, P3, Pz, P4, P8, PO9, O1, Oz, O2, PO10`

The LSL channel meta-data corresponds to the conventions of the XDF file format. These are described [here](https://github.com/sccn/xdf/wiki/EEG-Meta-Data).

## Loading Channel Label Files

Python users may automatically insert channel labels from a .bvef file into an LSL config file. To do so, please use the free utility [BVEF2lslconfig](https://github.com/brain-products/BVEF2lslconfig). You can find many electrode position files with channel labels for common cap configurations on the Brain Products website [here](https://www.brainproducts.com/downloads.php?kid=44).

repository: brain-products/LSL-LiveAmp

gha_license_id: MIT

repo_name: brain-products/LSL-LiveAmp


text:
# RND Environment
Research and development (RND) environment.
I'm using those dockers on remote desktop computer with GPU

## Features
- run scientific docker on remote host
- preserve datasets to `/var/datasets`
  and models to `/var/models`
- I'm using dockerfile [floydhub/pytorch:1.0.0-gpu.cuda9cudnn7-py3.37](https://docs.floydhub.com/guides/pytorch/)
  which has many scientific and deep learning tools
  (`pytorch`, `scikit-learn`, `tensorflow` and etc).
- jupyter on `http://{server-ip}:8888/`
- tensorBoard on `http://{server-ip}:6006/`

  [More details about it](https://docs.floydhub.com/guides/pytorch/)

repository: hyzhak/rnd-environment

gha_language: Dockerfile

repo_name: hyzhak/rnd-environment


text:
# [ES6: Use Destructuring Assignment to Assign Variables from Arrays](https://learn.freecodecamp.org/javascript-algorithms-and-data-structures/es6/use-destructuring-assignment-to-assign-variables-from-arrays)

ES6 makes destructuring arrays as easy as destructuring objects.

One key difference between the spread operator and array destructuring is that the spread operator unpacks all contents of an array into a comma-separated list. Consequently, you cannot pick or choose which elements you want to assign to variables.

Destructuring an array lets us do exactly that:

```js
const [a, b] = [1, 2, 3, 4, 5, 6];
console.log(a, b); // 1, 2
```

The variable `a` is assigned the first value of the array, and `b` is assigned the second value of the array.

We can also access the value at any index in an array with destructuring by using commas to reach the desired index:

```js
const [a, b,,, c] = [1, 2, 3, 4, 5, 6];
console.log(a, b, c); // 1, 2, 5
```

---

Use destructuring assignment to swap the values of `a` and `b` so that `a` receives the value stored in `b`, and `b` receives the value stored in `a`.

## Setup
```js
let a = 8, b = 6;
(() => {
  "use strict";
  // change code below this line

  // change code above this line
})();
console.log(a); // should be 6
console.log(b); // should be 8
```

## Solution
```js
let a = 8, b = 6;
(() => {
  "use strict";

  [b, a] = [a, b];

})();
console.log(a); // 6
console.log(b); // 8
```

repository: johnfelipe/progress

repo_name: johnfelipe/progress


text:
# Versions

- [`1.11-1` (_Dockerfile_)](https://github.com/mageinferno/docker-magento2-nginx/tree/1.11-1/Dockerfile)

# Description

This image is built from [`nginx`](https://hub.docker.com/_/nginx/) and contains the default webserver configuration for Magento 2.

# What's in this image?

This image installs the following:

- `nginx`

# Variables

The following environment variables are used for Nginx configuration:

- `PHP_HOST`: (default: `phpfpm`) The hostname of the PHP container.
- `PHP_PORT`: (default: `9000`) The port of the PHP container.
- `APP_MAGE_MODE`: (default: `default`) Set the appropriate MAGE_MODE.

# Docker Compose

Please see [https://github.com/mageinferno/magento2-docker-compose](https://github.com/mageinferno/magento2-docker-compose) for more detailed instructions and an example development environment using Docker Compose.

gha_language: Shell


text:
---
title:  System Requirements
summary: "The Superalgos Suite is a robust, cross-platform, browser-based system. It's capacity to run indefinite numbers of processes means that your hardware will set the limits of what you may or may not do with it."
sidebar: suite_sidebar
permalink: suite-system-requirements.html
---

## Cross-Platform

Superalgos is a web app, therefore, it is cross-platform. The dev team is testing mostly on Windows systems, but users are running the system on Mac OS and Linux systems as well.

## Chrome is the Only Tested Browser

Chrome is highly recommended so that you have a similar environment as the dev team in case you need help. We are not testing on any other browsers, and it is a well-known fact that browsers behave differently.

## Processing Power

One of the first and foremost design goals is to develop the most powerful trading automation and data processing system. There is no intention to limit or cut functionality short in an attempt to cope with less powerful hardware. It is a fact that your hardware will set the limits as of what you may or may not do with the system.

The system's processing capacity is based on running independent, specialized processes. No single process is as intensive as to require any special hardware, and all processes may run on basic—even outdated—laptop computers. That means that, regardless of the limitations of your current hardware, you should be able to use all of the features in the system.

What will vary depending on your hardware is the capacity to run a determinate number of processes simultaneoulsy. That is where you will find the limits of your hardware. In other words, you will find your system starts getting slow when it's doing many things at the same time. How many depends on your hardware.

The app has very little requirements for active, hands-on use, that is, for creating strategies, running backtests, or interacting with light-weight charts, for instance. We believe any cheap laptop should cope with such use.

Processing requirements increase in a roughly linear fashion with every process added to the mix. For instance processes that fetch data from exchanges and calculate indicators.

These are a few examples of use cases demanding significant processing power:

* Monitoring multiple markets in multiple exchanges, using multiple indicators on each chart, at the same time.

* Backtesting multiple strategies in multiple exchanges or multiple periods, at the same time.

* Running multiple live-trading sessions which depend on multiple indicators, at the same time.

## RAM Memory

The system is not RAM-intensive. One dedicated gigabyte should be enough for intensive use, and two gigabytes may be required for extreme charting. Those are ball-park, non-scientific figures.

## Graphics Processing Unit

The system benefits from a powerful GPU, as all of the visual experience Superalgos enables derives from the implementation of an HTML5 canvas animation. The more powerful your GPU, the more data you will be able to visualize at the same time, and the more fluid the visual experience becomes.

## Console/Command Line

Processes started from the system log their activity on the default console application, or the console used to fire up the app. Windows Command Prompt is particularly bad. It is recommended to install and use a decent application, such as Console Emulator Cmder. This will save you time and hassle in the long run.

## Deploying a Linux VPS to Trade Live

You may want to read an article about Trading Live from a Cheap Linux VM.

repository: Alex-Mishin/Superalgos

repo_name: Alex-Mishin/Superalgos


text:
## TetRS
---

A Tetris clone written in Rust.

### Why another Tetris clone?

The idea here is to create a "full featured" Tetris clone. Abstractions exist within the codebase that pave the way for future updates to extend the core mechanics.

## Building and running

Via cargo:

```
cargo run
```

### How to play:

Controls are:

* Arrow keys for movement.
* `Z` for counter-clockwise Tetromino rotation.
* `X` for clockwise Tetromino rotation.
* `Space` to drop a Tetromino immediately.
* `Escape` pauses the game.

### Shadow

The game supports a "Shadow" toggle to preview where a Tetromino will drop. You can toggle this via the `--shadow-enabled` flag:

```
cargo run -- --shadow-enabled
```

![tetrs-shadow](https://cloud.githubusercontent.com/assets/2499070/20560310/c501ceb8-b1cc-11e6-8dbc-056f7e489592.gif)

repository: simon-whitehead/tetrs

repo_name: simon-whitehead/tetrs


text:
---
title: "Installation & Usage"
description: "How to install and use Emulsify Gatsby Starter Drupal edition"
publishToStyleGuide: true
---

# Installation and Usage

#### Installation

`yarn` or `npm install`

#### Usage

Develop using Storybook

`yarn build`

View Design Guide locally

`yarn develop-gatsby`

repository: emulsify-ds/westernarts

path: /web/themes/custom/western_arts/styleguide/0__Getting started/1__Installation & Usage.md

filename: 1__Installation & Usage.md

repo_name: emulsify-ds/westernarts


text:
# Trustpilot API

This is an early - work in progress - version for the Trustpilot API.

At the moment, it's only the **Business Units** service that has been fully implemented.
And only the endpoints which do not require an OAuth token. The OAuth stuff will be implemented later.

### Supported services

| Name | Supported |
| :--- | :---: |
| Business Units | ✅ |
| Categories | ❌ |
| Consumer | ❌ |
| Consumer profile | ❌ |
| Invitation | ❌ |
| Private products | ❌ |
| Product reviews | ❌ |
| Resources | ❌ |
| Service reviews | ❌ |

repository: rugaard/trustpilot

repo_name: rugaard/trustpilot


text:
# Image Server
---
 * An Image Server Where You Just Upload Files And It Stores it into the server.

## To Do
---
 * A More Explainatory Readme
 * An Endpoint To Retrieve The Uploaded Files

## Author

**DaTerminators** © [Piyush Bhangale](https://github.com/ionadev), Released under the [MIT](https://github.com/DaTerminators/image-server/blob/master/LICENSE) License.<br>
Authored and maintained by Pitu.

> GitHub [@ionadev](https://github.com/ionadev)

repository: DaTerminators/file-server

repo_name: DaTerminators/file-server


text:
---
title: "Business Support"
date: 2020-11-13 14:54:00
---

## Support range

Provide original commercial support for companies that use Apache APISIX in the development phase and production environment.

## Service Content

Service support includes architecture review, code review, troubleshooting, diagnosis, suggestions, upgrades and security patches to ensure the normal operation of Apache APISIX.
If you have modified the core of Apache APISIX, or have custom plug-ins, it is recommended to purchase the advanced version so that we can understand these changes and locate and resolve faults faster.
The following table is the specific content:

|                                          |                       |                  |                                      |
| :--------------------------------------- | :-------------------: | :--------------: | :----------------------------------: |
|                                          |     Basic Edition     | Standard Edition |           Premium version            |
| Recommended mode                         | Non-critical business |   Key business   | Key business
Close communication |
| Troubleshooting                          |           ✓           |        ✓         |                  ✓                   |
| Security patch                           |           ✓           |        ✓         |                  ✓                   |
| new version update                       |           ✓           |        ✓         |                  ✓                   |
| Performance tuning                       |                       |        ✓         |                  ✓                   |
| Architecture review                      |                       |                  |                  ✓                   |
| Code review                              |                       |                  |                  ✓                   |
| Support method                           |   Email
WeChat    | Email
WeChat |      Email
WeChat
Phone      |
| Support time                             |        24 X 7         |      24 X 7      |                24 X 7                |
| Corresponding time SLA                   |         8 hrs         |     60 mins      |               30 mins                |
| Technical Support Contact                |           1           |        2         |                  2                   |
| Technical Support Manager                |                       |                  |                  ✓                   |
| Inspection                               |                       |                  |                  ✓                   |
| Free additional development support time |         1 hrs         |      2 hrs       |                4 hrs                 |

## Toll

The subscription fee is charged quarterly.
[Contact us for a quote](https://www.apiseven.com/support-for-business-form/)

repository: guoqqqi/website

repo_name: guoqqqi/website


text:
# uwmark_lamp_cookbook

UW-Madison University Makreting's LAMP Chef cookbook for configuring development environments for PHP/Wordpress projects.

## Supported Platforms

Developed for Centor 6.5

## Usage

### uwmark_lamp_cookbook::default

Include `uwmark_lamp_cookbook` in your node's `run_list`:

```json
{
  "run_list": [
    "recipe[uwmark_lamp_cookbook::default]"
  ]
}
```
The default recipe runs the other recipes:

* apache2
* mysql
* php
* cleanup
* vhost

## License and Authors

Author:: Nick Weaver<EMAIL_ADDRESS>


text:
# REST API for mds #

## API usage ##

The current REST API offers a service for CRUD operations on content objects, an authorization service, a curation service to invoke tasks on objects,
a service to manage registry contents, and a read-only service for respository characterization.
Services accept and return either XML or JSON. API URLs appear under the context 'webapi'.
Thus a URL to retrieve a bitstream might appear as:

    http://mdsrepo.mit.edu/webapi/content/1721.1/77095.5/media/my-file.pdf

### Content API ###

The content API (all URLs of which appear under the 'content' path) models DSpaceObjects as
resources that may contain sets of sub-resources. To obtain a representation of a resource (which here means a community,
collection, item or bitstream), one requests it via a persistent identifier (think handle):

    GET content/1721.1/2

The returned representation will contain one or more URIs for any sub-resources. For example, if the
above were an identifier for a collection, the representation would include the URI:

    content/1721.1/2/items

which when dereferenced would return a list of item URIs. The list below summarizes the sub-resources
available for each content type:

    community:  collections, subcommunities, mdsets, mdviews
    collection: items, mdsets, mdviews
    item:       filters, mdsets, mdviews
    bitstream:  mdsets, mdviews

A few explanations: first, _mdsets_ refer to metadata sets, i.e. collections of metadata that describe the
DSpace object. The sets currently defined correspond to the schemas configured in the metadata registry. Thus,
to request the Dublin Core metadata set for our resource, we would use the URI:

    content/1721.1/3/mdset/dc

Since mds has 'metadata for all' (i.e. all DSO types), one can request metadata on any object, not just items.
Closely related to metadata sets are _mdviews_, which are collections/projections of metadata values, profiled for particular purposes.
The service implementation may offer an arbitrary number of views, which may draw metadata from any number of sets. Metadata views,
unlike sets, are _read only_ resources. An example for an item might be:

    content/1721.1/3/mdview/public

Finally, _filters_ amount to a mechanism to expose the functionality of DSpace bundles, since they are used to
organize or group bitstreams in a item. An item resource will include a URI like:

     content/1721.1/3/filters

which will return a list of all the filters (bundles) defined on the item. One could then use the filter to restrict
a sub-resource list as follows:

    content/1721.1/3/filter/ORIGINAL

returning a list of bitstream URIs in the ORIGINAL bundle.

#### Content CRUD Operations ####

The previous section described the resource _access_ endpoints (obtained via HTTP GET methods). Modifying operations are defined below.
Creating new content resources is an operation typically performed on the _logical parent_ resource. For example, to create a collection that belongs to
the community 1721.1/1, one would POST a request to the resource URI:

    content/1721.1/1/collections

That is, the above URI is the resource name of the communities' _collection set_, not the community resource itself. Similarly,
adding a subcommunity is a POST to:

    content/1721.1/1/subcommunities

The only 'exception' to this rule is for top-level communities (which lack any parent resource). To add (create) a top-level community. POST to:

    content

Removing resources is quite simple: use the DELETE HTTP method on the resource URI:

    content/1721.1/1

would remove the community with handle '1721.1/1'. Updating metadata follows a slightly different pattern, since here the whole metadata set is the resource, not
individual values. Thus, one uses the recommended REST verb 'PUT' to the relevant metadata URI:

    content/1721.1/2/mdset/dc

In this case, the request body of the PUT would replace all the dc values in the object (other metadata would be unchanged).

#### Other Content Notes ####

* The URI 'content' (no other path components) is used as a discovery mechanism: it returns a list of the 'top-level' communities,
through which all other content can be found.

* Bitstream persistent IDs are simply the handle appended with the sequence number. So if 1721.1/4 is an item, 1721.1/4.1
is the first bitstream.

* To obtain the bitstream media streams, one uses the URL pattern:

    content/1721.1/4.1/media/mydoc.pdf

where 'mydoc.pdf' is the bitstream name. This is not strictly required, but the file suffix can act as a rendering hint to
certain clients (such as browsers).

### Curation API ###

The curation API is used to discover what tasks or other curation resources are installed on the server, and then invoke them
against content resources (or selectors). All API URLs appear under the 'curation' path.

To obtain a list of all task groups:

    GET curation/taskgroups

This resource lists URIs of all the groups. To obtain a list of tasks in a named group:

    curation/taskgroup/general

The same pattern is used for curation 'selectors':

     curation/selectorgroups
     curation/selectorgroup/general

To perform a curation on a content object, POST to the URI:

    curation/content/1721.1/1

or to curate a selection:

    curation/set/selector

The POST request entity body must contain the specifics of the curation 'order' e.g.:

    <curationOrder>
      <taskName>transmitAIP</taskName>
      <jrnFilter>a</jrnFilter>
      <txScope>object</txScope>
    </curationOrder>

### Authorization API ###

The authorization API exposes the primary objects used to assign and manage rights on content, viz. EPersons, Groups, and Resource Policies.
All API endpoints appear under the 'authz' path. To obtain a representation of an EPerson, Group or Policy one would request via GET:

    authz/eperson/123
    authz/group/234
    authz/policy/456

where '123' etc is the system id assigned to the object. For EPersons and Groups only, where there is a unique attribute (like email address for EPerson, or name for Group), it may be used instead of the system id. Thus the URI:

<EMAIL_ADDRESS>
would return a representation of the EPerson with the specified email if it existed.

The same URIs would be used (using ids only) with a DELETE method to delete the object, or a PUT method to update it.
The representation of a group resource  will include sub-resource URIs for its EPerson and Group members:

    authz/group/234/members
    authz/group/234/groupmembers

which when dereferenced will return entity reference lists of the EPeople and groups belonging to the group.
To create a new resource of any of these types, POST the request to the appropriate URI:

    authz/epeople
    authz/groups
    authz/policies

One special case arises for group membership lists. Since the lists can be extensive, the use of PUTs on a group resource to update it could be cumbersome, since to
adhere to the REST contract, the request body would have to include the entire membership list (and group membership list) in order to change in a single member.
Instead, the API for groups exposes what we can call _link resources_. For example:

    authz/group/234/eperson/123

This resource represents the membership of eperson 123 in group 234. Using a link resource, we can add a member to a group simply with a PUT request to the
desired link resource URI (request body ignored). To remove a member from a group, DELETE the link resource. Note that neither operation has any direct effect on the underlying components: i.e. the PUT does not create a group or an eperson, and the DELETE does not remove the group or eperson. An additional use of link resources is for establishing whether an eperson or group is a member of a group. The response code alone from a GET request will determine the answer, without having to retrieve an entire membership list. Link resources can also describe group members:

    authz/group/234/group/789

Finally, the API supports limited 'discovery' of groups and EPersons. Simply append a query string to the base URI for the resource type:

    authz/epeople/mit.edu

would attempt to match all EPersons with 'mit.edu' in the email field, and return an entity reference list of EPersons found. Since resource policies are bound
to individual DSOs, there is no meaningful notion of discovery. To obtain the list of policies for an object, however, use the URI:

    authz/1721.1/2/policies

where the content identifiers ('1721.1/2') are the same as those exposed in the content API.

### Registry API ###

The registry API allows administrators to maintain the various registries used to support the content. Currently the metadata schema/field registry,
and the bitstream format registries are exposed in the API. All API endpoints appear under the 'registry' path. To obtain a representation of
a metadata schema, field or bitstream format, use the system-assigned identifier:

    registry/schema/2
    registry/field/14
    registry/format/42

This same URI is used to update (PUT), or remove (DELETE). To create an object, POST to:

    registry/schemas
    registry/fields
    registry/formats

Metadata fields each belong to a schema, so you can obtain an entity reference list of them for a particular schema with:

    registry/schema/2/fields

Metadata schemas in mds can be marked as _sealed_, meaning that one should not add or remove fields belonging to the schema. This is useful for non-extensible schema such as dcterms. The API will enforce this policy, and returns a 403 Forbidden in response to attempts to create or delete fields in sealed schemas. Moreover, the sealed attribute in the schema may not be changed via the API.

### Info API ###

The info API can be used to characterize an mds instance. It is a read-only API (http GET), and provides summary information. Endpoints (all under 'info') with
the information returned:

    info/server - OS, Java, and Servlet container info
    info/system - all installed mds modules with date of install
    info/assets - counts of communities, collections, items, and bitstreams. Total storage used.
    info/metadata/schemaid - distribution of metdata values in schema (counts per field)
    info/formats - distribution of bitstreams in formats (counts per format)
    info/users - counts of users and groups
    info/workflow - counts of workspace and workflow items

Other information parameters are TDB

repository: richardrodgers/mds

repo_name: richardrodgers/mds


text:
# Run full text search queries on Amazon DocumentDB (with MongoDB compatibility) data with Amazon Elasticsearch Service

This repo is used for the blog post __[Run full text search queries on Amazon DocumentDB (with MongoDB compatibility) data with Amazon Elasticsearch Service](https://aws.amazon.com/blogs/database/run-full-text-search-queries-on-amazon-documentdb-data-with-amazon-elasticsearch-service/)__

You can also use this sample solution to stream events to Amazon Managed Stream for Kafka (or any other Apache Kafka distro), AWS Kinesis Streams, AWS SQS, and S3.

This sample solution is composed of:

## Lambda Function

The Lambda function retrieves Amazon DocumentDB credentials from Secrets Manager, sets up a connection to the DocumentDB cluster, reads the change events from the DocumentDB change stream, and replicates them to an Amazon ES indexes. The function also stores a change stream resume token in the DocumentDB cluster so it knows where to resume on its next run. To automate the solution, we poll for changes every 120 seconds. We use EventBridge to trigger a message to Amazon SNS, which invokes the function.

The Lambda function uses three variables that you can tune:

* Timeout – The duration after which the Lambda function times out. The default is set to 120 seconds.
* Documents_per_run – The variable that controls how many documents to scan from the change stream with every function run. The default is set to 1000.
* Iterations_per_sync – The variable that determines how many iterations the Lambda function waits before syncing the resume token (the resume token to track the events processed in the change stream). The default is set to 15.

For each target, there must be environment varibles in the lambda and permissions for the lambda role and/or network accordingly.

Change Streams resumability was built around the resume token used within the watch api in options resumeAfter or startAfter. If there are not events when this Lambda function runs for the first time, it uses a canary to establish a resume token for further executions.

## SNS and EventBridge Rule

The sample solution will poll for changes every 120 seconds. It uses Amazon EventBridge to trigger a message to Amazon SNS, which will in turn invoke the AWS Lambda functions which does the bulk of the work.

# How to install

1. Enable __[change streams](https://docs.aws.amazon.com/documentdb/latest/developerguide/change-streams.html)__.
2. Deploy a baseline environment:
    1. Go to AWS CloudFormation in AWS console and select *Create stack*.
    2. Check the *Upload a template file* option, select *Choose file *option and upload the __[change stream stack](https://raw.githubusercontent.com/aws-samples/amazon-documentdb-samples/master/samples/change-streams/setup/docdb_change_streams.yml)__ yaml file, and select *Next*.
    3. Give your stack a name and enter values for username, password, and the identifier for your Amazon DocumentDB cluster.
    4. AWS Cloud9 uses a Role. If you have used Cloud9 before, should already have an existing role. You can verify by going to the IAM console and searching for the role __[AWSCloud9SSMAccessRole](https://console.aws.amazon.com/iam/home?region=us-east-2#/roles/AWSCloud9SSMAccessRole)__. If you already have this role, choose true. If not, choose false and the AWS CloudFormation template creates this role for you. Select *Next*.
    5. Leave everything as default and select *Next*. Check the box to allow the stack create a role on behalf of you and select *Create stack*. The stack should complete provisioning in a few minutes.
3. Setup the Cloud9 environment:
    1. From your AWS Cloud9 environment, launch a new tab to open the Preferences tab.
    2. Select *AWS SETTINGS* from the left navigation pane.
    3. Turn off *AWS managed temporary credentials*. This enables us to simplify the developer experience later in the walkthrough.
    4. Close the Preferences tab.
    5. In a terminal window, execute:
        ```
        rm -vf ${HOME}/.aws/credentials
        ```
    6. Create an environment variable for the CloudFormation stack by executing:
        ```
        export STACK=<Name of your CloudFormation stack>
        echo "export STACK=${STACK}" >> ~/.bash_profile
        ```
    7. Configure AWS CLI to use the current region as the default:
        ```
        export AWS_REGION=$(curl -s <IP_ADDRESS>/latest/dynamic/instance-identity/document | grep region | cut -d\" -f4)
        ```
    8. Execute the code below to update the environment libraries, upload streaming code to an Amazon S3 bucket, and copy output from previous CloudFormation:
        ```
        curl -s https://raw.githubusercontent.com/aws-samples/amazon-documentdb-samples/master/samples/change-streams/setup/startup.sh -o startup.sh
        chmod 700 startup.sh
        ./startup.sh
        ```
7. Execute the commands below to create and deploy the AWS CloudFormation stack that will be populated with the required environment variables - Amazon DocumentDB URI, Amazon Elasticsearch service domain URI, watched database name, collection name, state database name, state collection name, networking configuration, SNS topics ARN, Lambda role ARN, and the Secrets Manager ARN.
    ```
    wget https://raw.githubusercontent.com/aws-samples/amazon-documentdb-samples/master/samples/change-streams/setup/lambda_function_config.sh
    chmod 700 lambda_function_config.sh
    ./lambda_function_config.sh
    ```
8. Streaming code is set. You can test it by running
    ```
    python test/es-test.py
    curl https://$(jq < cfn-output.json -r '.ElasticsearchDomainEndpoint')/_cat/indices?v
    ```

Once deployed, streaming functions will be run with the frequency set in the scheduling components.

# Environment Varibles for targets
When you set up a target, make sure AWS Lambda can reach it and the role associated to the lambda has proper permissions (e.g. s3:PutObject).

To add new target, you just need to add a new environment variable to the Lambda streaming function.

### Elasticsearch
One index will be automatically created per database and collection.
- ELASTICSEARCH_URI: The URI of the Amazon Elasticsearch domain where data will be streamed.

If Amazon Elasticsearch is a target, streaming functions must be deployed in a private subnet that can reach Internet to get an Amazon certificate required to publish to Elasticsearch. Otherwise, streaming code has to be modified and the certificate must be included in the Lambda function package.

### Kinesis
All events will go to this stream.
- KINESIS_STREAM : The Kinesis Stream name to publish DocumentDB events.

### SQS
All events will go to this queue.
- SQS_QUERY_URL: The URL of the Amazon SQS queue to which a message is sent.

### Kafka
One topic will be automatically created per database and collection. Make sure auto.create.topics.enable is set to true for the cluster configuration.
- MSK_BOOTSTRAP_SRV: The URIs of the MSK cluster to publish messages.

### S3
One folder will be automatically created per database and collection, and for each of them, folders for year, month, and day will be created.
- BUCKET_NAME: The name of the bucket that will save streamed data.
- BUCKET_PATH: The path of the bucket that will save streamed data.

# Keep in mind
- Make sure message size limits on targets will support your documents size.

## Security

See [CONTRIBUTING](CONTRIBUTING.md#security-issue-notifications) for more information.

## License

This library is licensed under the MIT-0 License. See the LICENSE file.

## Questions/feature requests?
Email questions to: documentdb-feature-request@amazon.com

repository: jpblair/amazon-documentdb-samples

repo_name: jpblair/amazon-documentdb-samples


text:
---
layout: default
---

# 1995-12-12 - Re: [NOISE] GAK and self-incrimination?

## Header Data

From: "Ed Carp (ecarp@netcom.com)"<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: 35fc7efbc85a382ba7d67d4ced4a01dd407344c000b76e69cc72afef6afc04c9

Message ID: \<199512112018.OAA11102@khijol\>

Reply To: _N/A_

UTC Datetime: 1995-12-12 06:27:46 UTC

Raw Date: Tue, 12 Dec 1995 14:27:46 +0800

## Raw message

```
{% raw  %}From: "Ed Carp (ecarp@netcom.com)"<EMAIL_ADDRESS>Date: Tue, 12 Dec 1995 14:27:46 +0800
To<EMAIL_ADDRESS>Subject: Re: [NOISE] GAK and self-incrimination?
Message-ID: <199512112018.OAA11102@khijol>
MIME-Version: 1.0
Content-Type: text/plain

> Date:          Mon, 11 Dec 1995 09:01:40 -0500
> To:            Bill Stewart<EMAIL_ADDRESS>> Subject:       Re: [NOISE] GAK and self-incrimination?
> From<EMAIL_ADDRESS>(tallpaul)
> Cc<EMAIL_ADDRESS>
> If I'm not guilty why do I want strong crypto? Sometimes for the same
> reason I want a shredder.  And why do I want a shredder? Sometimes just to
> keep the local gossip from going through my papers after I throw them out.

  This has all kinds
of annoying implications, especially for people who gather
demographics and other data for constructing email lists for sale.

-- short ed

{% endraw %}
```

## Thread

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

+ Return to "["Ed Carp (ecarp@netcom.com)" <khijol!netcom.com!ecarp@cygnus.com>](/authors/ed_carp_ecarp_at_netcom_com__khijolnetcom_comecarp_at_cygnus_com_)"

+ 1995-12-12 (Tue, 12 Dec 1995 14:27:46 +0800) - Re: [NOISE] GAK and self-incrimination? - _"Ed Carp (ecarp@netcom.com)"<EMAIL_ADDRESS>


text:
# vim-update-daily
A little plugin to allow easy plugin updates

This was created to automatically update [vim-plug](https://github.com/junegunn/vim-plug) once a day to keep those great plugins up to date.

# Configuration
There are two variables for how it should update right now `g:update_file` and `g:update_daily`.

The first handles where to store the file to log when the last update happened while the second is what command to run.
To change either of them simply by initializing them to a diffent path or command.

There is a final variable for when it should update, `g:update_open_with_args`. The default behavior is to only update when run without any arguments, ie `nvim` will update while `nvim quickedit` will not.

The defaults are as follows:

```
let g:update_file = '~/.local/share/nvim/lastupdate'
let g:update_daily = 'PlugUpgrade | PlugUpdate'
let g:update_open_with_args = 0
```

While this was designed for vim-plug if you change the command it runs it can easily update any other plugin manager

repository: isaacmorneau/vim-update-daily

repo_name: isaacmorneau/vim-update-daily


text:
# Interesting Links

I've found one of the more compelling reasons for using social media is to see what other media people are consuming. Specifically experts in a field. I've many articles, videos, and papers that I would have never discovered or found an interest in this way.

This is a *hopefully* simple attempt to isolate that benefit of social media. It's done in a manner that requires no cost to me or any future user.

## How to get Setup

1. Create a github and netlify account if you don't have
2. [![Deploy to Netlify](https://www.netlify.com/img/deploy/button.svg)](https://app.netlify.com/start/deploy?repository=https://github.com/dustinknopoff/interesting-links)
3. You'll receive an email at the address you setup with netlify.
4. Login.
5. This will take you to the Netlify CMS admin panel for your new site.
6. There are 2 sections `Links` and `My Interests`.
7. `Links` are things you find interesting and would like to share with others.
8. `My Interests` is for *"following"* other people.
9. Starting adding and following!

### Make it your Own

1. Clone the repo to your local computer
2. Edit the file `gatsby-config.js`. Add your own `Title`, `description`, etc.
3. All other changes requires customizing CSS/JS.

repository: dustinknopoff/interesting-links

repo_name: dustinknopoff/interesting-links


text:
## Wacky
[![Build Status](https://travis-ci.org/isotope11/wacky.png?branch=master)](https://travis-ci.org/isotope11/wacky)

Wacky is an engine for Rails that aims to be the best wiki.  The end goal is to
have a drop-in wiki for any given Rails app.

Features:

- versioning
- realtime markdown preview

### Installation

Add wacky to your Gemfile:

```ruby
gem 'wacky'
```

Mount wacky on your app:

```ruby
mount Wacky, at: '/wiki'
```

Copy the migrations and run them:

    rake wacky:install:migrations
    rake db:migrate

### Development

To run the tests:

    rake

repository: megalithic/wacky

repo_name: megalithic/wacky


text:
# Knative Serving Networking Openshift

This is an implementation of Knative's `Ingress` resource, specific to Openshift needs. This has been "forked" from upstream's `networking-istio` code and as such, the `pkg/reconciler/ingress` package is a nearly identical copy of upstream's code. The goal is to keep this code up-to-speed with upstream advancements and enhance it where necessary to accomodate for Openshift's needs.

## Keeping on track with upstream

To keep on track with upstream's code base we can cherry-pick changes to the `pkg/reconciler/ingress` folder upstream as we see fit. To see just commits that are local to that folder, use `git log pkg/reconciler/ingress` or navigate to https://github.com/knative/serving/commits/master/pkg/reconciler/ingress.

To cherry-pick a commit, use the `hack/cherry-pick.sh $COMMIT_ID` script as it'll automate a few tasks for you.

Remember to add a **[CP]** prefix to each cherry-picked commit before submitting it.

## Versioning scheme

The versioning scheme consists of the Knative Serving the code should be compatible with, followed by the Openshift Serverless version it'll be shipped with and an increasing number. For example:

- Knative Serving version: **v0.9.0**
- Openshift Serverless version: **1.2.0**
- Current build number: **01**

Makes **v0.9.0-1.2.0-01**

## Building and releasing a new image

To build a new image, use the `hack/build-image.sh` script. It wraps `go build` and `docker build` in a way that makes it look like an image build via operator-sdk. Push the image via `docker push` to quay.io to "release" it.

```bash
$ ./hack/build-image quay.io/openshift-knative/knative-networking-openshift:v0.9.0-1.2.0-01
$ docker push quay.io/openshift-knative/knative-networking-openshift:v0.9.0-1.2.0-01
```

gha_language: Go


text:
# acme-v2-client
a small PHP script to get and renew TLS certs from Let's Encrypt (Support ACME v2)

* Support ACME v2 (RFC 8555), ACME v1 is deprecated
* Please Read The Lastest Terms of Service Of Let's Encrypt Before You Use this Script.
  https://letsencrypt.org/documents/LE-SA-v1.2-November-15-2017.pdf
* Please Audit The Code Before You Use It
* Never Let The Script Run By Root
* Never Let The Script Read Your Domain Private Key
* use ssl server test to check your website's security
  https://www.ssllabs.com/ssltest/

# What you need to use this script to setup a https website
* **account private key**
  * used to register and communicate with acme server
  * the script need the read access of the account key
* **domain private key**
  * used as your website ssl private key
  * it must be different from your account private key for security
  * keep it in safe place, don't let the script read it
* **csr file** (Certificate Signing Request)
  * used to request the cert from CA
  * can be generated from your domain private key
  * the script need the read access of the csr file
* **http challenge dir** (which can be access by your domain)
  * used to prove the domain is in your control, acme server will
    access your domain like
    http://yourdomain.com/.well-known/acme-challenge/<challenge_file_name>
  * the script need the write access of the http challenge dir
  * the script will put the challenge file in this dir
* **a new user**
  * used to run this script
  * for security, never run this script by root
  * the user can not login from ssh
    (set your /etc/passwd to disable login for the new user)
  * the user can not read the domain private key
  * the user can read the account private key, csr file only
  * the user can write to the http challenge dir
  * set the renew cert crontab task for this user
    (Let's Encrypt cert will exprired about 90 days)
* **custom dh paramters** (optional)
  * fix the weak Diffie-Hellman and the logjam attack issue

# Script Usage
```
usage: acme-v2-client.php
    -a <account_key_file>
    -r <csr_file>
    -d <domain_list(domain1;domain2...;domainN)>
    -c <http_challenge_dir>
    -o <output_cert_file>
    [-t <terms_of_service>]

if -t command line option is set and it does not equal to the latest tos url,
you will get a error like:

terms of service has changed: please modify your -t command option
new tos: <new_tos>
```

# Detail Guide
## dependency
```
# install php-cli first
sudo apt-get install php-cli php-curl
```

## generate account private key
```
openssl genrsa -out account.key 4096
```

## generate domain private key
```
openssl genrsa -out domain.key 2048
```

## generate custom dh paramters
``
openssl dhparam -out dhparams.pem 2048
``

## generate csr from domain private key
```
# single domain
openssl req -new -sha256 -key domain.key -out domain.csr -subj "/CN=domain.com"

# multiple domain
cp /etc/ssl/openssl.cnf domain.conf
printf "[SAN]\nsubjectAltName=DNS:domain.com,DNS:www.domain.com" >> domain.conf
openssl req -new -sha256 -key domain.key -out domain.csr -subj "/" \
        -reqexts SAN -config domain.conf
```

## add a sslcert user, put the key in place
```
useradd -M sslcert
mkdir /opt/sslcert
mkdir /opt/sslcert/bin
mkdir /opt/sslcert/keys
mkdir /opt/sslcert/certs
mkdir /opt/sslcert/acme-challenge

cp acme-v2-client.php /opt/sslcert/bin
mv account.key /opt/sslcert/keys
mv domain.csr /opt/sslcert/keys
mv domain.key /etc/ssl/private
mv dhparams.pem /etc/ssl/private

chown -R sslcert:sslcert /opt/sslcert/keys
chown -R sslcert:sslcert /opt/sslcert/certs
chown -R sslcert:sslcert /opt/sslcert/acme-challenge
chmod 700 /opt/sslcert/keys
chmod 600 /opt/sslcert/keys/account.key
chmod 600 /opt/sslcert/keys/domain.csr
chmod 600 /etc/ssl/private/domain.key
chmod 600 /etc/ssl/private/dhparams.pem
```

## change nginx config to add http challenge dir
```
server {
    listen 80 default_server;
    server_name domain.com www.domain.com;

    root /opt/www/html;
    index index.html;
    try_files $uri $uri/ =404;

    location /.well-known/acme-challenge/ {
        default_type text/plain;
        alias /opt/sslcert/acme-challenge/;
    }
}

systemctl reload nginx
```

## create a wrap script
```
vi /opt/sslcert/bin/getcert.sh
chmod +x /opt/sslcert/bin/getcert.sh

#!/bin/bash

php /opt/sslcert/bin/acme-v2-client.php \
    -a /opt/sslcert/keys/account.key \
    -r /opt/sslcert/keys/domain.csr \
    -d "domain.com;www.domain.com" \
    -c /opt/sslcert/acme-challenge \
    -o /opt/sslcert/certs/domain.crt.new
if [ $? -ne 0 ]
then
    exit 1
fi

cp /opt/sslcert/certs/domain.crt.new \
   /opt/sslcert/certs/domain.crt

rm -f -- /opt/sslcert/acme-challenge/*

exit 0
```

## get cert
```
su -s /bin/bash -c 'bash /opt/sslcert/bin/getcert.sh' sslcert
```

## final nginx ssl conf
```
server {
    listen 80 default_server;
    server_name domain.com www.domain.com;

    root /opt/www/html;
    index index.html;
    try_files $uri $uri/ =404;

    location /.well-known/acme-challenge/ {
        default_type text/plain;
        alias /opt/sslcert/acme-challenge/;
    }

    location / {
        return 301 https://$host$request_uri;
    }
}

server {
    listen 443 ssl;
    server_name domain.com www.domain.com;

    root /opt/www/html;
    index index.html;
    try_files $uri $uri/ =404;

    ssl on;
    ssl_certificate /opt/sslcert/certs/domain.crt;
    ssl_certificate_key /etc/ssl/private/domain.key;
    ssl_session_timeout 10m;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    ssl_prefer_server_ciphers on;
    ssl_dhparam /etc/ssl/private/dhparams.pem;
}

systemctl reload nginx
```

## set crontab task to renew cert (run every week)
```
crontab -u sslcert -e

0 0 * * 1 /bin/bash /opt/sslcert/bin/getcert.sh
```

# Thanks
tialaramex@reddit


text:
---
id: 109
title: Temperature Monitor for Arduino
date: 2011-04-28T00:11:00+09:30
author: James Young
layout: post
guid: http://wordpress/wordpress/?p=109
permalink: /2011/04/temperature-monitor-for-arduino/
blogger_blog:
  - coding.zencoffee.org
blogger_author:
  - DW
blogger_permalink:
  - /2011/04/temperature-monitor-for-arduino.html
categories:
  - Electronics
tags:
  - arduino
---

  I've got a 1-year old, and the ducted heating system we have is only a single-zone model with the thermostat in the lounge room.  Since the bedroom doors are typically closed at night, I was always a bit concerned that there may be a large and non-linear temperature differential between the baby's room and the lounge room.  So I needed a way to track temperature between the two rooms overnight.

  The ENVI-R I had fitted is sitting in the return air vent for the heating system and has a built-in temperature monitor which I'm tracking via MRTG.  Given its position, the figures coming back from it should be the same as the temperature recorded by the thermostat in the lounge.

  What I then did was pull out my Arduino Inventor's Kit and assemble Circuit 10, which basically hooks up a TMP36 temperature sensor to Analog pin 0.  However, I heavily "adjusted" the code they gave to make it suited to my purposes.

> **Code segment is available at Google Code - [temptracker.pde](http://code.google.com/p/zencoding-blog/source/browse/trunk/arduino/temptracker.pde)**

  Essentially what happens is that the temperature monitor accumulates temperatures from the TMP36 once a second, and then once every five minutes writes the accumulated average to the EEPROM.  On startup the Arduino dumps the contents of the EEPROM out to the serial port in CSV format so you can recover it.  Given 5 minutes between samples, the Arduino can record a bit over 21 hours of temperature data like that, with no fancy shields or anything required, just a 9V power supply and the TMP36 sensor.

  After you're done, you should load up the EEPROM_clear example and run it to wipe the EEPROM back to 0.

   So, hauling out the data from MRTG and the Arduino and charting them in Excel gave me this;

      Room Temperature Comparison

The big spike at midnight was where my wife had to get up and left the door open, so the bedroom temperature normalized to close to the lounge room temperature.  It looks like the room temperature differential is on average 7.5 degrees C, and it looks pretty linear.  It also looks like the heater system (which was set to 19 degrees) didn't come on, since there's no spikes on the lounge room chart.

Now, something notable.  These temperature monitors occassionally return garbage data.  The TMP36 on the Arduino sometimes returns 9.08 degrees, and the ENVI-R's temperature sensor sometimes returns 0.  Why this happens I don't understand, but the point of the averaging on the Arduino is to reduce the effect of those broken results (a couple of 9.08's in a whole field of 300 x 15's isn't going to change the average much).  In the case of the ENVI-R, I just manually chopped out any obviously broken data.  I should go and fix my collection script to disregard broken results in MRTG.

Anyhow, it turned out to be pretty useful, and I imagine that code could be used as a base for a whole bunch of simplistic data logging applications, where you only need a small number of samples and want minimal hardware.


text:
---
title: 'Scope: A Little Goes a Long Way'
templateKey: blog-post
date: 2008-12-15T17:43:03.000Z
category:
  -Design, Tools of the Trade
alias: scope-little-goes-long-way
summary: >
 I wasn't at work last week, I'm sure you all noticed. Instead I spent the week in Austin, attending a four-day workshop series called UX Intensive, hosted by Adaptive Path.
author: AMac
image: /assets/scope.jpg
---

I wasn't at work last week, I'm sure you all noticed. Instead I spent the week in Austin, attending a four-day workshop series called [UX Intensive](http://adaptivepath.com/events/2009/uxi/), hosted by [Adaptive Path](http://adaptivepath.com/).

Throughout the week, I and about 100 other web enthusiasts examined four key elements that contribute to a successful website design: [Design Strategy](/2008/12/15/scope-little-goes-long-way), [Design Research](/2009/01/05/what-would-barney-do), [Information Architecture](/2009/01/28/metadata), and Interaction Design.

Over the course of four days, I met a lot of interesting people and learned a great deal about designing and building websites. In light of my week in Austin, I've put together a list of four insights to better web design, one for each day of the week.

Design Strategy
---------------

Design strategy ties in directly with business strategy—that is, how a business positions itself in the marketplace and differentiates itself from the competition. A unique and valuable position is what drives good business and good websites.

One important ingredient to having a good strategy for any project is clearly defining the scope of the project. Scope is, in the end, what we deliver to the client and, ultimately, the end user. Scope is defined at the beginning of the project, often in our first meetings with the client.

Too often, in all the initial excitement, the scope gets really big, really fast. Clients want an all-inclusive site with all the cool new features that does it all and "fixes everything." And, of course, we are always willing, able, and eager to deliver all the client wants and more. But it's important at this stage that we all take a step back and think about two concepts.

The first is simple. There is always a time constraint on our projects, a time limit, more or less. Within the allotted frame, let's think about delivering a smaller scope that is done very well rather than an overwhelming scope that yields a mediocre result.

The second depends on the first. Launching a site with a small scope allows the product to evolve over time, in stages. Each stage is a new opportunity to impress customers all over again. Think of it like lottery payments over the course of 10 years rather than one big lump sum. Delivering a cool new feature every few months will keep customers engaged and excited about the product over a longer period of time.

Thinking about these two concepts prior to defining scope is a great way to deliver a cost-effective, quality website that evolves over time and allows the client to systematically deliver a quality product to the end user.

repository: alexander-digett/digett

repo_name: alexander-digett/digett


text:
---
title: The Fiscal Data Package
redirect_from:
  - "/about/governance/"
---

The Fiscal Data Package is a lightweight and user-oriented format for publishing and consuming fiscal data. Fiscal data packages are made of simple and universal components. They can be produced from ordinary spreadsheet software and used in any environment.

The motivation behind the fiscal data package was to create a specification which is open by nature - based on other open standards, supported by open tools and software, modular, extensible and promoted transparently by a large community.

It is designed to be simple to use - providing a small but flexible set of features, based on real-world requirements and not theoretical ones. All the while, the built-in extensibility allows this spec to adapt to many different use cases and domains. It is also possible to gradually use more and more part of this specification - thus making it easier to implement this spec with existing data while slowly improving the data quality.

A main concern of this specification is the ability to work with data as it is currently exists, without forcing publishers to modify the contents or structure of their current data files in order to "adapt" them to the specification.

#### The Open Fiscal Data Package serves two main purposes:
Standardizing the structure and the content of fiscal data so that tools and services can be built over it for visualization, analysis or comparison;
Driving data quality by providing a solid framework of publication.

So the Open Fiscal Data Package specifies the form for fiscal data and offers a standardized framework for the content.

- Read the [Fiscal Data Package specification](https://frictionlessdata.io/specs/fiscal-data-package/) on the Frictionless Data website
- Meet the [OpenSpending tools]({% link about/tools.md %})
- Read about

branch_name: refs/heads/gh-pages


text:
# RdsConcerto

This gem provide feature which to clone Aurora(MySQL) instance.

## Installation

Add this line to your application's Gemfile:

```ruby
gem 'rds_concerto', require: false, group: :development
```

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install rds_concerto

## Usage
### Config
Put yaml to project root as `.concert.yml`.

```yaml
aws:
  region: ap-northeast-1
  access_key_id: aaaaaaaaaaaaaaaaa
  secret_access_key: bbbbbbbbbbbbbbb
  account_id: 111111111
database_url_format: "mysql2://master_username:master_user_password@{{endpoint}}/your_db_name?pool=5"
db_instance:
  source:
    identifier: a
    cluster_identifier: b
  new:
    available_types:
      - db.r4.large
      - db.r4.2xlarge
      - db.r4.3xlarge
    default_instance_type: db.r4.large
    db_parameter_group_name: default
    db_cluster_parameter_group_name: default
    publicly_accessible: false
    db_subnet_group_name: default-vpc-**************
```

* db_instance.db_subnet_group_name
  * optional. need subnet name, if you want public access.
* database_url_format
  * optional.
  * If you exec url command, need it.

### Command
```shell
bundle exec bin/concerto --help
```

## Warnging

This tool is not provied data mask feature. You will need to mask in other ways.
I think good way is to do clone from masked db. the masked db do to restore from backup each day.

## Development

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

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

## License

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

## TODO
* raise error when arg do not include in available_types
* matomeru args of RdsConcerto::CLI methods
* command log
* override mysql login and password
* Web interface

gha_language: Ruby


text:
# Universal THCRAP Launcher (UTL)
[![Build status](https://ci.appveyor.com/api/projects/status/fyrq8utgva8b1e8o?svg=true)](https://ci.appveyor.com/project/Tudi20/universal-thcrap-launcher)
[![CodeFactor](https://www.codefactor.io/repository/github/thpatch/universal-thcrap-launcher/badge)](https://www.codefactor.io/repository/github/thpatch/universal-thcrap-launcher)
[![GitHub release](https://img.shields.io/github/release/thpatch/Universal-THCRAP-Launcher.svg)](https://github.com/thpatch/Universal-THCRAP-Launcher/releases)
[![GitHub stars](https://img.shields.io/github/stars/thpatch/Universal-THCRAP-Launcher.svg)](https://github.com/thpatch/Universal-THCRAP-Launcher)
[![GitHub license](https://img.shields.io/github/license/thpatch/Universal-THCRAP-Launcher.svg)](https://github.com/thpatch/Universal-THCRAP-Launcher/blob/master/UNLICENSE.txt)

## What is UTL?
UTL is a third-party program that replaces the clutter of shortcuts that [THCRAP](https://github.com/thpatch/thcrap) creates by being a program that allows you to choose a patch configuration (list of mods and translations on top of each other) and an executable file (game or custom.exe) to run trough THCRAP.

## Installation
 - If your Windows version is lesser than Win 10 (but above WinXP), make sure to have at least [.NET Framework 4.6](https://dotnet.microsoft.com/download/dotnet-framework/thank-you/net46-web-installer).
 - Download UTL from [here](https://github.com/thpatch/Universal-THCRAP-Launcher/releases).
 - Extract the files.
 - Place the files next to `thcrap_configure.exe` and `thcrap_loader.exe` in the `bin` folder.
 - (If you JUST UPGRADED from before the restructurization of thcrap run `restructure_utl.bat` FROM THE MAIN THCRAP FOLDER. This will move your previous utl files to their right place.)
 - Run `Universal THCRAP Launcher.exe` in the `bin` folder.
 - The program will create a launcher in the main thcrap directory for you.
 - You can delete any other shortcut in the main directory. While the two exes in the main directory of thcrap have some extra functionality in them with installing redistributes (fancy word for common requirements by programs), you will usually won't need that functionality more than once and the ones in the `bin` folder can be executed from the launcher.

## Images
 - Screenshot of program:
 ![Screenshot of program](https://i.imgur.com/8QuWJ8l.png)
 - Settings:
 ![Settings](https://i.imgur.com/8HnnRnY.png)
 - Language Tab:
 ![Language Tab](https://i.imgur.com/FAfylHl.png)
 - Supported Languages:
 ![Supported Languages](https://i.imgur.com/BozBook.png)

## Adding/Updating Languages
The language files are in the [langs folder](https://github.com/thpatch/Universal-THCRAP-Launcher/tree/master/langs).
Just send a push request, and I will have a look-trough and will accept the push request.

## Licensing
JSON.Net is licensed under the MIT license

license: Unlicense,MIT

repository: thpatch/Universal-THCRAP-Launcher

detected_licenses: Unlicense MIT

gha_language: C#

gha_license_id: Unlicense

repo_name: thpatch/Universal-THCRAP-Launcher


text:
# react-ctx-store

> A React context wrapper, which makes context more performant, scalable and easy to use.

## Why?

React context is good, but it is not good for medium to big projects, it has following problems:

- re-rendering, context re-renders all the subscriber doesn't matter if the subscriber is using the updated property or not.
- scalability, context has this re-rendering issue, one single store is not possible so multiple context are required.
- there is not simple way to update the context, it requires a bit of extra code.

[![NPM](https://img.shields.io/npm/v/react-ctx-store.svg)](https://www.npmjs.com/package/react-ctx-store) [![JavaScript Style Guide](https://img.shields.io/badge/code_style-standard-brightgreen.svg)](https://standardjs.com)

## Install

```bash
npm install --save react-ctx-store
```

### Usage

```tsx
import React, { Component } from 'react'

import { createContext } from 'react-ctx-store'

const store = {
  count: 0,
}

const updaters = {
  updateCount: (store) => {
    return {
      count: store.count + 1;
    }
  }
}

const {Consumer, Provider} = createContext(store, updaters)

function CounterComponent ({count, updateCount}) {
  return (
    <div>
      <span>{count}</span>
      <button onClick={updateCount}>update count</button>
    </div>
  )
}

export function ExampleApp (){
  return (
      <Provider>
        <Consumer mapContextToProps={['count', 'updateCount']}>
          <CounterComponent/>
        </Consumer>
      </Provider>
    )
}
```

### API

```tsx
import { creatContext } from 'react-ctx-store'

const store = {
  count: 0,
}

// an object of where every key should be an string and value should be a function which will update the store
const updaters = {
  updateCount: (store, ...rest) => {
    return {
      count: store.count + 1;
    }
  }
}

const { Consumer, Provider, connect, useStore, _context } = createContext(
  store,
  updaters
)
```

`react-ctx-store` exports one single method `createContext` which takes 2 arguments

- Store - a javascript object.
- Updaters - an object of functions, only these functions can update the store, every updater function receives store as the first argument, and rest of the argument can be passed by the caller function. To update the store updater function will have to return an updated store value.

`createContext` method returns following Components and methods:

#### 1. Provider

A React component which allows consuming components to subscribe to a context changes, similar to React Context Provider.

Usage:

```tsx
function Example() {
  return (
    /* children of the Provider will have access to store and updaters using Provider Component */
    <Provider>
      <App />
    </Provider>
  )
}
```

#### 2. Consumer

A React Component that can subscribe to the values of the store/context.
Consumer takes a single prop `mapContextToProps` which takes an array of properties or a callback function as value.

Usage:

```tsx
/* all direct children of Consumer component will receive count as a prop */
<Consumer mapContextToProps={['count']}>...</Consumer>
```

or

```tsx
/* all direct children of Consumer component will receive totalCount as a prop */
<Consumer mapContextToProps={({count} => {totalCount: count * 10})}>
  ...
</Consumer>
```

#### 3. Connect

A method which lets you subscribe to the values of the store/context.

Usage:

```tsx
/* Component will receive count as a prop*/
const App = connect(['count'])(Component)
```

or

```tsx
/* Component will receive count as a prop*/
const App = connect((store) => {count: store.count, update: store.updateCount})(Component)
```

#### 3. useStore

A hook, which returns store and updaters.

Note: the component using useStore hook will re-render if any value changes in the store.

```tsx
function WithHooks() {
  const { count, updateCount } = useStore()
  return (
    <div>
      <span>{count}</span>
      <button onClick={updateCount}>Update Count</button>
    </div>
  )
}
```

#### 4. \_context

A React Context object which is internally being used to store the values, it is exposted in case a user wants to have access to original Context.

### Examples

#### Async operation in updaters

```tsx
import { createContext } from 'react-ctx-store'

const store = {
  userData: null
}

const updaters = {
  fetchUserData: async (store, userId) => {
    const userData = await fetch('.../user/' + userId)
    return { userData }
  }
}

const { Consumer, Provider } = createContext(store, updaters)

function UserProfile({ userData, fetchUserData }) {
  useEffect(() => {
    fetchUserData('123')
  }, [])
  return <div>UserName: {userData.name}</div>
}

export function App() {
  return (
    <Provider>
      <Consumer mapContextToProps={['userData', 'fetchUserData']}>
        <UserProfile />
      </Consumer>
    </Provider>
  )
}
```

## License

MIT © [aadilhasan](https://github.com/aadilhasan)

repository: aadilhasan/react-ctx-store

repo_name: aadilhasan/react-ctx-store