text:
# Demo I - Loading the Data

---
- [Python Packages](#python-packages)
- [1. Load Processed Global Data](#1-load-processed-global-data)
  - [1.1 - Meta Data](#11---meta-data)
  - [1.2 - Input Data](#12---input-data)
  - [1.3 - Checks](#13---checks)
  - [1.4 - Convert metadata to indices (**Important**)](#14---convert-metadata-to-indices-important)
- [2 - Training and Test Split](#2---training-and-test-split)
  - [2.1 - Independent Set I (SOCA2016)](#21---independent-set-i-soca2016)
    - [Checks](#checks)
  - [2.2 - Indpendent Set II (ISPRS2020)](#22---indpendent-set-ii-isprs2020)
    - [Checks](#checks-1)
  - [2.3 - ML Data](#23---ml-data)
    - [Checks](#checks-2)
  - [2.4 - Inputs, Outputs](#24---inputs-outputs)
- [3. Final Dataset (saving)](#3-final-dataset-saving)
  - [3.1 - Print out data dimensions (w. metadata)](#31---print-out-data-dimensions-w-metadata)
  - [3.2 - Saving](#32---saving)
  - [3.3 - Loading](#33---loading)
  - [3.4 - Checking](#34---checking)
  - [3.5 - Save the rest of the data](#35---save-the-rest-of-the-data)

---

### **Important** - Paths and Directories

This is annoying but it needs to be defined otherwise things get confusing. We need a few important paths to be pre-defined:

| Name           | Variable       | Purpose                                                                      |
| -------------- | -------------- | ---------------------------------------------------------------------------- |
| Project        | `PROJECT_PATH` | top level directory for the project (assuming megatron)                      |
| Code           | `CODE_PATH`    | folder of any dedicated functions that we use                                |
| Raw Data       | `RAW_PATH`     | where the raw data is. Ideally, we **never** touch this ever except to read. |
| Processed Data | `DATA_PATH`    | where the processed data is stored                                           |
| Interim Data   | `INTERIM_PATH` | where we save the training, validation and testing data                      |
| Saved Models   | `MODEL_PATH`   | where we save any trained models                                             |
| Results Data   | `RESULTS_PATH` | where we save any data results or outputs from ML models                     |
| Figures        | `FIG_PATH`     | where we store any plotted figures during any part of our ML pipeline        |

This cell checks to see if all of the paths exist. If there is a path missing, it probably means you're not in megatron. If that's the case...well, we'll cross that bridge when we get there.

<details>

```python
import pathlib
import sys

# define the top level directory
PROJECT_PATH = pathlib.Path("/media/disk/erc/papers/2019_ML_OCN/")
CODE_PATH = PROJECT_PATH.joinpath("ml4ocean", "src")

# check if path exists and is a directory
assert PROJECT_PATH.exists() & PROJECT_PATH.is_dir()
assert CODE_PATH.exists() & CODE_PATH.is_dir()

# add code and project paths to PYTHONPATH (to call functions)
sys.path.append(str(PROJECT_PATH))
sys.path.append(str(CODE_PATH))

# specific paths
FIG_PATH = PROJECT_PATH.joinpath("ml4ocean/reports/figures/global/")
RAW_PATH = PROJECT_PATH.joinpath("data/global/raw/")
DATA_PATH = PROJECT_PATH.joinpath("data/global/processed/")
INTERIM_PATH = PROJECT_PATH.joinpath("data/global/interim/")
MODEL_PATH = PROJECT_PATH.joinpath("models/global/")
RESULTS_PATH = PROJECT_PATH.joinpath("data/global/results/")

# check if path exists and is a directory
assert FIG_PATH.exists() & FIG_PATH.is_dir()
assert RAW_PATH.exists() & RAW_PATH.is_dir()
assert DATA_PATH.exists() & DATA_PATH.is_dir()
assert INTERIM_PATH.exists() & INTERIM_PATH.is_dir()
assert MODEL_PATH.exists() & MODEL_PATH.is_dir()
assert RESULTS_PATH.exists() & RESULTS_PATH.is_dir()
```

</details>

---

## Python Packages

```python
# Standard packages
import numpy as np
import pandas as pd
```

## 1. Load Processed Global Data

In this section, I will load the metadata and the actual data. The steps involved are:

1. Define the filepath (check for existence)
2. Open meta data and real data
3. Check that the samples correspond to each other.
4. Check if # of features are the same

### 1.1 - Meta Data

```python
# name of file
meta_name = "METADATA_20200310.csv"

# get full path
meta_file = DATA_PATH.joinpath(meta_name)

# assert meta file exists
error_msg = f"File '{meta_file.name}' doesn't exist. Check name or directory."
assert meta_file.exists(), error_msg

# assert meta file is a file
error_msg = f"File '{meta_file.name}' isn't a file. Check name or directory."
assert meta_file.is_file(), error_msg

# open meta data
meta_df = pd.read_csv(f"{meta_file}")

meta_df.head().to_markdown()
```

|      |     wmo | n_cycle |    N |     lon |     lat |    juld | date                |
| ---: | ------: | ------: | ---: | ------: | ------: | ------: | :------------------ |
|    0 | 2902086 |       1 |    1 | 88.6957 | 12.1639 | 23009.2 | 2012-12-30 03:58:59 |
|    1 | 2902086 |      10 |   10 | 88.6033 | 12.4128 | 23018.1 | 2013-01-08 03:24:59 |
|    2 | 2902086 |     100 |   64 | 86.2039 | 13.7915 | 23432.1 | 2014-02-26 03:34:59 |
|    3 | 2902086 |     101 |   65 | 86.3116 |   13.75 | 23437.1 | 2014-03-03 03:26:59 |
|    4 | 2902086 |     102 |   66 | 86.3971 | 13.7588 | 23442.1 | 2014-03-08 03:31:59 |

### 1.2 - Input Data

```python
# name of file
data_name = "SOCA_GLOBAL2_20200310.csv"

# get full path
data_file = DATA_PATH.joinpath(data_name)

# assert exists
error_msg = f"File '{data_file.name}' doesn't exist. Check name or directory."
assert data_file.exists(), error_msg

# assert meta file is a file
error_msg = f"File '{data_file.name}' isn't a file. Check name or directory."
assert data_file.is_file(), error_msg

# load data
data_df = pd.read_csv(f"{data_file}")

data_df.head().iloc[:, :6].to_markdown()
```

|      |    N |         wmo | n_cycle |     sla |     PAR | RHO_WN_412 |
| ---: | ---: | ----------: | ------: | ------: | ------: | ---------: |
|    0 |    1 | 2.90209e+06 |       1 | -4.7044 | 42.6541 |  0.0254617 |
|    1 |    2 | 2.90209e+06 |       2 | -4.0382 | 42.6541 |  0.0254617 |
|    2 |    3 | 2.90209e+06 |       3 | -3.4604 | 44.2927 |  0.0240942 |
|    3 |    4 | 2.90209e+06 |       4 | -2.8404 | 42.7664 |   0.024917 |
|    4 |    5 | 2.90209e+06 |       5 |  -2.394 | 42.7664 |   0.024917 |

### 1.3 - Checks

I do a number of checks to make sure that our data follows a standard and that I am reproducing the same results.

* Number of samples are equal for both
* 7 meta features
* 48 data features (26 data + 19 levels + 3 meta)
* check features in columns

```python
# same number of samples
error_msg = f"Mismatch between meta and data: {data_df.shape[0]} =/= {meta_df.shape[0]}"
assert data_df.shape[0] == meta_df.shape[0], error_msg

# check number of samples
n_samples = 25413
error_msg = f"Incorrect number of samples: {data_df.shape[0]} =/= {n_samples}"
assert data_df.shape[0] == n_samples, error_msg

# check meta feature names
meta_features = ['wmo', 'n_cycle', 'N', 'lon', 'lat', 'juld', 'date']
error_msg = f"Missing features in meta data."
assert meta_df.columns.tolist() == meta_features, error_msg

# check data feature names
input_meta_features = ['N', 'wmo', 'n_cycle']
input_features = ['sla', 'PAR', 'RHO_WN_412', 'RHO_WN_443',
       'RHO_WN_490', 'RHO_WN_555', 'RHO_WN_670', 'doy_sin', 'doy_cos',
       'x_cart', 'y_cart', 'z_cart', 'PC1', 'PC2', 'PC3', 'PC4', 'PC5', 'PC6',
       'PC7', 'PC1.1', 'PC2.1', 'PC3.1', 'PC1.2', 'PC2.2', 'PC3.2', 'PC4.1']
output_features = ['bbp', 'bbp.1', 'bbp.2', 'bbp.3', 'bbp.4', 'bbp.5', 'bbp.6', 'bbp.7',
       'bbp.8', 'bbp.9', 'bbp.10', 'bbp.11', 'bbp.12', 'bbp.13', 'bbp.14',
       'bbp.15', 'bbp.16', 'bbp.17', 'bbp.18']
features = input_meta_features + input_features + output_features
error_msg = f"Missing features in input data."
assert data_df.columns.tolist() == features, error_msg
```

### 1.4 - Convert metadata to indices (**Important**)

To make our life easier, we're going to eliminate the need to keep track of meta data all of the time. So I'm going to merge the datasets together to form one dataframe. Then I will set the index to be the metadata values. The remaining parts will be columns which will be features.

So in the end, we will have a dataframe where:

* the **indices** is the metadata (e.g. wmo, n_cycle)
* the **columns** are the actual features (e.g. sla, pca components, bbp, etc).

```python
# merge meta and data
full_df = pd.merge(meta_df, data_df)

# convert meta information to indices
full_df = full_df.set_index(meta_features)

# checks - check indices match metadata
meta_features = ['wmo', 'n_cycle', 'N', 'lon', 'lat', 'juld', 'date']
error_msg = f"Missing features in input data."
assert full_df.index.names == meta_features, error_msg

# checks - check column names match feature names
input_features = ['sla', 'PAR', 'RHO_WN_412', 'RHO_WN_443',
       'RHO_WN_490', 'RHO_WN_555', 'RHO_WN_670', 'doy_sin', 'doy_cos',
       'x_cart', 'y_cart', 'z_cart', 'PC1', 'PC2', 'PC3', 'PC4', 'PC5', 'PC6',
       'PC7', 'PC1.1', 'PC2.1', 'PC3.1', 'PC1.2', 'PC2.2', 'PC3.2', 'PC4.1']
output_features = ['bbp', 'bbp.1', 'bbp.2', 'bbp.3', 'bbp.4', 'bbp.5', 'bbp.6', 'bbp.7',
       'bbp.8', 'bbp.9', 'bbp.10', 'bbp.11', 'bbp.12', 'bbp.13', 'bbp.14',
       'bbp.15', 'bbp.16', 'bbp.17', 'bbp.18']
features = input_features + output_features
error_msg = f"Missing features in input data."
assert full_df.columns.tolist() == features, error_msg
```

```python
print('Dataframe Features:', full_df.shape)
full_df.columns.tolist()[:10]
```

    Dataframe Features: (25413, 45)

    ['sla',
     'PAR',
     'RHO_WN_412',
     'RHO_WN_443',
     'RHO_WN_490',
     'RHO_WN_555',
     'RHO_WN_670',
     'doy_sin',
     'doy_cos',
     'x_cart']

```python
print('Dataframe Indices (meta vars):', len(full_df.index.names))
full_df.index.names
```

    Dataframe Indices (meta vars): 7

    FrozenList(['wmo', 'n_cycle', 'N', 'lon', 'lat', 'juld', 'date'])

---

## 2 - Training and Test Split

### 2.1 - Independent Set I (SOCA2016)

This independent set has a set number of independent floats which are not counted in the training or validation phase. These floats were in a paper (Sauzede et. al., 2016) and used during the testing phase to showcase how well the models did.

* 6901472
* 6901493
* 6901523
* 6901496

So we need to take these away from the data.

```python
# soca2016 independent floats
soca2016_floats = ["6901472", "6901493", "6901523", "6901496"]

# subset soca2016 floats
soca2016_df = full_df[full_df.index.isin(soca2016_floats, level='wmo')]
```

#### Checks

```python
# check number of samples (meta, inputs)
n_samples = 378
error_msg = f"Incorrect number of samples for soca2016 floats: {soca2016_df.shape[0]} =/= {n_samples}"
assert soca2016_df.shape[0] == n_samples, error_msg
```

### 2.2 - Indpendent Set II (ISPRS2020)

This independent set was a set of floats taken from the ISPRS paper (Sauzede et. al., 2020 (pending...)). These floats were used as the independent testing set to showcase the performance of the ML methods.

* 6901486 (North Atlantic?)
* 3902121 (Subtropical Gyre?)

So we need to take these away from the data.

```python
# isprs2020 independent floats
isprs2020_floats = ["6901486", "3902121"]

# isprs2020 independent floats
isprs2020_df = full_df[full_df.index.isin(isprs2020_floats, level='wmo')]
```

#### Checks

```python
# check number of samples (meta, inputs)
n_samples = 331
error_msg = f"Incorrect number of samples for isprs2016 floats: {isprs2020_df.shape[0]} =/= {n_samples}"
assert isprs2020_df.shape[0] == n_samples, error_msg
```

### 2.3 - ML Data

Now we want to subset the input data to be used for the ML models. Basically, we can subset all datasets that **are not** in the independent floats. In addition, we want all of the variables in the input features that we provided earlier.

```python
# subset non-independent flows
ml_df = full_df[~full_df.index.isin(isprs2020_floats + soca2016_floats, level='wmo')]
```

#### Checks

```python
# check number of samples (meta, inputs)
n_samples = 24704
error_msg = f"Incorrect number of samples for non-independent floats: {ml_df.shape[0]} =/= {n_samples}"
assert ml_df.shape[0] == n_samples, error_msg
```

### 2.4 - Inputs, Outputs

Lastly, we need to split the data into training, validation (and possibly testing). Recall that all the inputs are already written above and the outputs as well.

```python
input_df = ml_df[input_features]
output_df = ml_df[output_features]

# checks - Input Features
n_input_features = 26
error_msg = f"Incorrect number of features for input df: {input_df.shape[1]} =/= {n_input_features}"
assert input_df.shape[1] == n_input_features, error_msg

# checks - Output Features
n_output_features = 19
error_msg = f"Incorrect number of features for output df: {output_df.shape[1]} =/= {n_output_features}"
assert output_df.shape[1] == n_output_features, error_msg
```

---

## 3. Final Dataset (saving)

### 3.1 - Print out data dimensions (w. metadata)

```python
print("Input Data:", input_df.shape)
print("Output Data:", output_df.shape)
print("SOCA2016 Independent Data:", soca2016_df[input_features].shape, soca2016_df[output_features].shape)
print("ISPRS2016 Independent Data:", isprs2020_df[input_features].shape, isprs2020_df[output_features].shape)
```

    Input Data: (24704, 26)
    Output Data: (24704, 19)
    SOCA2016 Independent Data: (378, 26) (378, 19)
    ISPRS2016 Independent Data: (331, 26) (331, 19)

### 3.2 - Saving

* We're going to save the data in the `global/interim/` path. This is to prevent any overwrites.
* We also need to `index=True` for the savefile in order to preserve the metadata indices.

```python
input_df.to_csv(f"{INTERIM_PATH.joinpath('inputs.csv')}", index=True)
```

### 3.3 - Loading

This is a tiny bit tricky if we want to preserve the meta data as the indices. So we need to set the index to be the same meta columns that we used last time via the `.set_index(meta_vars)` command.

```python
test_inputs_df = pd.read_csv(f"{INTERIM_PATH.joinpath('inputs.csv')}")

# add index
test_inputs_df = test_inputs_df.set_index(meta_features)
```

### 3.4 - Checking

So curiously, we cannot compare the dataframes directly because there is some numerical error when saving them. But if we calculate the exact differences between them, we find that they are almost equal. See below what happens if we calculate the exact difference between the arrays.

```python
# example are they exactly the same?
# np.testing.assert_array_equal(test_inputs_df.describe(), input_df.describe())
np.testing.assert_array_equal(test_inputs_df.values, input_df.values)
```

```python
AssertionError:
Arrays are not equal

Mismatched elements: 96056 / 642304 (15%)
Max absolute difference: 1.42108547e-14
Max relative difference: 3.92139227e-16
    x: array([[-4.704400e+00,  4.265410e+01,  2.546170e-02, ..., -3.458944e+00,
        -1.017509e-02, -1.025450e+00],
        [-9.015000e-01,  4.455050e+01,  2.060340e-02, ..., -3.691716e+00,...
    y: array([[-4.704400e+00,  4.265410e+01,  2.546170e-02, ..., -3.458944e+00,
        -1.017509e-02, -1.025450e+00],
        [-9.015000e-01,  4.455050e+01,  2.060340e-02, ..., -3.691716e+00,...
```

We get an assertion error that they're not equal. There is a mismatch difference of order 1e-15 for the absolute and relative differences. That's numerical error probably due to compression that comes when saving and loading data. Let's check again but with a little less expected precision.

```python
np.testing.assert_array_almost_equal(test_inputs_df.values, input_df.values, decimal=1e-14)
```

so just by reducing the precision by a smidge (1e-14 instead of 1e-15), we find that the arrays are the same. So we can trust it.

### 3.5 - Save the rest of the data

```python
input_df.to_csv(f"{INTERIM_PATH.joinpath('inputs.csv')}", index=True)
output_df.to_csv(f"{INTERIM_PATH.joinpath('outputs.csv')}", index=True)
soca2016_df.to_csv(f"{INTERIM_PATH.joinpath('soca2016.csv')}", index=True)
isprs2020_df.to_csv(f"{INTERIM_PATH.joinpath('isprs2020.csv')}", index=True)
```


text:
# Get Receipt Proof Flow

The client requests a receipt along witha proof for a previously sent transaction by providing its `tx_id` and timestamp (that was found inside the transaction itself).

The response is synchronous, so if the node takes a short while to figure out the response, the client blocks. This read does not require an active subscription on the virtual chain.

This read is not under consensus. Multiple queries can take place at the same time as this is fully parallel.

## Participants in this flow

* Client
  * `ClientSdk`

* Gateway node
  * `PublicApi`
  * `TransactionPool`
  * `BlockStorage`

## Assumptions for successful flow

* `BlockStorage` is synchronized to latest committed block.

## Flow

* `ClientSdk` sends a request to `PublicApi`.

* `PublicApi` of gateway node:
  * Queries the transaction status. See [Get Transaction Status Flow](../transaction-status.md)
    * By querying the `TransactionPool` and `BlockStorage`
  * If found, requests the `BlockStorage` to prepare a proof.

  * `BlockStorage` of gateway node:
    * Fetches the receipt block.
    * Calculates the receipts merkle tree and generate a merkle proof for the receipt.
    * Returns the block header, proof and the receipt merkle proof.

  * Responds to the client.

license: MIT

repository: orbs-network/orbs-spec

branch_name: refs/heads/master

extension: md

gha_language: Go

gha_license_id: MIT

license_type: permissive

repo_name: orbs-network/orbs-spec


text:
---
title: FastCGI - A High-Performance Gateway Interface
description: Position paper for the workshop "Programming the Web - a search for APIs", </br > Fifth International World Wide Web Conference, 6 May 1996, Paris, France.
layout: page
---

[Mark R. Brown](https://www.linkedin.com/in/mark-brown-32a01b11/)

Open Market, Inc.

2 May 1996

**Copyright © 1996 Open Market, Inc. 245 First Street, Cambridge, MA 02142 U.S.A.**

* * *

### Abstract

FastCGI is a fast, open, and secure Web server interface that solves the performance problems inherent in CGI without introducing any of the new problems associated with writing applications to lower-level Web server APIs. Modules to support FastCGI can be plugged into Web server APIs such as Apache API, NSAPI, and ISAPI. Key considerations in designing FastCGI included minimizing the cost of migrating CGI applications (including applications written in popular scripting languages such as Perl), supporting both single-threaded and multi-threaded application programming, supporting distributed configurations for scaling and high availability, and generalizing the roles that gateway applications can play beyond CGI's "responder" role.

For more information on FastCGI, including an interface specification and a module for the Apache server, visit the [fastcgi-archives.github.io Web site](https://fastcgi-archives.github.io/).

### 1\. Introduction

The surge in the use of the Web by business has created great demand for applications that create dynamic content. These applications allow businesses to deliver products, services, and messages whose shape and content are influenced by interaction with and knowledge of users.

This move towards dynamic Web content has highlighted the performance limits of CGI (Common Gateway Interface). In response there has been a proliferation of Web server APIs. These APIs address some (though not all) of the performance problems with CGI, but are not designed to meet the need of business applications. When applied to business applications, Web server APIs suffer from these problems:

*   **Complexity.** Server APIs introduce a steep learning curve, with increased implementation and maintenance costs.
*   **Language dependence.** Applications have to be written in a language supported by the server API (usually C/C++). Perl, the most popular language for CGI programs, can't be used with any existing server API.
*   **No process isolation.** Since the applications run in the server's address space, buggy applications can corrupt the core server (or each other). A malicious or buggy application can compromise server security, and bugs in the core server can corrupt applications.
*   **Proprietary.** Coding your application to a particular API locks you into a particular server.
*   **Tie-in to server architecture.** API applications have to share the same architecture as the server: If the Web server is multi-threaded, the application has to be thread-safe. If the Web server has single-threaded processes, multi-threaded applications don't gain any performance advantage. Also, when the server's architecture changes, the API will usually have to change, and applications will have to be adapted or rewritten.

Web server APIs are suitable for applications that require an intimate connection to the core Web server, such as security protocols. But using a Web server API for a Web business application would be much like using an old-fashioned TP monitor, which required linking applications right into the monitor, for a modern business transaction processing application. The old-fashioned solution suffers a huge development and maintenance cost penalty because it ignores 30 years of progress in computing technology, and may end up providing inferior performance to boot. Nobody uses the old technology unless they are already locked into it.

FastCGI is best viewed as a new implementation of CGI, designed to overcome CGI's performance problems. The major implementation differences are:

*   FastCGI processes are persistent: after finishing a request, they wait for a new request instead of exiting.
*   Instead of using operating system environment variables and pipes, the FastCGI protocol multiplexes the environment information, standard input, output, and error over a single full-duplex connection. This allows FastCGI programs to run on remote machines, using TCP connections between the Web server and the FastCGI application.

FastCGI communicates the exact same information as CGI in a different way. Because FastCGI _is_ CGI, and like CGI runs applications in separate processes, it suffers none of the server API problems listed above.

### 2\. Migration from CGI

Open Market has developed a FastCGI application library that implements the FastCGI protocol, hiding the protocol details from the developer. This library, which is freely available, makes writing FastCGI programs as easy as writing CGI applications.

The application library provides replacements for the C language standard I/O (stdio) routines such as <tt>printf()</tt> and <tt>gets()</tt>. The library converts references to environment variables, standard input, standard output, and standard error to the FastCGI protocol. References to other files "fall through" to the underlying operating system standard I/O routines. This approach has several benefits:

*   Developers don't have to learn a new API to develop FastCGI applications.
*   Existing CGI programs can be migrated with minimal source changes.
*   FastCGI interpreters for Perl, Tcl, and other interpreted languages can be built without modifying the interpreter source code.

Here's a simple FastCGI application:

```
    #include <fcgi_stdio.h>

    void main(void)
    {
        int count = 0;
        while(FCGI_Accept() >= 0) {
            printf("Content-type: text/html\r\n");
            printf("\r\n");
            printf("Hello world!<br>\r\n");
            printf("Request number %d.", count++);
        }
        exit(0);
    }
```

This application returns a "Hello world" HTML response to the client. It also keeps a counter of the number of times it has been accessed, displaying the value of the counter at each request. The <tt>fcgi_stdio.h</tt> header file provides the FastCGI replacement routines for the C standard I/O library. The <tt>FCGI_Accept()</tt> routine accepts a new request from the Web server.

The application library was designed to make migration of existing CGI programs as simple as possible. Many applications can be converted by adding a loop around the main request processing code and recompiling with the FastCGI application library. To ease migration to FastCGI, executables built with the application library can run as either CGI or FastCGI programs, depending on how they are invoked. The library detects the execution environment and automatically selects FastCGI or regular I/O routines, as appropriate.

Applications written in Perl, Tcl, and other scripting languages can be migrated by using a language interpreter built with the application library. FastCGI-integrated Tcl and Perl interpreters for popular Unix platforms are available from the [fastcgi-archives.github.io](https://fastcgi-archives.github.io/) Web site. The interpreters are backward-compatible: They can run standard Tcl and Perl applications.

### 3\. Single-threaded and multi-threaded applications

FastCGI gives developers a free choice of whether to develop applications in a single-threaded or multi-threaded style. The FastCGI interface supports multi-threading in two ways:

*   Applications can accept concurrent Web server connections to provide concurrent requests to multiple application threads.
*   Applications can accept multiplexed Web server connections, in which concurrent requests are communicated over a single connection to multiple application threads.

Multi-threaded programming is complex -- concurrency makes programs difficult to test and debug -- so many developers will prefer to program in the familiar single-threaded style. By having several concurrent processes running the same application it is often possible to achieve high performance with single-threaded programming.

The FastCGI interface allows Web servers to implement _session affinity_, a feature that allows applications to maintain caches of user-related data. With session affinity, when several concurrent processes are running the same application, the Web server routes all requests from a particular user to the same application process. Web server APIs don't provide this functionality to single-threaded applications, so the performance of an API-based application is often inferior to the performance of the corresponding FastCGI application.

### 4\. Distributed FastCGI

Because FastCGI can communicate over TCP/IP connections, it supports configurations in which applications run remotely from the Web server. This can provide scaling, load balancing, high availability, and connections to systems that don't have Web servers.

Distributed FastCGI can also provide security advantages. A Web server outside a corporate firewall can communicate through the firewall to internal databases. For instance, an application might need to authenticate incoming users as customers in order to give access to certain documents on the external Web site. With FastCGI this authentication can be done without replicating data and without compromising security.

### 5\. Roles

A problem with CGI is its limited functionality: CGI programs can only provide responses to requests. FastCGI provides expanded functionality with support for three different application "roles":

*   **Responder.** This is the basic FastCGI role, and corresponds to the simple functionality offered by CGI today.
*   **Filter.** The FastCGI application filters the requested Web server file before sending it to the client.
*   **Authorizer.** The FastCGI program performs an access control decision for the request (such as performing a username/password database lookup).

Other roles will be defined in the future. For instance, a "logger" role would be useful, where the FastCGI program would receive the server's log entries for real-time processing and analysis.

### 6\. Conclusions

Today's Web business applications need a platform that's fast, open, maintainable, straightforward, stable, and secure. FastCGI's design meets these requirements, and provides a logical migration path from the proven and widely deployed CGI technology. This allows developers to take advantage of FastCGI's benefits without losing their existing investment in CGI applications.

For more information about FastCGI, visit the [fastcgi-archives.github.io Web site](https://fastcgi-archives.github.io/).

**© Copyright 1996 - 2014 Open Market, [Rob Saccoccio](https://www.linkedin.com/in/rob-saccoccio-792ba3b/) & others, All rights reserved.**

license: OML

gha_language: HTML

gha_license_id: NOASSERTION


text:
# Docker Host

A Docker Host is a physical or virtual machine with a Linux Operation System and (at least) the [Docker Engine](DockerEngine.md) first. The Docker Engine takes care of everything around building Docker Images or running Docker Containers and connects Docker clients to Docker servers.

## Operating system of the HOST

You **MUST** use one of the following Linux Distributions:

- CentOS/Redhat
- Debian/Ubuntu
- CoreOS

## Patch management

A Docker Host is basically a Linux server an **MUST follow all Operation and Security Guidelines** that are already established at Haufe.

> A Docker Host might be treated as an "immutable" host and after the initial provisioning process, NO further modifications are allowed.
>
> As a consequence, ANY changes based on feature or security requests are introduced by switching to a new server that meets ALL THE NEW REQUIREMENTS but is identical otherwise.

## Docker version

IF you are planning to use the Docker Host (later) in production,
you **MUST** install a Docker version > 1.10.2.

You **MUST** verify that the host is configured correctly for
Docker by running [The Docker Bench for Security](https://github.com/docker/docker-bench-security).

> Out of experience, you SHOULD treat section
"1.1 Create a separate partition for containers " like a "MUST".

## Services beside Docker Engine

You **MUST** only install services that are required by
security or operations directly on the Dockerhost:

- docker
- sshd (remote access to "bare" machine)
- monitoring tools (**EXAMPLES**)
  - cAdvisor (metrics)
  - nrpe (Nagios Remote Plugin Executor for availability checks etc.)


text:
# DFP-Analysis
The purpose of this repository is to provide some transprency for blogs I've written for [Data for Progress](https://www.dataforprogress.org/). Because of data limitations not everything can be shared, but for what can be shared I will share it here. As I get chance I will see what I can make available from previous analysis.

## Overview
Each blog is a separate folder. Included also are the DPF plot themes. To run this though you need to have three fonts: FuturaBT-Heavy, Montserrat-Thin, and Montserrat-Regular.

Prior to making this repository I put the analysis for two other blogs in other repositories.
1. The Analysis of the 2018 Early Voters. [Repository](https://github.com/reuning/2018-live-poll-results)
2. Estimates of 2020 Democratic Candidate Ideology. [Repository](https://github.com/reuning/2020-Candidate-Positions)

## Blogs
1. [MaxDiff Estimates of Candidate Support by Demographic Group](https://www.dataforprogress.org/blog/2019/6/17/a-better-measure-of-candidate-support-by-demographic-groups). [Code](MaxDiff_Candidates)
2. [6 Apparent Political Clusters](https://wthh.dataforprogress.org/blog/2018/11/25/the-six-apparent-political-clusters). [Code](WTHH_Classes)
3. [What do Voters Know?](https://www.dataforprogress.org/blog/2019/6/26/what-do-the-voters-know) [Code](What_Voters_Know)
4. [Perceptions of Candidate Ideology Using Aldrich-Mckelvey Scaling](https://www.dataforprogress.org/blog/2019/7/4/perceptions-of-candidate-ideology) [Code](AM_Scaling)
5. [How Activists View the 2020 Race](https://www.dataforprogress.org/blog/2019/7/31/how-activists-view-the-2020-race) [Code](Activists_2020)

## Packages used (generally)
Most analysis is done in [RStan](https://github.com/stan-dev/stan) with plots made in [ggplot2](https://ggplot2.tidyverse.org/). In addition this repostiory uses [here](https://github.com/r-lib/here) to help with working directories.

## Data
Data is almost always pulled directly from DFP servers and so is not included in this repository.

repository: reuning/DFP-Analysis

repo_name: reuning/DFP-Analysis


text:
![collaboratory logo](../Misc-files/collaboratory2.png)

## [Collaboratory@Columbia](http://collaboratory.columbia.edu/)
### Columbia [Data Science Institute](http://datascience.columbia.edu/) and [Columbia Enterpreneuship](http://entrepreneurship.columbia.edu/)
## Winter 2019-2020 Data Science Bootcamp

- When: January 15th – 17th, 2020
- Where: Room 903 [SSW](http://stat.columbia.edu/location-and-directions/)
- Daily schedule: 9am to 4pm

### Boot Camp Information
The boot camp is organized into three stand-alone modules. Each module is a blend of prerequisite learning experiences, in-class lectures, hands-on laboratory exercises with a variety of data sets.

Participants are required to bring their own computer to the daily sessions. There will be coffee in the morning. Lunch and refreshments are **NOT** provided.

#### Day 1: Wednesday, January 15th, 2020: [Introduction to MACHINE LEARNING with Python/sklearn](Day1-Machine-Learning/)

#### Day 2: Thursday, January 16 th, 2020: [Bayesian Modeling with Stan](Day2-Bayesian-Modeling/)

#### Day 3: Friday, January 17th, 2020: [Introduction to Text Mining in Python](Day3-Text-Mining/)


text:
# How to Contribute #

## Submitting Changes ##

Please submit a [pull request](https://github.com/jamesmcclain/s3-block-device/pulls) on GitHub.

## Coding Conventions ##

All C source code has been piped through [GNU Indent](https://www.gnu.org/software/indent/).
The Kernighan & Ritchie style is used, tabs are converted to spaces, and the line-limit is 100 columns.
Those combine to give `indent -kr -nut -l100`.


text:
project_path: /web/_project.yaml
book_path: /web/updates/_book.yaml
description: The Chromium Chronicle, a monthly series geared specifically to Chromium developers — the developers who build the browser.

{# wf_updated_on: 2019-09-17 #}
{# wf_published_on: 2019-08-27 #}
{# wf_tags: chromium-chronicle #}
{# wf_featured_image: /web/updates/images/generic/cr-chron.jpg #}
{# wf_featured_snippet: All code has bugs. The Chrome Browser process has no sandbox, meaning those bugs could give malcious code full access to the whole device. This episode explains the dos and don'ts of coding without a sandbox. #}
{# wf_blink_components: N/A #}

# The Chromium Chronicle: Coding Outside the Sandbox {: .page-title }

**Episode 5:** August 2019

*by Ade in Mountain View*

Chrome is split into processes. Some of them are sandboxed, which means that
they have reduced access to the system and to users' accounts. In a sandboxed
process, bugs that allow malicious code to run are much less severe.

**The browser process has no sandbox**, so a bug could give malicious code full
access to the whole device. What should you do differently? And what's the
situation with other processes?

![sandbox diagram](/web/updates/images/2019/08/ch-chron5/sandbox-diagram.png)

**All code has bugs.** In the browser process, those bugs allow malicious code
to install a program, steal user data, adjust computer settings, access content
of all browser tabs, login data, etc.

**In other processes, OS access is limited** via platform-specific restrictions.
For more information, see Chrome's [sandbox implementation guide][sandbox-implementation].

Make sure to avoid the following common mistakes:
{: .compare-worse }

![rule of two](/web/updates/images/2019/08/ch-chron5/rule-of-two.jpg){: .attempt-left }

* **Don’t parse or interpret untrustworthy data using C++ in the
  browser process.**
* Don’t trust the origin a renderer claims to represent. The browser’s
  [RenderFrameHost][render-frame-host] can be used to get the current origin securely.

Instead, use the following best practices:
{: .compare-better }

* Be extra paranoid if your code is in the browser process.
* Validate all IPC from other processes. Assume all other processes are already
  compromised and out to trick you.
* Do your processing in a renderer or utility process or some other sandboxed
  process. Ideally, also use a memory safe language such as JavaScript
  (solves >50% security bugs).

For years, we ran network stacks (e.g. HTTP, DNS, QUIC) in the browser process,
which led to some [critical vulnerabilities][critical-vulnerabilities]. On
some platforms, networking now has its own process, with a sandbox coming.

## Additional Resources

* [Chromium's Rule of Two][rule-of-two]: no more than two of unsafe data,
unsafe code, and unsafe process.
* [Validating IPC Data][validating-ipc]: a guide on how to ensure that IPCs
from the renderer process are not full of fibs and misrepresentations.

{% include "web/_shared/helpful.html" %}

{% include "web/_shared/rss-widget-updates.html" %}

[sandbox-implementation]: https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md
[render-frame-host]: https://cs.chromium.org/search/?q=RenderFrameHost&sq=package:chromium&type=cs
[critical-vulnerabilities]: https://bugs.chromium.org/p/chromium/issues/list?q=type%3Dbug-security%20component%3AInternals%3ENetwork%20status%3Afixed%2Cverified%20security_severity%3Dcritical&can=1
[rule-of-two]: https://chromium.googlesource.com/chromium/src/+/master/docs/security/rule-of-2.md
[validating-ipc]: https://chromium.googlesource.com/chromium/src/+/HEAD/docs/security/mojo.md#Validate-privilege_presuming-data-received-over-IPC

repository: rachelandrew/WebFundamentals

repo_name: rachelandrew/WebFundamentals


text:
DULY Core integration/staging repository
=====================================

[![Build Status](https://travis-ci.org/DULY-Project/DULY.svg?branch=master)](https://travis-ci.org/DULY-Project/DULY) [![GitHub version](https://badge.fury.io/gh/DULY-Project%2FDULY.svg)](https://badge.fury.io/gh/DULY-Project%2FDULY)

DULY is a cutting edge cryptocurrency, with many features not available in most other cryptocurrencies.
- Anonymized transactions using coin mixing technology, we call it _Obfuscation_.
- Fast transactions featuring guaranteed zero confirmation transactions, we call it _SwiftTX_.
- Decentralized blockchain voting providing for consensus based advancement of the current Masternode
  technology used to secure the network and provide the above features, each Masternode is secured
  with collateral of 10K DULY

More information at [duly.com](http://www.duly.com) Visit our ANN thread at [BitcoinTalk](http://www.bitcointalk.org/index.php?topic=1262920)

### Coin Specs

Algo	Quark

Block Time	60 Seconds

Difficulty Retargeting	Every Block

Max Coin Supply (PoW Phase)	43,199,500 DULY

Max Coin Supply (PoS Phase)	Infinite

Premine	60,000 DULY*

*60,000 DULY Premine was burned in block [279917](http://www.presstab.pw/phpexplorer/DULY/block.php?blockhash=206d9cfe859798a0b0898ab00d7300be94de0f5469bb446cecb41c3e173a57e0)

### Reward Distribution

PoW Phase

Block Height	Reward Amount	Notes	Duration (Days)

1	60,000 DULY	Initial Premine	0 Days

2-151200	250 DULY	Open Mining	 Approx 180 Days

151201-259200	50 DULY

PoS Phase

Block Height	Reward Amount

259201-Infinite	Variable based on SeeSaw Reward Mechanism

### PoW Rewards Breakdown

Block Height	Masternodes	Miner	Budget

2-43200	20% (50 DULY)	80% (200 DULY)	N/A

43201-151200	20% (50 DULY)	70% (200 DULY)	10% (25 DULY)

151201-259200	45% (22.5 DULY)	45% (22.5 DULY)	10% (5 DULY)

### PoS Rewards Breakdown

Phase	Block Height	Reward	Masternodes & Stakers	Budget

Phase 1	259201-302399	50 DULY	90% (45 DULY)	10% (5 DULY)

Phase 2	302400-345599	45 DULY	90% (40.5 DULY)	10% (4.5 DULY)

Phase 3	345600-388799	40 DULY	90% (36 DULY)	10% (4 DULY)

Phase 4	388800-431999	35 DULY	90% (31.5 DULY)	10% (3.5 DULY)

Phase 5	432000-475199	30 DULY	90% (27 DULY)	10% (3 DULY)

Phase 6	475200-518399	25 DULY	90% (22.5 DULY)	10% (2.5 DULY)

Phase 7	518400-561599	20 DULY	90% (18 DULY)	10% (2 DULY)

Phase 8	561600-604799	15 DULY	90% (13.5 DULY)	10% (1.5 DULY)

Phase 9	604800-647999	10 DULY	90% (9 DULY)	10% (1 DULY)

Phase X	648000-Infinite	5 DULY	90% (4.5 DULY)	10% (0.5 DULY)

repository: theduly/dulyquark

repo_name: theduly/dulyquark


text:
---
layout: post
title:  Building a Mini Arcade Machine (Part 2)
quote:
thumbnail: true
upload_directory: /uploads/mini-arcade-pt2
toc_enabled: true
tags: ["Arcade cabinet"]
---

About a month ago I started building a mini arcade machine. A lot has happened since my first post. In the last couple of weeks my girlfriend and I sanded and painted all the wood panels. This last weekend we put the panels together and wired all the buttons, LEDs and joysticks. We slowly watched our arcade machine come to life!

## Putting it together

### Wood
Putting the painted pieces of wood together wasn't very difficult. We got a lot of help from my father in law. Practically all pieces are screwed on to both sides of the arcade. This ensures that everything is strong and can stand up to a beating if someone loses a game!

![](/uploads/mini-arcade-pt2/wood.jpg)

### Wiring the buttons & LEDs

Before we started inserting the buttons in the holes, I checked if all LEDs where working. I also indicated the polarity of the LED's on the connectors. That way I knew where the positive and negative leads should go.

![](/uploads/mini-arcade-pt2/buttons_joystick.jpg)

The LEDs need to be wired in parallel. I wired up all the LEDs using the included daisy chained ground wire. Be careful though! The wire included with this kit is intended to wire things in series, not parallel! Connecting the LEDs in parallel with this wire results in a short circuit. I needed some time to actually figure this out. I thought that everything in this kit was ready to go and was a little hesitant to cut the wire in half. Luckily though, my basic knowledge of electricity helped me out.

![](/uploads/mini-arcade-pt2/wiring_buttons.jpg)

Getting everything connected in the cabinet was a bit of a pain because we had already assembled the entire arcade. Some buttons where hard to reach and each button needs 4 wires! Putting the joysticks in was also difficult because we had to put a bolt on each screw from inside the cabinet. Conclusion? We should have wired everything up before assembling the entire cabinet!

Luckily though the wiring itself is pretty easy and straightforward. I connecting the buttons randomly to the different ports on the USB controller. How you wire the buttons isn't really important since they have to be configured later on. You do have to pay a little more attention to the joysticks though. They should be wired to one of two ports on the USB controller.

### VGA to HDMI
In the previous post I installed and configured RetroPie on my Raspberry Pi. I hooked up the Pi to my television with HDMI and tested if everything worked correctly. Everything worked great!

Last weekend however, I connected the Pi to the old VGA display in the cabinet. After booting up the Pi, the screen came on but displayed nothing. Complete darkness. Obviously the problem had to be related to the HDMI to VGA converter. As it turns out, I needed to enable HDMI safe mode to get the picture up and running.

So I ssh'ed into the Pi, edited the ``/boot/config.txt`` file and uncommented this line:

hdmi_safe=1

After a reboot, the screen turned on and I was greeted by EmulationStation's splash screen.

## Configuring RetroArch & EmulationStation
After finishing the wiring and the cabinet, we couldn't wait to play games! Before you can play you need to configure the joysticks and buttons. RetroPie ships with RetroArch, a development interface for game emulators. It allows you to configure your input method once and then use it across all supported game emulators. Neat!

To configure the buttons and the joysticks I needed to know the ID's of each button. To get this, I fired up ``jstest`` with this command:

{% highlight bash %}
jstest –event /dev/input/js0
{% endhighlight %}

This little utility shows all the inputs on the screen and shows their current state. I pressed each button and noted the ID of each of them. After this I edited the retroarch config file and configured the buttons. The config file is located here: ``/opt/retropie/configs/all/retroarch.cfg``. Here's my config file:

input_player1_joypad_index = 0
input_player1_a_btn = 13
input_player1_b_btn = 10
input_player1_y_btn = 21
input_player1_start_btn = 12
input_player1_up_axis = +3
input_player1_down_axis = -3
input_player1_left_axis = +2
input_player1_right_axis = -2

input_player2_joypad_index = 0
input_player2_a_btn = 0
input_player2_b_btn = 9
input_player2_y_btn = 2
input_player2_start_btn = 12
input_player2_up_axis = -1
input_player2_down_axis = +1
input_player2_left_axis = -0
input_player2_right_axis = +0

Note that this won't work for every setup. It depends on how you wired the buttons on to the USB interface. I also configured a hotkey that allowed me to exit a running game and return to EmulationStation. To do that, I specified a hotkey button and an exit button (my start and select buttons). So when I press both at the same time, the game exits and I return to EmulationStation!

input_enable_hotkey_btn = 12
input_exit_emulator_btn = 6

### Fixing the autofire problem
After configuring both RetroArch and EmulationStation I stumbled upon a weird issue. When you move one of the joysticks in a particular direction it autofires. The pi thinks I'm rapidly moving the joysticks in one particular direction instead of just holding it down. This caused all sorts of issue's. Some games where very hard to play because of it. Also navigating around EmulationStation was so fast that I jumped up and down the list of games.

I confirmed the problem by running ``jstest –event /dev/input/js0``. When moving the joystick down, it fills the screen with events. This should trigger just one event!

I probably spend an hour researching this issue and ultimately found [a thread on the RetroArch forums](http://blog.petrockblock.com/forums/topic/autofire-on-the-axis/) that described my issue. The solution is to apply a patch to the Linux kernel. Luckily for me, the author of the post solved his own issue and compiled a custom kernel. All I needed to do was download his kernel and run his ``install.sh`` file.

I downloaded the kernel from [his Dropbox](https://www.dropbox.com/s/oobz4e58r0afhwf/custom_kernel_1.20150216-1.tar.gz?dl=0) and transfered it to the Pi over SFTP. Now all that's left is extracting the tar.gz file and running the install script:

{% highlight bash %}
tar xf custom_kernel_1.20150216-1.tar.gz
cd custom_kernel_1.20150216-1
sudo ./install.sh
{% endhighlight %}

After installing the kernel, the script prompted me to reboot my Pi. I confirmed by typing 'Y' and a few minutes later the Pi had restarted into the new kernel. Autofiring problem: solved!

## Finding great multiplayer games
When you're building a 2-player arcade you obviously want some multiplayer games on it! I searched around on the internet and found some fun multiplayer games. Here's the short list of co-op games we currently play:

For NES:

* [Ice Climber](http://en.wikipedia.org/wiki/Ice_Climber)
* [Bubble Bobble](http://en.wikipedia.org/wiki/Bubble_Bobble)
* [Tetris (Atari)](http://en.wikipedia.org/wiki/Tetris_%28Atari%29)
* [Yoshi](http://en.wikipedia.org/wiki/Yoshi_%28video_game%29)

For SNES:

* [Ms. Pac-Man](http://en.wikipedia.org/wiki/Ms._Pac-Man)
* [Super Bomberman 3](http://en.wikipedia.org/wiki/Super_Bomberman_3)

For SEGA Genesis:

* [Sonic the Hedgehog 2](http://en.wikipedia.org/wiki/Sonic_the_Hedgehog_2)
* [Zombies Ate My Neighbors](http://en.wikipedia.org/wiki/Zombies_Ate_My_Neighbors)
* [Mortal Kombat](http://en.wikipedia.org/wiki/Mortal_Kombat_%281992_video_game%29)

Definitely leave a comment if you know another great multiplayer game for any of those classic game consoles!

## The finished arcade
Here is the finished arcade in action:

	<video src="/uploads/mini-arcade-pt2/arcade-web.mp4" autoplay muted loop style="width: 320px; height: 388px;display:inline-block;"></video>

And here are some more pictures:

![](/uploads/mini-arcade-pt2/final_1.jpg)

![](/uploads/mini-arcade-pt2/final_2.jpg)

![](/uploads/mini-arcade-pt2/final_3.jpg)

## Conclusion
This was probably one of the coolest projects I ever did! I usually spend my free time developing software, not sawing wood. I never created something physical like this before. It required not only my IT skills but also my handyman skills!

We're both very happy with how the arcade turned out. We'll continue to tweak it in the future. We want to add a nice marquee, make a better support for the screen, add more games and hold a game tournament with friends!

![](/uploads/mini-arcade-pt2/arcade_at_night.jpg)


text:
# Arwa: A(nother) Rusty Web-API

The Arwa project aims to expose modern web-APIs as Rust APIs, allowing you to interact with browser functionality such
as the DOM, the browser console, the fetch API, and many more. Arwa builds on top of
[web-sys](https://crates.io/crates/web-sys). `web-sys` by itself also exposes the browser's web-APIs; it achieves this
by automatically generating rust bindings from the [WebIDL](https://webidl.spec.whatwg.org/) specifications of the
web-APIs. However, APIs designed for Javascript do not always map neatly to Rust idioms. Arwa is an attempt at providing
a better developer experience, by tailoring more opinionated decisions on how to best expose web-functionality in Rust
on a case by case basis. A core guiding concept in the design of this mapping is the following "hierarchy of
consistency":

1. Arwa first and foremost tries to be internally consistent (even when the web-standards themselves not always quite
   manage to be).
2. Secondly, Arwa tries to be consistent with the Rust ecosystem, in particular with [std](https://doc.rust-lang.org/std/),
   the Rust standard library. As a simple example, Arwa uses `len` - not `length` - for the size of a collection.
3. Lastly, Arwa tries to be consistent with the Javascript web-APIs.

This hierarchy means that Arwa may not always closely follow the idioms of the Javascript APIs, though hopefully those
versed in interacting with the browser through Javascript will hopefully quickly find it familiar.

As Arwa builds on top of `web-sys`, most Arwa types can be converted to a corresponding `web-sys` type through a
[From](https://doc.rust-lang.org/std/convert/trait.From.html) / [Into](https://doc.rust-lang.org/std/convert/trait.Into.html)
conversion (which is almost always zero-cost). This means that if Arwa does not (yet) implement a certain web API, but
`web_sys` does, you will still be able to interact with this API by "lowering" into `web_sys` types and using "raw"
`web_sys`. It also means that you can use other crates that build on top of `web_sys` and interoperate with Arwa.

## Project Status

Arwa is still very young and thus the API is in still in flux. Arwa currently has (mostly) complete APIs for the
following set of web APIs (as distinguished by [MDN](https://developer.mozilla.org/en-US/docs/Web/API)):

- CSSOM
- Console API
- DOM
- Fetch API
- File API
- Fullscreen API
- Geolocation API
- HTML DOM (including HTML Media Elements and Custom Elements)
- HTML Drag And Drop API
- History API
- Page Visibility API
- Performance API
- Pointer Events
- Pointer Lock API
- Resource Timing API
- Selection API
- Service Worker API (without `postMessage`, see below)
- UI Events
- URL API (currently only parsed from strings, no builder API yet)
- Vibration API
- Web Crypto API (but not "subtle" crypto; random number generation only)
- Web Storage API
- Web Workers API (without `postMessage`, see below)

Note on `postMessage`: how messages are to be composed is currently an unsolved question. The current general plan is to
mimic [Serde](https://serde.rs/) -like serialization, but that is in itself a substantial project. For the time being
it is recommended you lower to `web_sys` types and post plain `JsValue` objects.

## License

MIT

repository: RSSchermer/ARWA

repo_name: RSSchermer/ARWA


text:
# Messages

In this section we describe the processing of the staking messages and the corresponding updates to the state.

## MsgBindNameRequest

A name record is created using the `MsgBindNameRequest` message.

```proto
message MsgBindNameRequest {
  option (gogoproto.equal)           = false;
  option (gogoproto.goproto_getters) = false;

  // The parent record to bind this name under.
  NameRecord parent = 1 [(gogoproto.nullable) = false];
  // The name record to bind under the parent
  NameRecord record = 2 [(gogoproto.nullable) = false];
}
```

This message is expected to fail if:
- The parent name record does not exist
- The requestor does not match the owner listed on the parent record _and_ the parent record indicates creation of child records is restricted.
- The record being created is otherwise invalid due to format or contents of the name value itself
    - Insuffient length of name
    - Excessive length of name
    - Not deriving from the parent record (targets another root)

If successful a name record will be created as described and an address index record will be created for the address associated with the name.
## MsgDeleteNameRequest

The delete name request method allows a name record that does not contain any children records to be removed from the system.

```proto
// MsgDeleteNameRequest defines an sdk.Msg type that is used to remove an existing address/name binding.  The binding
// may not have any child names currently bound for this request to be successful.
message MsgDeleteNameRequest {
  option (gogoproto.equal)           = false;
  option (gogoproto.goproto_getters) = false;

  // The parent record the record to remove is under.
  NameRecord parent = 1 [(gogoproto.nullable) = false];
  // The record being removed
  NameRecord record = 2 [(gogoproto.nullable) = false];
}
```

This message is expected to fail if:
- Any components of the request do not pass basic integrity and format checks
- The parent name record does not exist
- The record to remove does not exist
- Any child records exist under the record being removed
- The requestor does not match the owner listed on the record.

## CreateRootNameProposal

The create root name proposal is a governance proposal that allows new root level names to be established after the genesis of the blockchain.

```proto
message CreateRootNameProposal {
  option (gogoproto.equal)            = false;
  option (gogoproto.goproto_getters)  = false;
  option (gogoproto.goproto_stringer) = false;

  string title       = 1;
  string description = 2;
  string name        = 3;
  string owner       = 4;
  bool   restricted  = 5;
}
```

This message is expected to fail if:
- The name already exists
- Insuffient length of name
- Excessive length of name

repository: obsidiansystems/provenance

branch_name: refs/heads/main

repo_name: obsidiansystems/provenance


text:
### [CVE-2022-30243](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30243)
![](https://img.shields.io/static/v1?label=Product&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=brighgreen)

### Description

Honeywell Alerton Visual Logic through 2022-05-04 allows unauthenticated programming writes from remote users. This enables code to be stored on the controller and then run without verification. A user with malicious intent can send a crafted packet to change and/or stop the program without the knowledge of other users, altering the controller's function. After the programming change, the program needs to be overwritten in order for the controller to restore its original operational function.

### POC

#### Reference
- https://github.com/scadafence/Honeywell-Alerton-Vulnerabilities
- https://www.honeywell.com/us/en/product-security

#### Github
No PoCs found on GitHub currently.

repository: trickest/cve

repo_name: trickest/cve


text:
---
layout: post
title: "Discussing Podcasting and Educational Technology on the State of Ed Podcast"
tags: podcasts
eye_catch: /blog/assets/img/audio-device-macro-55800.jpg
---

This past weekend I attended [Ed Camp Long Island](https://edcampli.weebly.com/) at Commack Middle School.  Ed Camp’s are educational conferences where the sessions are created by the attendees.  It is a great opportunity to share expertise and learn from other great educators.  During the conference I attended a session where I recorded an episode for the State of Ed Podcast with [Marc Isseks](https://twitter.com/marcisseks) and other educators from Long Island.  During the episode we discussed how to get started podcasting with students and other educational technology trends.

<!--more-->

<iframe src="//html5-player.libsyn.com/embed/episode/id/11579534/height/360/theme/standard/thumbnail/yes/direction/backward/" allowfullscreen="" width="100%" height="360"></iframe>

**Source:** [State of Ed Podcast](http://stateofedpodcast.com/?p=346)

**Photo:** [Pixabay / Pexels](https://www.pexels.com/photo/black-recordering-microphone-55800/)

repository: eddiecmurray/blog

repo_name: eddiecmurray/blog


text:
##Go-Samayam

###About

This is a command line utility used to log events, create a to-do-list,
schedule appointments and time activities.

![](https://raw.githubusercontent.com/nerorevenge/go-samayam/master/Pictures/screen_2014-12-16-08-12-28.png)

### Project Goals

1. clean go code ( not accomplished)
2. heavily commented ( haha ... yeah sure )
3. absolutely no-admin related stuff ( using termbox-go may be a violation of that goal )
4. Easy to install and use ( still working on that )
5. Target distros: Arch for now (  still far from that )

license: Unlicense

repository: metric-space/go-samayam

repo_name: metric-space/go-samayam


text:
---
layout: layout.pug
navigationTitle: Dispatch 1.4.0
title: Release Notes 1.4.0
menuWeight: 10
beta: false
excerpt: View release-specific information for Dispatch 1.4.0
---

WARNING: D2iQ Dispatch has been deprecated in favor of Flux. See the D2iQ blog post for more information.

# Release Notes for Dispatch 1.4.0

## v1.4.0 - Released Feb 3, 2021
Document Modified Date: Released Feb 3, 2021

This document describes the new features, caveats, and resolved issues in D2iQ Dispatch.

### Disclaimer

* Release notes are sometimes updated with new information about restrictions and caveats. Please see [https://docs.d2iq.com/dkp/dispatch/](https://docs.d2iq.com/dkp/dispatch/) for the latest version of the D2iQ Dispatch release-notes.

### FluxCD

This release introduces [FluxCD](https://toolkit.fluxcd.io/) as a new GitOps backend. ArgoCD is now considered deprecated and will likely be removed in future releases. [Refer to this guide to learn how to setup your GitOps repositories with FluxCD.](../../tutorials/cd_tutorials/fluxcd/)

### Installation and Upgrades

To install Dispatch, follow one of the two options below:
- **Installation**: Run `konvoy init` and then update the `configVersion` for `https://github.com/mesosphere/kubeaddons-dispatch` in your `cluster.yaml`.

- **Upgrade**: Update the `configVersion` for `https://github.com/mesosphere/kubeaddons-dispatch` in your `cluster.yaml` .

1. Update the following *example* snippet from `cluster.yaml` to upgrade Dispatch 1.3.x to 1.4.0.

```yaml
  - configRepository: https://github.com/mesosphere/kubeaddons-dispatch
    configVersion: stable-1.18-1.3.1
    addonsList:
    - name: dispatch
      enabled: false
```

It should read:

```yaml
  - configRepository: https://github.com/mesosphere/kubeaddons-dispatch
    configVersion: stable-1.19-1.4.0
    addonsList:
    - name: dispatch
      enabled: true
```

2. Apply the configuration to install/upgrade Dispatch to the Konvoy cluster.
```
konvoy up
```

3. Verify that the installation/upgrade is successful.
```
helm test dispatch-kubeaddons
```
### Frontend Languages

| Frontend Language | Version |
| ------------------ | ------- |
|Starlark | 0.9 |
|CUE | 0.7 |
|YAML | 0.6 |
|JSON | 0.6 |

### Known Issues

- Prometheus endpoint `/ops/portal/prometheus/targets` will report target `dispatch/dispatch-event-sink-images/0` as unhealthy, with an error message `server returned HTTP status 404 Not Found`. Please run `kubectl delete servicemonitor -n dispatch dispatch-event-sink-images` to resolve this error.

### Improvements since Dispatch 1.3

- Added support to tasks for annotations and labels.
- Addes support in Dispatch CLI for Docker registry authentication when pulling images.
- Added support for automated installation of FluxCD onto federated clusters.
- Upgraded Tekton to v0.16.3.

### Resolved Issues

- Fixed issue with buildkit deployment on multi-instance Dispatch deployments.

### Notes

repository: mesosphere/dcos-docs-site

gha_language: SCSS

repo_name: mesosphere/dcos-docs-site


text:
# Olivea tectonae (T.S. Ramakr. & K. Ramakr.) J.L. Mulder, 1973 SPECIES

#### Status
ACCEPTED

#### According to
The Catalogue of Life, 3rd January 2011

#### Published in
Curr. Sci. 18: 176 (1949)

#### Original name
Uredo tectonae Racib., 1900

### Remarks
null

repository: mdoering/backbone

repo_name: mdoering/backbone


text:
# bunyan-hub

A centralized bunyan log aggregator.

[bunyan](https://github.com/trentm/node-bunyan) is a simple and powerful log module for node.js. This program is a server which collecting log events from all local node service. It simply start a tcp server on 28692 (BUNYA on phonepad) and waiting other node program to send new-line determined JSON string to it. You can use [bunyan-hub-logger](https://www.npmjs.com/package/bunyan-hub-logger) (or [bunyan-pub-stream](https://www.npmjs.com/package/bunyan-pub-stream) + bunyan) to push log to it and use [bunyan-sub](https://www.npmjs.com/package/bunyan-sub) cli tool to subcribes to it with specified conditions. or use [bunyan-sub-stream](https://www.npmjs.com/package/bunyan-sub-stream) api for programing use.

I think the best part of it is that you can use bunyan-sub-stream to pipe to other `bunyan-*-stream`s from npm.

I'm also planning develop a web dashboad for it like [logio](http://logio.org/) and then it would a killer app for having a local centralized log aggregator.

## install

```bash
npm i -g bunyan-hub
```

## usage

```bash
bunyanhub start
bunyanhub stop
```

You can also run `bunyan-hub-server` directly, which is the same as run `node server.js` in source directory. So you can use pm2 as the process supervisor.

```bash
pm2 start --name bunyan-hub `which bunyan-hub-server`
```

Then you can only stop it by `pm2 stop bunyan-hub`, `bunyanhub stop` will stop the instance but immediately restarted by pm2.

## protocol
once connected to localhost:28692 which bunyan-hub listening, you could write a JSON with `cmd` property ending with `\n` or FIN.

* `{"cmd":"stop"}\n` will stop the server.
* `{"cmd":"version"}\n` will give you bunyah-hub version back.
* `{"cmd":"publish"}\n` will return you nothing, but expect you to further sending more JSON string which is in bunyan record format.
* `{"cmd":"subscribe"}\n` will turn you tcp client into subscription mode, bunyan-hub will send you bunyan records in new-line determined JSON string.

usually you don't need to use raw TCP connection you self, instead using high level modules mentioned in the top section of this readme document.

## license
MIT

repository: undoZen/bunyan-hub

gha_language: JavaScript

repo_name: undoZen/bunyan-hub


text:
# ProdCheck

A web app to help people know what products are available in the store before going there. This app can be hosted and implemented independently.

## For Developers
[![Gitter](https://badges.gitter.im/convocation/ProdCheck.svg)](https://gitter.im/convocation/ProdCheck?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge)
1. First of all fork this repo.
2. Clone the repo -
```
git clone https://github.com/YOUR_USERNAME/ProdCheck.git
```
3. Installing
This app is made with Django which needs python3. Once you have python
Install all the dependencies using -
```
pip install -r requirements.txt
```
4. Make the necessary changes. And then commit it.
5. Push it to the server and submit a PR.
6. In case of any help you can always join Gitter.

### Starting the server

Before starting the server you need to migrate the models to the database.
```
python manage.py makemigrations
python manage.py migrate
```
Now to start the server -
```
python manage.py runserver
```

## License

This project is licensed under the MIT License - see the [LICENSE.md](LICENSE.md) file for details

repository: subhamX/ProdCheck

gha_language: Python

repo_name: subhamX/ProdCheck


text:
---
layout: post
title: Week 10 (26 Mar - 01 Apr, 2018)
---

**1. What did you do this past week?**

In the last week, I spent a lot of my time on schoolwork. In Software Engineering we learned about SQL, which I also have been learning this semseter in my Data Management class with Dr. Cannata. Currently in Data Management we are working on a project to visualize and find interesting trends in a dataset of our choosing. Our group found a really interesting dataset with a lot of detailed information on Police Shootings in Seattle over the last 10 years. As part of that project we are learning to use R and Tableau, which are both great data visualization tools. In my Elements of Music class we learned about chords, which was interesting because I play the guitar and know how to play chords on it, but now I know the underlying theory about them. Outside of school I spent some good quality time with my 2 cats, and I also biked quite a bit.

**2. What's in your way?**

With the semester getting closer to ending, I need to make sure I stay focused and finish out strong.

**3. What will you do next week?**

Probably spend a lot of time working on the SWE project.

**4. What's my experience of the class?**

It's really informative, I like Professor Downing's teaching style when it comes to programming. Having examples of code up on the screen and showing how changes in the code affect the output in real time is very helpful.

**5. What's my pick-of-the-week or tip-of-the-week?**

As I mentioned above, [Tableau](https://public.tableau.com/en-us/s/) is a great tool for data visualization. It seems to be one of those pieces of software that is easy to learn but hard to master, so I reccommend downloading it and messing around for a few hours to see what you can do with it. I am also learning about creating an interactive document using R markdown, a flavor of Markdown that incorporates R for easy data visualization.
[Here is a cheatsheet for R markdown.](https://www.rstudio.com/wp-content/uploads/2015/02/rmarkdown-cheatsheet.pdf)

-Spencer Huff

![headshot](https://avatars2.githubusercontent.com/u/12532488?s=400&u=8126106b9eec2022947a99c49fed90fbafc06f21&v=4 =300x300)


text:
---
title: Where are the women
author: Kerim
layout: post
permalink: /archives/2003/04/29/where-are-the-women/
categories:
  - Old Blog Import
---
From Body and Soul:

>   One of the things that struck me watching the crowds tearing down the statues of Saddam Hussein was that I didn’t see any women. Another thing that struck me was that no one commented on this — as if streets without women were entirely normal. Pardon my stereotypically feminist response, but to me a world wiped clean of women is a little disturbing. It seems to say, “Here is the future of Iraq. And people of your gender aren’t in it.” I don’t want to be a party-pooper, but it seems that about 65% of Iraq didn’t get its invitation to the party.
>
>
>     I hope that’s not the future of Iraq.
>

As was pointed out by Atrios, women in Afghanistan were much more visible after the Taliban fell…

repository: kerim/keywords

repo_name: kerim/keywords


text:
Tweets are stupid, pointless and twitter should not have
a permanent history, the only reason it does is because other blogging platforms did at the time of it's inception. That's literally it.

## How to dust / get started

Okay so you need to do a bunch of things:

* you need to installed `nodejs` and `npm`
* you need to run `npm ci`
* you need to get hold of your consumer_key, consumer_secret, access_token_key and access_token_secret
[more info here](https://developer.twitter.com/en/docs/basics/authentication/oauth-1-0a/obtaining-user-access-tokens)
* then you'll need to make a file and fill it full of the id's of the tweets you wanna delete, you can find these tweets [by downloading
your twitter archive](https://help.twitter.com/en/managing-your-account/how-to-download-your-twitter-archive)
* once you've done all this, run the duster and it'll murder your tweets for you, toit roight?

## Improvements

This could do with a LOT of improvements which is why i'm going to setup a service that will let you delete all tweets before this
year for a small (negotiable) fee.

repository: remiyoyo/tweet-duster

repo_name: remiyoyo/tweet-duster


text:
[DOCUMENTATION](http://nytimes.github.com/backbone.stickit/)

## Introduction

Backbone.stickit is yet another model-view binding plugin for Backbone. Like the other plugins, Stickit will wire up a two-way binding that will keep form elements, innerHTML, text, and attribute values bound with model attributes.

Stickit differs, however, in that it is a more natural fit with Backbone's style and functionality. In Backbone fashion, stickit leaves rendering up to you, with no special attributes, configuration, or markup needed in the template; in fact, stickit will clean up your templates, as you will need to interpolate fewer variables while rendering. Similar to `view.events`, stickit is configured with a `view.bindings` object, which is like events on steroids. Lastly, stickit leverages the `view.events` object so delegating, undelegating, and removing bindings will be seamless in the lifetime of a Backbone view.

## Download + Source

[download v0.5.2](http://nytimes.github.com/backbone.stickit/downloads/backbone.stickit_0.5.2.zip)

[view annotated source](http://nytimes.github.com/backbone.stickit/docs/annotated/)

## Usage

Similar to `view.events`, you can use `view.bindings` to map selectors to binding configurations. The following bindings configuration will map the view's dom element with [id="header"] to the `view.model`'s `headerName` attribute:

```javascript
  bindings: {
    '#header': {
      modelAttr: 'headerName'
    }
  }
```

After the view's html is rendered, usually the last call will be to stickit:

```javascript
  render: function() {
    this.$el.html('<div id="header"/>');
    this.stickit();
  }
```

On the initial call, stickit will initialize bound elements with their values so you don't need to interpolate model attributes when rendering templates. Form elements will be configured with a two-way binding, connecting user input/changes and model attribute values.

## API

### stickit
`view.stickit(optionalModel, optionalBindingsConfig)`

Uses `view.bindings` to bind elements in `view.el` with attributes in `view.model`. Stickit can be called more than once with different models or binding configurations.

```javascript
  render: function() {
    // render this.$el.html()
    // Use this.bindings and this.model to bind this.$el
    this.stickit();
    // In addition to, or instead, pass in a different model and bindings configuration.
    this.stickit(this.otherModel, this.otherBindings);
  }
```

### unstickModel
`view.unstickModel()`

Removes event bindings from any models used by stickit. Removing model events will be taken care of in `view.remove()`, but if you want to unbind the model early, use this.

## Bindings

The `view.bindings` is a hash of jQuery or Zepto selector keys with binding configuration values. When stickit is initialized, bound elements will update with their respective model attribute values.

### modelAttr

A string value which is used to map a model attribute value to the selected view element. If `modelAttr` is the only configuration, then it can be written in short form where the attribute name is the value of the whole binding configuration.

```javascript
  bindings: {
    '#header': {
      modelAttr: 'headerName'
      ...
    },
    // Short form...
    '#body': 'body'
  }
 ```

### format

A string function reference or function which returns a formatted version of the value that is passed in before setting it in the bound view element.

```javascript
  bindings: {
    '#header': {
        modelAttr: 'headerName',
        format: 'formatHeader'
    }
  },
  formatHeader: function(val, attrName) {
    return attrName + ': ' + val;
  }
 ```

### afterUpdate

A string function reference or function which is called after a value is updated in the dom.

```javascript
  bindings: {
    '#header': {
        modelAttr: 'headerName',
        afterUpdate: 'highlight'
    }
  },
  highlight: function($el, val) {
    $el.fadeOut(500, function() { $(this).fadeIn(500); });
  }
 ```

### updateMethod

Method used to update the matched dom element value. Defaults to 'text', but 'html' may also be used to update the dom element's innerHTML.

```javascript
  bindings: {
    '#header': {
        modelAttr: 'headerName',
        updateMethod: 'html',
        format: function(val) { return '<div id="headerVal">' + val + '</div>'; }
    }
  }
 ```

### escape

A boolean which when true escapes the model before setting it in the view - internally, gets the attribute value by calling `model.escape('attribute')`. This is only useful when `updateMethod` is "html".

```javascript
  bindings: {
    '#header': {
        modelAttr: 'headerName',
        updateMethod: 'html',
        escape: true
    }
  }
 ```

## Form Element Bindings

Form elements will be configured with two-way bindings, connecting user input/changes and model attribute values. The following form elements are supported:

 - input and textarea - `modelAttr` value bound with form element value
 - input[type=number] - `modelAttr` will be updated with number value.
 - input[type=checkbox] - `checked` property determined by `modelAttr` truthiness, or use `format` to return boolean
 - input[type=radio] - `modelAttr` value matches a radio group `value` attribute
 - select - see the `selectOptions` configuration

### bindForm

Enables two way binding to form elements, defaults to true. If set to false, the form element binding will be one way, and changes made to the form element will not be applied to the model.

```javascript
  bindings: {
    'input#header': {
        modelAttr: 'headerName',
        bindForm: false
    }
  }
 ```

### readonly

Sets the matched form element to readonly when readonly is `true` or, if in the case that it is a function reference, the function returns true.

```javascript
  bindings: {
    'input#header': {
        modelAttr: 'headerName',
        readonly: true
    },
    'textarea#body': {
      modelAttr: 'body',
      readonly: 'isBodyReadonly'
    }
  },
  isBodyReadonly: function(modelAttr) {
    return this.model.get(modelAttr).length > 200;
  }
 ```
### selectOptions

The following are the configuration options for `selectOptions` which binds an object collection, html select box, and a model attribute value:

 - `collection`: an object path of a collection relative to `window` or a string function reference which returns a collection.
 - `labelPath`: the path to the label value for select options within the collection of objects.
 - `valuePath`: the path to the values for select options within the collection of objects. When an options is selected, the value that is defined for the given option is set in the model. Leave this undefined if the whole object is the value.

When bindings are initialized, Stickit will build the `select` element with the options and bindings configured. If
you do not want Stickit to build the element, just leave off the `selectOptions`.

The following example references a collection of stooges at `window.app.stooges` with the following value:

```javascript
  [{name : 'moe', age : 40}, {name : 'larry', age : 50}, {name : 'curly', age : 60}]
```

```javascript
  bindings: {
    'select#stooges': {
        modelAttr: 'stooge',
        selectOptions: {
          collection: 'app.stooges',
          labelPath: 'age',
          valuePath: 'name'
    }
  }
 ```

### setOptions

An object which is used as the set options when setting values in the model. This is only used when binding to form elements, as their changes would update the model.

```javascript
  bindings: {
    '#header': {
        modelAttr: 'headerName',
        setOptions: {silent:true, customOption:false}
    }
  }
 ```

## Attribute Bindings

### attributes

Binds element attributes with observed model attributes, using the following options:

 - `name`: element attribute name.
 - `observe`: observes the given model attribute. If left undefined, then the main configuration `modelAttr` is observed.
 - `format`: formats the observed model attribute value before it is set in the matched element.

```javascript
  bindings: {
    '#header': {
      attributes: [{
        name: 'class',
        observe: 'hasWings',
        format: 'formatWings'
      }, {
        name: 'data-lang',
        observe: 'language'
      }]
    }
  },
  formatWings: function(val, attrName) {
    return val ? 'has-wings' : 'no-wings';
  }
 ```

## F.A.Q.

### Why Stickit?

JavaScript frameworks seem to be headed in the wrong direction - controller callbacks, configuration, and special tags are being forced into the template/presentation layer. Who wants to program and debug templates?

If you are writing a custom frontend, then you're going to need to write custom JavaScript.  Stickit tries to stay true to Backbone's style; where most frameworks or other Backbone plugins muck up the presentation layer with obtrusive JavaScript, stickit defines configuration and callbacks in the place that they should be - in the view/controller/JavaScript.

### Dependencies

 Backbone 0.9, underscore.js, and jQuery or Zepto

### License

MIT

## Change Log

#### 0.5.2

 - Fix IE7/8 select options bug ([issue #9](https://github.com/NYTimes/backbone.stickit/pull/9))

#### 0.5.1

 - Shorthand binding for model attributes: `'#selector':attrName`.
 - Added support for input[type=number] where values will be bound to model attributes as the Number type.
 - Attribute name is passed in as the second parameter of `format` callbacks.
 - Bug fixes: issue [#1](https://github.com/NYTimes/backbone.stickit/issues/1), [#2](https://github.com/NYTimes/backbone.stickit/issues/2), [#4](https://github.com/NYTimes/backbone.stickit/issues/4), [#6](https://github.com/NYTimes/backbone.stickit/issues/6), [#8](https://github.com/NYTimes/backbone.stickit/issues/8)

#### 0.5.0

 - Initial release (extracted and cleaned up from the backend of cn.nytimes.com).


text:
- infos = Information about Python bindings below
- infos/author = Manuel Mausz<EMAIL_ADDRESS>- infos/status = maintained
- infos/provides = swig
- infos/description =

# Python

Python bindings for Elektra.

If you have the Python bindings already installed,
you get started by reading the [tutorial](/doc/tutorials/python-kdb.md).

## Installation

See [installation](/doc/INSTALL.md).
The package is called `python3-elektra`.

## CMake Variables

To build the Python bindings
on Debian Stretch or Buster you need:

```sh
-DPython_ADDITIONAL_VERSIONS=`py3versions -d -v`
-DSWIG_EXECUTABLE=/usr/bin/swig3.0 \
-DPYTHON_EXECUTABLE:PATH=/usr/bin/python3 \
```

For Python3 on Debian Jessie you need:

```sh
-DPYTHON_EXECUTABLE:PATH=/usr/bin/python3.4
-DPYTHON_LIBRARY:FILEPATH=/usr/lib/python3.4/config-3.4m-x86_64-linux-gnu/libpython3.4.so
-DPYTHON_INCLUDE_DIR:PATH=/usr/include/python3.4
```

On most distributions `CMAKE_INSTALL_PREFIX` needs to be set to `/usr`
so that Python finds the modules without setting `PYTHONPATH`.

The default `CMAKE_INSTALL_PREFIX` (`/usr/local`) usually is
not part of Python's default search path, see `python3 -c 'import sys; print(sys.path)'`.
So either make sure to:

1. compile with `CMAKE_INSTALL_PREFIX=/usr`
2. tell CMake your correct Python site package with e.g. `PYTHON_SITE_PACKAGES=/usr/lib64/python3.y/site-packages`
3. extend Python's default search path at runtime with e.g. `PYTHONPATH=/usr/local/lib/python3/dist-packages`

## Development

Note that `cmake` does _not_ automatically rebuild SWIG bindings
when header files are changed. Remove the build directory
in that case.

## Iteration

Use external iterators the following way:

```python
size = ksSize(keySet)
for cursor in range(size):
	key = ksAt(keySet, cursor)
	# ...
```

repository: ElektraInitiative/libelektra

gha_language: C

repo_name: ElektraInitiative/libelektra


text:
### [CopyQ](https://hluk.github.io/CopyQ/)

#### Install using Git

If you are a git user, you can install the theme and keep up to date by cloning the repo:

    $ git clone https://github.com/dracula/copyq.git

#### Install manually

Download using the [GitHub .zip download](https://github.com/dracula/copyq/archive/master.zip) option and unzip them.

#### Activating theme

1. Open the CopyQ main window
2. Open CopyQ Preferences under the File > Preferences menu
3. Click Appearance in the Configuration window
4. Click Load Theme and find the dracula.ini file where you downloaded it.
5. Click Apply and OK


text:
WebPayment Request API - Magento 2 Module
=====================
PaymentRequest lets you accept payment from different payment methods.

![Rafael Corrêa Gomes - Magento 2 WebPayment](https://media.giphy.com/media/1fkd4JT1Aj7hLBsG0Z/giphy.gif)
![RequestPaymentAPI](https://media.giphy.com/media/8375Cq2Vjq7xypjheQ/giphy.gif)

Facts
-----
- version: 0.9.0
- extension key: Rafaelcg_WebPayment

Description
-----------
The Payment Request API is a W3C standard candidate that is meant to eliminate checkout forms. It vastly improves user workflow during the purchase process, providing a more consistent user experience and enabling web merchants to easily leverage different payment methods.

The Payment Request API is designed to be vendor-agnostic, meaning it does not require use of a particular payment system. It's not a new payment method, nor does it integrate directly with payment processors; rather, it is a conduit from the user's payment and shipping information to merchants, with the following goals:

- Let the browser act as intermediary among merchants, users, and payment methods
- Standardize the payment communication flow as much as possible
- Seamlessly support different secure payment methods
- Work on any browser, device, or platform—mobile or otherwise

The Payment Request API is an open and cross-browser standard that replaces traditional checkout flows by allowing merchants to request and accept any payment in a single API call. The API allows the web page to exchange information with the user agent while the user is providing input, before approving or denying a payment request.

Best of all, with the browser acting as an intermediary, all the information necessary for a fast checkout can be stored in the browser, so users can just confirm and pay, all with a single click.

Compatibility
-------------
- Magento >= 2.1

Installation Instructions
-------------------------
1. Copy the content of the `src` folder to your root folder.
2. Run these commands:

```
php -f bin/magento module:enable Rafaelcg_WebPayment
php -f bin/magento setup:upgrade
```

Contribution
------------
Any contribution is highly appreciated. The best way to contribute code is to open a [pull request on GitHub](https://help.github.com/articles/using-pull-requests).

Licence
-------
[MIT - Open Software Licence](https://opensource.org/licenses/MIT)

Copyright
---------
(c) 2019 [Rafael Corrêa Gomes](https://github.com/rafaelstz)


text:
---
title: 'API Methods'
date: '2020-04-08'
author: 'Chandu Sree'
---

APIs enable us to develop different kinds of web applications having
operations like CRUD(create, retrieve, update, delete).

Here we can discuss different API methods and their use cases.

![Imgur](https://i.imgur.com/h3K7u72.jpg)

### GET API :

We can use GET requests to retrieve resource representation or
information only, we cannot modify it in any way. They do not
change the state of the resources and are said to be the safe
methods. GET APIs should be idempotent, which means it should be
able to make multiple identical requests and must also produce the
same result everytime until another API has changed the state of
resource on the server. If the request URLs refers to a data producing
process, the produced data will be returned in the the response and
not the source text of the process, unless it is the output of the
process.

For any GET API, if the resource is found on the server, then it must
return HTTP response code 200(OK). Incase resource is not found
then it must return HTTP response code 404(Not Found), if GET
request itself is not correctly formed then the server will return to
HTTP response code 400(Bad Request).

Example: HTTP GET http://www.appdomain.com /users

### POST API :

We can use post APIs to create new subordinate resources. A file is
subordinate to a directory containing it or a row is subordinate to a
database table.

If a resource has been created on the origin server then the response
201 (created). If the action performed by the POST method does not
result in a resource that can be identified by a URL then the HTTP
response code should be 200 (OK) or 204 (No Content).Responses to
this methods are not cacheable. POST is neither safe or idempotent.

Example: HTTP POST http://www.appdomain.com/users

### PUT API :

We can use PUT API’s primarily to update existence resource if a new
resource has been created by the PUT API,the origin server must
inform the user agent via the HTTP response code 201 (Created).
If an existing resource is modified then the HTTP response code is
either 200 (OK) or 204 (No Content). Responses to this method are
not cacheable.

The difference between POST APIs and PUT APIs can be observed in
the URLs. POST requests are made on resource collections whereas
PUT requests are made on a single resource.

Example: HTTP PUT http://www.appdomain.com/users/123

### DELETE API:

DELETE APIs are used to delete resources identified by the request
URL. If the response includes an entity .An entity describing the
status, then the HTTP response code should be 200 (OK)

If the actions has been queued then it should be 202 (Accepted)
If the actions has been performed but the response does not include
an entity then the HTTP response code should be 204 (No Content)
DELETE operations are idempotent, if you delete a resource then it is
removed from the collection of resources repeatedly calling DELETE
API on the resource will not change the outcome. However calling
DELETE on a resource for a second time will return a 404 (Not Found)
since it was already removed. Responses to this method are not
cacheable.

Example: HTTP DELETE http://www.appdomain.com/users/123

repository: DrawPI/Blogs

path: /API Basics/2020-08-01-API-methods.md

repo_name: DrawPI/Blogs


text:
# Blupe.Space
Blupe.Space, an amazing "Aatmanirbhar" video meeting platform for all your needs is coming to you. Blupe.Space is so simple that, you don't even have to Sign Up to join a meeting.
Blupe.Space also comes with some amazing features such as :
- Raising Hands
- Streaming to YouTube
- App / Web Support
- Utmost Safety / Security

This is the first version of the app. The app is free and open sourced. : [Blupe - Secure Video Meetings](https://play.google.com/store/apps/details?id=me.aravind.blupespace)

---

### Advantages of Blupe
- an Aatmanirbhar initiative
- Has everything that you need
- Utmost Safety and Security
- Open Sourced and available to you for contributions

---

---

### Contributors
- Designs by Navaneeth Venu - [Instagram](https://instagram.com/noobaneeth), [Portfolio](https://nauaneeth.github.io/), [GitHub](https://github.com/nauaneeth)

---

You're welcome to contribute to this. Please reach out to me over [Instagram](https://instagram.com/aravindvenugopal02) so that we can discuss how you can be a part of this. Here are some ways by which you can contribute :
- Help us add more features to the app
- Help us improve the user interface
- Help us improve the user experience
- Help us improve our overall structure
- Help us reach more passionate individuals
- Help us Promote the app to reach more people

---
Also, please feel free to share your opinion / feedback. Your input will help us create a better product and reach more passionate people around the world and thereby help them out as much as we can.

gha_language: Java


text:
# AtTypes-react-datasheet

Typescript types for `react-datasheet`.

## Usage

Add the following dependency to your `package.json`:
```
"@types/react-datasheet": "weswigham/AtTypes-react-datasheet"
```

## Workarounds

This exposes a generic component (since you're very free with what data you can store in the data field of the props). [TS doesn't currently do type inference on JSX components, even when they are generic](https://github.com/Microsoft/TypeScript/issues/14036), and the syntax doesn't support placing a generic inline. Until the situation changes, the correct workaround is like so:
```ts
import ReactDataSheet from "react-datasheet";
import "react-datasheet/lib/react-datasheet.css";
import * as React from "react";

export interface GridElement {
    value: string;
    enabled: boolean;
}

// Note the alias below
const MyGrid: {new (): ReactDataSheet<GridElement>} = ReactDataSheet;

export default (state: any) => <MyGrid data={state.values} valueRenderer={(cell) => cell.enabled ? cell.value : ""}/>;

```

repository: weswigham/AtTypes-react-datasheet

repo_name: weswigham/AtTypes-react-datasheet


text:
+++
title = "Add support for variables in plugins"
type = "docs"
+++

# Add support for variables in plugins

Variables are placeholders for values, and can be used to create things like templated queries and dashboard or panel links. For more information on variables, refer to [Templates and variables]({{< relref "../../variables/templates-and-variables.md" >}}).

This guide explains how to leverage template variables in your panel plugins and data source plugins.

We'll see how you can turn a string like this:

```sql
SELECT * FROM services WHERE id = "$service"
```

into

```sql
SELECT * FROM services WHERE id = "auth-api"
```

Grafana provides a couple of helper functions to interpolate variables in a string template. Let's see how you can use them in your plugin.

## Interpolate variables in panel plugins

For panels, the [replaceVariables]({{< relref "../../packages_api/data/panelprops.md#replacevariables-property" >}}) function is available in the [PanelProps]({{< relref "../../packages_api/data/panelprops.md" >}}).

Add `replaceVariables` to the argument list, and pass it a user-defined template string.

```ts
export const SimplePanel: React.FC<Props> = ({ options, data, width, height, replaceVariables }) => {
  const query = replaceVariables('Now displaying $service')

  return <div>{ query }</div>
}
```

## Interpolate variables in data source plugins

For data sources, you need to use the [getTemplateSrv]({{< relref "../../packages_api/runtime/gettemplatesrv.md" >}}), which returns an instance of [TemplateSrv]({{< relref "../../packages_api/runtime/templatesrv.md" >}}).

1. Import `getTemplateSrv` from the `runtime` package.

   ```ts
   import { getTemplateSrv } from '@grafana/runtime';
   ```

1. In your `query` method, call the `replace` method with a user-defined template string.

   ```ts
   async query(options: DataQueryRequest<MyQuery>): Promise<DataQueryResponse> {
     const query = getTemplateSrv().replace('SELECT * FROM services WHERE id = "$service"'), options.scopedVars);

     const data = makeDbQuery(query);

     return { data };
   }
   ```

repository: sapcc/grafana

repo_name: sapcc/grafana


text:
This is a commandline tool for recording OGG audio.

It can run in the following modes:
- `main` = (default) listen on local tcp port 3000 and write ogg data to receiving clients
- `main -` = write ogg data to stdout (bash redirect to write to file, etc.)
- `main stream` = write stdin to local tcp port 3000 (used it for some testing)

Recommended use with FFMPEG! You can use the -i tcp://<IP_ADDRESS>:3000 as input after launching.


text:
# Unofficial [Booklog](https://booklog.jp/) plugin for [Franz](http://meetfranz.com/)

The minimum required version of Franz to run custom integrations is 5.0.0. You can download the latest version of Franz [here](http://meetfranz.com/#download).

## Installation

1. To install a new integration, clone or download this repository

2. Open the Franz Plugins folder on your machine (note that this dev directory may not exist yet, and you must create it):

 * Mac: `~/Library/Application Support/Franz/recipes/dev/`
 * Windows: `%appdata%/Franz/Roaming/recipes/dev/`
 * Linux: `~/.config/Franz/recipes/dev/`

3. Copy the `booklog` folder into the plugins directory
4. Reload Franz

repository: takafm/franz-booklog

repo_name: takafm/franz-booklog


text:
# snowplow-badrows-tables

Resources to enable SQL queries over Snowplow bad rows

## Overview

A "bad row" is any payload that hits a Snowplow pipeline, but which cannot be successfully parsed or processed.
Bad rows are preserved by writing them to cloud storage (e.g. [S3][S3 home] or [GCS][GCS home]) as newline-delimited JSON objects.

[Athena][athena home] on AWS and [BigQuery][bigquery home] on GCP are tools that let you query your bad rows, using the cloud storage files as a back-end data source.

```sql
SELECT data.failure.messages FROM adatper_failures
WHERE data.failure.timestamp > timestamp '2020-04-01'
```

This is great for debugging your pipeline without the need to load your bad rows into a separate database.

## Setup

To create tables in Athena or BigQuery, you need to provide a table definitions corresponding to the JSON schema of your bad row files.
Each different bad row type (e.g. schema violations, adapter failures) has its own JSON schema, and therefore requires its own separate table.

This repo is split into:

* [Resources and instructions for Athena](athena) if your bad rows are in AWS S3
* [Resources and instructions for BigQuery](bigquery) if your bad rows are in Google Cloud Storage

[S3 home]: https://aws.amazon.com/s3/
[athena home]: https://aws.amazon.com/athena/
[GCS home]: https://cloud.google.com/storage
[bigquery home]: https://cloud.google.com/bigquery

repository: edwin-snowplow/snowplow-badrows-tables

repo_name: edwin-snowplow/snowplow-badrows-tables


text:
# Phragmidium bullatum Westend., 1863 SPECIES

#### Status
SYNONYM

#### According to
The Catalogue of Life, 3rd January 2011

#### Published in
Bull. Soc. R. Bot. Belg. 30: 11 (1863)

#### Original name
Phragmidium bullatum Westend., 1863

### Remarks
null

path: /life/Fungi/Basidiomycota/Pucciniomycetes/Pucciniales/Phragmidiaceae/Phragmidium/Phragmidium mucronatum/ Syn. Phragmidium bullatum/README.md


text:
# Overview

A Docker image for recording audio and video streams of an IP based  surveillance camera. The camera need to support the *RTSP* protocol. The streams are processed by *ffmpeg*.

## Usage

You need to specify at least the RTSP URL of the IP camera and a volume to store the recorded data. You may need to read to documentation of your IP camera in order to find the correct URL.

Then you can start the container like this:

```bash
docker run -d -e<EMAIL_ADDRESS>-v /my/local/storage_path:/record --restart unless-stopped mytracks/ipcamerarecorder
```

The container will write *mp4* files to the volume mounted to `/record`. Therefore you may need to specify a user id with the correct permissions. As a default the container is executed using user id 1000.

## Configuration

You can configure the container using the following environment variables:

| Environment Variable  | Description | Default Value |
| ------------- | ------------- | ------------- |
| `URL`  | The RTSP URL used to connect to the camera. This has to be a [valid RTSP URL for ffmpeg](http://ffmpeg.org/ffmpeg-protocols.html#rtsp). |<EMAIL_ADDRESS>|
| `KEEP_DAYS`  | The numbers of days to keep the recorded files.  | `14` |
| `RECORD_LENGTH_SECONDS`  | The length of each individual recording in seconds  | `3600` |
| `FRAMERATE`  | The frame rate for the recording  | `4` |
| `FFMPEG_ARGS`  | Additional command line arguments for ffmpeg.  |  |

## Some Details

You can specify the length of the recordings using the environment variable `RECORD_LENGTH_SECONDS`. After this period the container will stop. I have chosen this solution because it was the most reliable solution in case the camera wasn't reachable for some time or in case any other error occurred. Therefore you need to specify `--restart unless-stopped` when starting the container.

With each start of the container old recordings are deleted. You can specify the number of days to keep old recordings using the environment variable `KEEP_DAYS`.

## Supported Architectures

The following Docker architectures are supported: `linux/arm64`, `linux/arm/v7` and `linux/amd64`

## Kubernetes

You can also run this container in Kubernetes. Here is an example of a pod definition that you can use as a starting point for your configuration:

```yaml
apiVersion: v1
kind: Pod
metadata:
  name: ipcamerarecorder1
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 1000
  restartPolicy: Always
  hostNetwork: true
  containers:
  - name: ipcamerarecorder
    image: mytracks/ipcamerarecorder
    env:
    - name: URL
      value<EMAIL_ADDRESS>    volumeMounts:
      - mountPath: /record
        name: record
  volumes:
  - name: record
    hostPath:
      path: /my/local/storage_path
      type: Directory
```

*Notes:*

* You need to set `hostNetwork: true`. Otherwise RTSP will not work. If you know a better solution please let me know.
* You need to set `restartPolicy: Always`. Otherwise you will only get a single recording.

repository: mytracks/ipcamerarecorder

gha_language: Shell

repo_name: mytracks/ipcamerarecorder