text:
# QoS3
Third practical assignment for the QoS subject

Some tutorials for android client:

http://www.dreamincode.net/forums/topic/396185-android-socket-tutorial-part-1/
http://www.dreamincode.net/forums/topic/396186-android-socket-tutorial-part-2/

Mitmproxy documentation:
https://docs.mitmproxy.org/stable/

Get urls from mitmproxy to check if they are ads or not:
https://discourse.mitmproxy.org/t/extract-all-request-urls-from-a-session/26

mitmdump > output.txt

Databases to check ads:
https://filterlists.com/
https://easylist.to/
https://easylist.to/easylist/easylist.txt

url: https://raw.githubusercontent.com/ggoncalopereira/MIEI-projects/522fc3ee7b5c29dcb6378e08291f2337d73bb099/4th year/Qualidade de Serviço na Internet/TP3/README.md

repository: ggoncalopereira/MIEI-projects

repo_name: ggoncalopereira/MIEI-projects


text:
# openshift-pv-cleanup

The purpose of this role is to clean up persistent volumes in a cluster before decommisioning a cluster.

## Usage

```
ansible-playbook -i inventory roles/openshift-pv-cleanup/test/main.yml
```

repository: redhat-cop/casl-ansible

branch_name: refs/heads/master

extension: md

gha_language: Python

license_type: permissive

repo_name: redhat-cop/casl-ansible


text:
# kfilesync

 Sync MTP devices(Android devices, USB memory, etc) to Windows PC.

 Sync between MTP devices is also possible.

## Usage
```
kfilesync src dst [mode]

  src   Source folder
            ex) MTP0:\DCIM  - DCIM folder of MTP device with id = 0
  dst   Destination folder
  mode  Sync mode
        +  Copy new files from source folder (default)
        0  Init sync. Copy no files and just make list of files in source folder.
           Current files in source folder will not be copied in next sync.
        -  Delete files which is not in source folder.
        =  Make destination folder equal to source folder.
        ?  Show differences only.
```

license: MIT

repository: tobwithu/gowpd

repo_name: tobwithu/gowpd


text:
---
date: 2016-01-14 10:50:10+00:00
redirect_from:
  - /real-life-facebook/
title: Real life Facebook
header:
  teaser: "/assets/images/category-spirit-of-the-age.png"
  video:
    id: LO-1VaR3PPo?rel=0
    provider: youtube
categories: spirit-of-the-age

tags:
  - Facebook
  - social-conditioning
  - friendship
  - social-anxiety
  - social-isolation
  - technology
  - politics
excerpt: "Are you on Facebook?  How many of your online friends do you really actually know?  Would you want to change that?  Why or why not?"
---

Are you on Facebook?  How many of your online friends do you really actually know?  Would you want to change that?  Why or why not?

Who's really taking note of all those personal details you expose to your friends on  Facebook...

**Please note:** If you're reading this in an email or RSS feed, you must [visit the website](http://www.alecsatin.com/spirit-of-the-age/real-life-facebook/){: .btn .btn--warning} to watch the video.
{: .notice}

Originally published at: Comfort for Christians

gha_license_id: MIT


text:
# Reference

## Bundle File Format

Bundles – including the `deployer.root.bundle` – are yaml files with the following sections:

### `deployables`

The key is the `name` of the deployable, i.e. a `war` named `foo` will be deployed as `foo.war`, so the base uri for a REST service is `https://<hostname>:<port>/<name>`.

- `state`: Either `deployed` or `undeployed`. Defaults to
the variable [`${name}.state`](#vars) or `deployed`.
- `group-id`: Defaults to the variable [`default.group-id`](#vars).
- `artifact-id`: Defaults to the name of the deployable.
- `classifier`: Defaults to none.
- `version`: Defaults to the variable [`${name}.version}`](#vars) or `CURRENT` (see below).
- `type`: `war` or `jar`. Defaults to [`default.deployable-type`](#vars) or `war`.
- `checksum`: The SHA-1 checksum of the artifact file. Optional to check for integrity.

Special `version` values:

| name | usage |
| --- | --- |
| `CURRENT` | The currently deployed version. Only for `deployables`, not for `bundles`. |
| `LATEST` | The numerically largest version in the repository that is not a `-SNAPSHOT`. |
| `UNSTABLE` | The numerically largest version in the repository, `-SNAPSHOT` or not. |

### `bundles`

The key is the `name` of the bundle.

- `group-id`: Defaults to the variable [`default.group-id`](#vars).
- `artifact-id`: Defaults to the name of the deployable.
- `classifier`: Defaults to none.
- `version`: Mandatory.
- `instances`: The map of instance names to a map of variables passed into a `bundle`.
Defaults to a single empty-named entry with an empty map.

### `log-handlers`

The key is the `name` of the log handler. This is conventionally an upper case string.

- `state`: Either `deployed` or `undeployed`. Defaults to `deployed`.
- `level`: The [log level](#log-levels). Defaults to `ALL`.
- `type`: One of `console`, `periodic-rotating-file`, or `custom`.
Defaults to [`default.log-handler-type`](#vars) or `periodic-rotating-file`.
- `format`: The format used for log lines.
Defaults to using a [`default.log-formatter`](#vars) or [`default.log-format`](#vars) or `%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n`.
- `formatter`: Alternative to `format`: The name of a named formatter. Wildfly 10.0.0 defines: `PATTERN` and `COLOR-PATTERN`.

Only for `periodic-rotating-file`:
- `file`: The base name of the file to log to. Defaults to the lower case `name` of the log handler plus `.log`.
- `suffix`: The date/time suffix used when rotating, defining the rotation frequency.
Defaults to [`default.log-file-suffix`](#vars) or `.yyyy-MM-dd`, i.e. daily rotation.

Only for `custom`:
- `module`: The JBoss module name. Mandatory.
- `class`: The fully qualified class name of the custom handler. Mandatory.
- `properties`: A map of parameters passed to the custom handler. Defaults to an empty map.

### `loggers`

The key is the `category` of the logger, usually the fully qualified name of the class producing the logs.

- `state`: Either `deployed` or `undeployed`. Defaults to `deployed`.
- `level`: The [log level](#log-levels). Defaults to [`default.log-level`](#vars) or `«DEBUG»`.
- `handlers`: A list of log handler names. Defaults to an empty list.
- `handler`: Alternative syntax for a single log handler name. Defaults to an empty list.
- `use-parent-handlers`: Should the log handlers of the parent logger be used?
Defaults to `true` if the `handlers` are empty, or `false`, if there _are_ log handlers.

### `data-sources`

The key is the `pool-name` of the data source.

- `state`: Either `deployed` or `undeployed`. Defaults to `deployed`.
- `uri`: The JNDI URI used to connect to the database. Mandatory.
- `jndi-name`: The name that can be used to look up the data source.
Defaults to `java:/datasources/<name>DS` where `<name>` is the name of the data source.
- `driver`: The `driver-name` to be used to connect.
Defaults to the part after `jdbc` in the `uri` or `default.data-source-driver`, if the URN isn't a `jdbc`.
- `user-name`: The user name to authenticate with. Default is vendor specific.
- `password`: The password to authenticate with. Default is vendor specific.
- `pool:min`: The minimum number of connections to keep in the connection pool. Default is vendor specific.
- `pool:initial`: The number of connections that should be opened at startup. Default is vendor specific.
- `pool:max`: The maximum number of connections to keep in the connection pool. Default is vendor specific.
- `pool:age`: The maximum age in some time unit that an unused connection is kept in the pool. Default is vendor specific.
Note that on JBoss this value is configured in minutes, so values below 60 seconds will be rounded to one minute.

Note that the `pool` settings are nested, i.e. they share one `pool` parent tag.

Supported time units:

- `milliseconds`, `millisecond`, `millis`, `milli`, `ms`
- `seconds`, `second`, `s`
- `minutes`, `minute`, `min`

### Variables

Bundles can refer to variables in the `${name}` notation. To escape a `$`, duplicate it to `$$`.

Variable values are:

- system properties,
- variables defined in the configuration [`vars`](#vars), and
- variables passed into bundles (see below).

The deployer fails, if a variable passed-in overwrites an existing variable (esp. system property),
or if the resulting plan has unresolved variables.

A variable name can contain the name of a function to be applied to the value:

- `«x»`: The literal string `x` – useful for, e.g., ` or ` expressions. This quote type (guillemet) has the advantage of being nestable.
- `toUpperCase(x)`: Turns the value of the variable `x` into all upper case.
- `toLowerCase(x)`: Turns the value of the variable `x` into all lower case.
- `toInitCap(x)`: Uppercase the first character and append the rest as is.
- `hostName()`: Returns the DNS name of the local host (without the domain name).
- `domainName()`: Returns the DNS domain of the local host.
- `regex(a, b)`: Apply the regular expression `b` to `a`, returning the first matching group.
- `decrypt(secret)`: Use a key from a keystore to decrypt a secret. See [key-store config](#key-store).
- `decrypt(secret, alias)`: Use a key with a specific alias from a keystore to decrypt a secret. See [key-store config](#key-store).
- `switch(x) body`: Use one of a map of string literals in the body, depending on the value of expression `x`.
For an example, see below.

You can chain variable expressions, by separating them with ` or `.
E.g. `toLowerCase(foo) or bar` will resolve to `baz`, if the variable `foo` is set to `BAZ`,
or fall back to `bar` if `foo` is not set.

The body of the `switch` function maps some labels to string literals, e.g.:

```yaml
password: "${switch(stage)
  dev: «A»
  qa: «B»
  prod: «C»
  }"
```

## Config

The deployer itself can be configured with a file `deployer.config.yaml`.

Restart The Deployer for changes to this file to be picked up.

### `repository`

Where and how to access the repository containing deployables (`war`, etc.) and bundles.

- `type`: `maven-central` or `artifactory`. Defaults to `artifactory`, if it's running on `localhost:8081`, or `maven-central` otherwise.
- `uri`: The base URI of the repository. For the defaults, see `type`.
- `username`: The credentials required by `artifactory`. Defaults to not using auth.
- `password`: The credentials required by `artifactory`. Defaults to not using auth.
- `repository-snapshots`: The name of the snapshot repository. Defaults to `snapshots-virtual`.
- `repository-releases`: The name of the release repository. Defaults to `releases-virtual`.

### `root-bundle`

What root bundle should be used when there is no `deployer.root.bundle`:

| key | value |
| --- | --- |
| name | The name of the root bundle loaded. Defaults to the DNS host name (without the domain or trailing digits). |
| group-id | The `group-id` of the bundle loaded. Defaults to the `default.group-id` or the DNS domain name. |
| classifier | The `classifier` of the bundle loaded. Defaults to null. |
| version | The `version` of the bundle loaded. Defaults to the `version` variable (or fails). |
| shutdown-after-boot | Shut the container down right after the root bundle has been applied. Useful when building, e.g., a Docker file. Defaults to `false`. |

These values can be used in expressions as `root-bundle:name`, etc.

### `manage`

This is a list of resource type names to be managed or `[all]`, i.e. resources of this kind that are deployed in the container, but are not in the plan, are removed (only exception: the Deployer itself).
Defaults to an empty list, i.e. things are left alone.

### `pin`

The list of resources to be skipped, i.e. they won't get removed when managed,
your plan will fail if it contains this resource, and they won't show up when reading the effective plan.

I.e., to pin a deployable `myapp`, use this:

```yaml
pin:
  deployables: [myapp]
```

### `triggers`

These triggers can cause The Deployer to run:

| name | description |
| --- | --- |
| startup | The initial run after the container was booted |
| post | A http POST coming in |
| fileChange | The `deployer.root.bundle` file was changed |

By default all triggers are allowed, but you can limit the allowed triggers in the `deployer.config.yaml`.
E.g., to only allow the `startup` trigger, add:

```yaml
triggers: [startup]
```

If you specify an empty list, i.e. `triggers: []`, The Deployer runs in read-only mode.

### `vars`

This is a map of variables to set.

Special values:

| name | usage |
| --- | --- |
| default.group-id | `group-id` to be used, if none is specified. |
| default.deployable-type | `type` to be used for `deployables`, if none is specified. Defaults to `war`. |
| default.log-level | `level` to be used for `loggers`, if none is specified. This is _not_ used for `log-handlers`! The level of log handlers defaults to `ALL`. |
| default.log-handler-type | `type` to be used for `log-handlers`, if none is specified. Defaults to `periodicRotatingFile`. |
| default.log-format | `format` to be used for `log-handlers`, if none is specified. Defaults to `%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n`. |
| default.log-formatter | `formatter` to be used for `log-handlers`, if none is specified. Defaults to using the `default.log-format`. |
| default.log-encoding | `encoding` to be used for `log-handlers`, if none is specified. Defaults to system default. |
| default.log-file-suffix | `suffix` to be used for file `log-handlers`, if none is specified. Defaults to using the `yyyy-MM-dd` (i.e. daily rotation). |

### `key-store`

The key to be used for the `decrypt` expression.

| name | usage |
| --- | --- |
| path | The file path to the keystore. Mandatory to use `decrypt`. |
| type | The format of the keystore, e.g. `jks` or `jceks`. Defaults to `jks`. Note that you can't store secret keys (i.e. symmetric encryption keys) in `jks`. |
| pass | The password required for the keystore. Defaults to `changeit`, the JDK default. |
| alias | The default name of the key in the keystore. Can be overridden in the call to `decrypt`. Defaults to `secretkey`. |

To encrypt some key, you can use the `main` method in the `CipherFacade` class, e.g. to get the CLI help via Maven:

    mvn exec:java -Dexec.mainClass="com.github.t1.deployer.app.CipherFacade" -Dexec.args="--help"

## Miscellaneous

### Log Levels

The deployer uses the log levels of [slf4j](http://www.slf4j.org):
`ALL`, `ERROR`, `WARN`, `INFO`, `DEBUG`, `TRACE`, and `OFF`.

The JBoss CLI additionally allows log levels from Java Util Logging and more,
so when reading these levels, The Deployer maps them as follows:

| jul | slf4j |
| --- | --- |
| ALL | ALL |
| FATAL | ERROR |
| SEVERE | ERROR |
| WARNING | WARN |
| INFO | INFO |
| CONFIG | INFO |
| FINE | DEBUG |
| FINER | DEBUG |
| FINEST | TRACE |
| OFF | OFF |

gha_language: Java


text:
---
hrs_structure:
  division: '2'
  volume: '10'
  title: '25'
  chapter: '466'
  section: ''
type: chapter
tags:
  - Business
menu:
  hrs:
    identifier: HRS0466
    parent: title25
    name: Chapter 466 Public Accountancy
weight: 79000
title: Public Accountancy
full_title: Chapter 466 Public Accountancy
---
**CHAPTER 466 [OLD]**

**PUBLIC ACCOUNTANCY**

**REPEALED.** L 1973, c 158, §1.

**CHAPTER 466**

**PUBLIC ACCOUNTANCY**

Part I. General Provisions

Section

466-1 Purpose

466-2 Short title

466-3 Definitions

466-4 Board of public accountancy

466-5 License of certified public accountant

466-5.5 Educational requirements for licensure effective

December 31, 2000

466-6 License of public accountant

466-7 Permits to practice

466-8 Fees

466-9 Disciplinary action

466-10 Prohibited acts

466-11 Injunctions against prohibited acts

466-11.5 Single act evidence of practice

466-12 Ownership of accountant's working papers

466-13, 14 Repealed

466-15 Advisory committees

466-17 Construction; severability

Part II. Peer Review Process

466-31 Definitions

466-32 Establishment of peer review process;

confidentiality

466-33 Standards for peer reviews and sponsoring

organizations

466-34 Enrollment and participation

466-35 Peer review compliance reporting form

466-36 Hawaii supplement to the peer review report

466-37 Retention of documents

466-38 Reporting to the board

466-39 Appeals

466-40 Procedures for sponsoring organization

466-41 Oversight of sponsoring organizations

466-42 Peer review oversight committee

466-43 Oversight of peer reviewers for a Hawaii

supplemental peer review

Cross References

Sunset evaluations modified, see §§26H-4 and 26H-5.

repository: SamMade/BlueAndKrabby

repo_name: SamMade/BlueAndKrabby


text:
# CINDER

## Description

The custom CINDER driver provides the ability to manage volumes through Open Stack.

**IMPORTANT:** These files must be patched on machines where `cinder-volume` is installed. Preferably under their own directories.

## Driver

The CINDER driver can be found under `volume/drivers` and should be installed under its respective directory.
After installing the driver, you should restart `cinder-volume`.

repository: yongshengma/framework-cinder-plugin

repo_name: yongshengma/framework-cinder-plugin


text:
# grunt-nodocs

[![NPM](https://nodei.co/npm/grunt-nodocs.png?downloads=true&downloadRank=true&stars=true)](https://nodei.co/npm/grunt-nodocs/)

## Installation

```
npm install grunt-nodocs --save-dev
```

## NpmTask

```
grunt.loadNpmTasks('grunt-nodocs');
```

## nodocs Task

Run this task with the `grunt nodocs` command.

nodocs fills the need for a simple task, to grab comments out of a piece of code and turn them into a markdown file. It's simple and can be done by hand, but what happens when your code is 1000+ lines long?

Also, with markdown being the sole method of writing proper documentation, we assume and encourage the user to write their comments in markdown fashion.

### Comment Syntax Requirements:

- Comments must at least start and end with the conventional block comment tags `/*`, `*/`.
- Each line must start with an `*`.
- There must be a single space between the `*` and the start of your comments.

```javascript
/*
*
* Comments go between the starting and ending comment block lines
*
*/
```

nodocs' algorithm also allows for the user to distinguish between internal comments and external comments. Below we give an example of how to accomplish this. By simply adding another character to the end of the starting comment line you can distinguish between what should only be seen internally and what can be seen by the outside world.

Internal:

```
/**
*
*
*/
```

External:

```
/*
*
*
*/
```

### Default Code Sample:

```javascript
/**
* # This is an internal comment - For internal use.
* # noDocs Markdown Text
*
* ## Isn't this amazing?
*/
noDocsInternal function(){
	//Do Work
}

/*
* # This is an external comment - User specified set of comments that can be seen by the public
* # noDocs Markdown Text
*
* ## Isn't this amazing?
*/
noDocsExternal function(){
	//Do Work
}
```

#### Options

##### src

Type: `[String]`

The file path of the source file.

##### dest

Type: `String`

The file path for the destination of the output file.

##### start

Type: `[String]`

Starting line of comment block. Can be used to distinguish comments that are meant for internal use and comments for external use

##### multiDocs

Type: `Object`

If multiple readme files are wanted, for if someone wants to make a wiki with multiple pages, the multidocs object allows for a user to make a single markdown file per file read into grunt.

###### Properties

|Property|Value|Description|
|-----|-----|-----|
|multiDocs|Bool|True or false to determine single or multi-file output|
|dest|String|Path for markdown output|

## Example - Basic:

```javascript
grunt.initConfig({
	nodocs: {
		internal: {								// Task
			options: {							// Options
				src: 'src/src.js',				// Source Location
				dest: 'internal.md',			// Destination Location
				start: ['/*','/**']			// How the code block starts.
			}
		},
		external: {								// Task
			options: {							// Options
				src: 'src/src.js',				// Source Location
				dest: 'external.md',			// Destination Location
				start: ['/*']					// How the code block starts.
			}
		}
	}
});
loadNpmTasks('grunt-nodocs');
```

## Example - Wildcard:

```javascript
grunt.initConfig({
	nodocs: {
		internal: {								// Task
			options: {							// Options
				src: 'src/*.js',				// Source Location
				dest: 'internal.md',			// Destination Location
				start: ['/*','/**']				// How the code block starts.
			}
		}
	}
});

loadNpmTasks('grunt-nodocs');
```

## Example - Negated Files:

```javascript
grunt.initConfig({
	nodocs: {
		internal: {                                 // Task
			options: {                                // Options
				src: ['src/*', '!src/*.html'],          // Source Location
				dest: 'internal.md',                    // Destination Location
				start: ['/*','/**']                     // How the code block starts.
			}
		}
	}
});

loadNpmTasks('grunt-nodocs');
```

## Example - Multiple README Files:

```javascript
grunt.initConfig({
	nodocs: {
		internal: {                                 // Task
			options: {                                // Options
				src: ['src/*', '!src/*.html'],          // Source Location
				dest: 'internal.md',                    // Destination Location
				start: ['/*','/**'],                     // How the code block starts.
				multiDocs: {					// Multiple README Files for each file read in
					multiFiles: true,
					dest: 'test/'
				}
			}
		}
	}
});
```
# Release History:
- 2016-06-13 v1.0.2 Peer Dependencies updated for grunt.
- 2016-06-13 v1.0.1 Fixed a few bugs in the case of a user not specifying certain options. Also added in more checks to make sure options are present. Fixed issues with multi-file and single file options.
- 2016-06-13 v1.0.0 Added multi-file options. One markdown file generated for every js file specified. Minor cleanup to code. Added statistics badge.
- 2015-09-08 v0.0.11 Integrated wildcard functionality into src location option. Users can now specify a directory with multiple javascript files.
- 2015-06-29 v0.0.10 Words are still hard...spelling mistakes
- 2015-06-29 v0.0.9 Refactored code for better self-documenting/human readable code. Fixed a bug with trimming each line(in case of code blocks and other formatting techniques).
- 2015-06-29 v0.0.8 File rename
- 2015-06-29 v0.0.7 Removed outer for loop to check for starting comment markers. Now checks against hash to write comments in the correct order.
- 2015-06-24 v0.0.6 Made option:start an array again to allow for multiple sweeps of the code instead of multiple tasks and updated documentation
- 2015-06-23 v0.0.5 Updated documentation...words can be hard.
- 2015-06-23 v0.0.4 Updated bugs in example config
- 2015-06-23 v0.0.3 Removed outer for loop for [start] and changed [start] to just a start string
- 2015-06-22 v0.0.2 Fixed a bug with checking for start of comment block
- 2015-06-22 v0.0.1 Initial Release

repository: doverthere/grunt-nodocs

repo_name: doverthere/grunt-nodocs


text:
---
layout: default
---

# 1993-07-17 - Diffie Hellman

## Header Data

From<EMAIL_ADDRESS>(Norman Hardy)

To<EMAIL_ADDRESS>Message Hash:<PHONE_NUMBER>8e98384e96c239726229748c61478722a569433c050918d7440e66

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1993-07-17 21:14:47 UTC

Raw Date: Sat, 17 Jul 93 14:14:47 PDT

## Raw message

```
{% raw  %}From<EMAIL_ADDRESS>(Norman Hardy)
Date: Sat, 17 Jul 93 14:14:47 PDT
To<EMAIL_ADDRESS>Subject: Diffie Hellman
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

What is the best reference to the Diffie Hellman key
exchange algorithm? (Preferably on line)
Thanks

{% endraw %}
```

## Thread

+ Return to [July 1993](/archive/1993/07)

+ Return to<EMAIL_ADDRESS>(Norman Hardy)](/authors/norm_at_netcom_com_norman_hardy_)"

+ 1993-07-17 (Sat, 17 Jul 93 14:14:47 PDT) - Diffie Hellman -<EMAIL_ADDRESS>(Norman Hardy)_


text:
# IE-Poly

IE-Poly is a JS polyfill library for "DOM Element Object" methods that are not supported in some versions of Microsoft's Internet Explorer browser. Errors for methods have also been added in to ensure the user is using proper argument types as well as the correct number of arguments for the method to function as expected.

## To Use:

Pass a reference of a "DOM Element Object" to the "ie()" function constructor to gain access to the polyfill methods, like so:

```javascript
var domNode = document.getElementById("myDomNode");

ie(domNode).addEventListener('onclick', function(){console.log('node clicked')})

ie(domNode).classList.remove("class1", "class2");
```

## Polyfills added so far:

addEventListener

removeEventListener

The classList property with its returned DOMTokenList Object polyfill, along with methods: add, remove, item, contains

repository: daniel-warner/ie-poly

repo_name: daniel-warner/ie-poly


text:
# React Hooks Practice

[![Author](https://img.shields.io/badge/author-hwhang0917-green?style=flat)](https://github.com/hwhang0917/react-hooks-practice)
[![License](https://img.shields.io/github/license/hwhang0917/react-hooks-practice)](https://github.com/hwhang0917/react-hooks-practice/blob/master/LICENSE)

> Collection of React Hooks ready to be installed with NPM

---

## React Hook Checklist

- [x] useInput
- [x] useTabs
- [x] useTitle
- [x] useClick
- [x] useHover
- [x] useConfirm
- [x] usePreventLeave
- [x] useBeforeLeave
- [x] useFadeIn
- [x] useNetwork
- [x] useScroll
- [x] useFullScreen
- [x] useNotification
- [x] useAxios


text:
# Source for EECS-E6895 Project

## Building
This project uses Maven. To build a (clean) install, use the following command
from the top directory (i.e., where ```pom.xml``` is located):
```
mvn clean install
```


text:
#finagle-aws

A module for making life a little easier when talking to AWS via Finagle.

       import com.heroku.finagle.aws.S3.{S3Secret, S3Key}
       import com.heroku.finagle.aws.{Get, Put, S3}
       import com.twitter.util.Future
       import org.jboss.netty.buffer.ChannelBuffers
       import org.jboss.netty.handler.codec.http.HttpResponse
       import org.jboss.netty.util.CharsetUtil

       class Readme {

         val s3key = S3Key("...")

         val s3Secret = S3Secret("...")

         val client = S3.client(s3key, s3Secret)

         val buffer = ChannelBuffers.wrappedBuffer("SOME BYTES".getBytes(CharsetUtil.UTF_8))

         val put: Future[HttpResponse] = client(Put("theBucket", "objectName", buffer))

         val get: Future[HttpResponse] = client(Get("theBucket", "objectName"))

       }

##License

    Copyright 2001-2012 Scott Clasen<EMAIL_ADDRESS>
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

repository: sclasen/finagle-aws

gha_language: Scala

repo_name: sclasen/finagle-aws


text:
# Earth In GLFW

## Intruduction

An opengl demo based on GLFW

## Requirement

+ gcc/clang
+ cmake
+ SDL2_image 2.0.0+
+ glfw3

## How to Install Dependencies

### Install Homebrew

Please read this page: <https://brew.sh/>

```
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
```

### Install Dependencies

```
$ brew install cmake SDL2_image glfw3
```

## How To Use it

[![asciicast](https://asciinema.org/a/121663.png)](https://asciinema.org/a/121663)

repository: yuikns/gl-earth

repo_name: yuikns/gl-earth


text:
# Automatic Differentiation

[![Travis](https://travis-ci.org/CyberZHG/toy-auto-diff.svg)](https://travis-ci.org/CyberZHG/toy-auto-diff)
[![Coverage](https://coveralls.io/repos/github/CyberZHG/toy-auto-diff/badge.svg?branch=master)](https://coveralls.io/github/CyberZHG/toy-auto-diff)

## Install

```bash
pip install toy-auto-diff
```

## Document

See [doc](https://cyberzhg.github.io/toy-auto-diff/).

repository: turiya/toy-auto-diff

repo_name: turiya/toy-auto-diff


text:
The code changes I've used to achieve Azure AD common endpoint support from [oidc-client](https://github.com/IdentityModel/oidc-client-js) library in our authentication service.

The prime reason for using this is related to the [issue](https://github.com/IdentityModel/oidc-client-js/issues/724), which apparantly is a support which they can't add due to specification criteria. To support common endpoint, we've used the same [ResponseValidator](https://github.com/IdentityModel/oidc-client-js/blob/dev/src/ResponseValidator.js) v2.0 from<EMAIL_ADDRESS>library and made a minor tweak to be used as our custom response validator. The files that ResponseValidator depends on is also utilized.

Feel free to contribute to keep this robust

# Changes
The changes made in the source code to get things working are

Made the following change in ResponseValidator.js
```
    if(issuer.indexOf('{tenantid}') > -1) { // for azure ad common end point
        issuer = this._joseUtil.parseJwt(response.id_token).payload.iss;
    }

```

# Usage
The Custom ResponseValidator is then used while initializing as follows
```
        const settings: UserManagerSettings = {
            .
            .
            .
            ResponseValidatorCtor: ResponseValidator
        };
```


text:
# Select
Select has the capability to pick out fields to be returned by the database

```js
select(...keys)
```

Example :

```js
Collection()
 .select('createdAt', 'name', 'foobar')
 .where('createdAt', '<=', new Date())
 .cursor()
```

repository: patrickml/singularity

gha_language: JavaScript

repo_name: patrickml/singularity


text:
---
title: |
    223 Behold! the mountain of the Lord. - Hymns for the Poor of the Flock
metadata:
    description: |
        Hymns for the Poor of the Flock 223. Behold! the mountain of the Lord.. Behold! the mountain of the Lord In latter days shall rise, On mountain tops above the hills, And draw the wond’ring eyes.
    keywords:  |
        Hymns for the Poor of the Flock, adventhymnals, advent hymnals, Behold! the mountain of the Lord., Behold! the mountain of the Lord,
    author: Brian Onang'o
---

#### Advent Hymnals
## 223. Behold! the mountain of the Lord.
####  Hymns for the Poor of the Flock

```txt
1. Behold! the mountain of the Lord
In latter days shall rise,
On mountain tops above the hills,
And draw the wond’ring eyes.

2. To this the joyful nations round,
All tribes and tongues, shall flow;
“Up to the hill of God,” say they,
“And to His house we’ll go.”

3. The beam that shines from Sion’s hill,
Shall lighten ev’ry land;
The King who reigns in Salem’s tow’rs
Shall all the world command.

4. Among the nations He shall judge;
His judgments truth shall guide:
His sceptre shall protect the just,
And quell the sinner’s pride.

5. No strife shall rage, nor hostile feuds
Disturb those peaceful years;
To plough-shares men shall beat their swords,
To pruning-hooks their spears.2 24

6. No longer hosts encount’ring hosts,
Shall crowds of slain deplore;
They hang the trumpet in the hall,
And study war no more:—

7. For now, O Israel, thou art call’d
To worship at His shrine;
And, walking in the light of God,
In all His grace to shine.
```

repository: GospelSounders/adventhymnals

repo_name: GospelSounders/adventhymnals


text:
# UART Device Service
## Overview
This Device Service is a reference example of a Device Service developed with **[Go Device Service SDK](https://github.com/edgexfoundry/device-sdk-go)**.

- Function:
  - It is developed for universal serial device, such as USB to TTL serial port, rs232 interface and rs485 interface device.  It provides REST API interfaces to communicate with serial sensors or configure them.
- Characteristics:
  - Universal serial port
- Physical interface: TTL, RS232, RS485, USB to TTL
- Driver protocol: UART

## Usage
- This Device Service have to run with other EdgeX Core Services, such as Core Metadata, Core Data, and Core Command.
- After starting the service, the linux uart device will be opened and configured(defalut: /dev/ttyUSB0 with 115200bps). User can choose another uart device by sending "uartconfig" command.
- When uart device is opend,  the data sent from another sensors will be stored and they can be read by "gethex" or "getstring" command. User can also sends down link data to those sensors by "sendhex" or  "sendstring" command.

## REST API

| Method | Core Command | parameters                         | Description                                                  | Response                                       |
| ------ | ------------ | ---------------------------------- | ------------------------------------------------------------ | ---------------------------------------------- |
| get    | gethex       |                                    | Get serial device data, output in hex string format          | "{"rxbuf hex":"32333437383536"}"               |
| get    | getstring    |                                    | Get serial device data, output in ascii string format        | "{"rxbuf string":"aadd33"}"                    |
| put    | sendhex      | {"sendhex":<txbuf>}                | Send data to the serial device, input in hex string format   | 200 ok                                         |
| put    | sendstring   | {"sendstring":<txbuf>}             | Send data to the serial device, input in ascii string format | 200 ok                                         |
| get    | uartconfig   |                                    | Get serial port configuration parameters                     | "{"baud":"9600","device path":"/dev/ttyUSB5"}" |
| put    | uartconfig   | {"path":<path>,<br/>"baud":<baud>} | Configure serial port parameters                             | 200 ok                                         |

## License
[Apache-2.0](LICENSE)

repository: jxit/edgex-examples

repo_name: jxit/edgex-examples


text:
# Node.js  Diagnostics WorkGroup Meeting 2022-10-11

## Links

* **Recording**:  https://www.youtube.com/watch?v=o2tBFhRWO7g
* **GitHub Issue**: https://github.com/nodejs/diagnostics/issues/592
* **Minutes Google Doc**: https://docs.google.com/document/d/1utEDIAUXoLFCPdqorSLacHlpdo5j4F20tDwf2Kum938/edit

## Present

* Diagnostics team: @nodejs/diagnostics
* Stephen Belanger @qard
* Rafael Gonzaga @rafaelgss
* Tony Gorez @tony-go
* Yagiz Nizipli @anonrig
* Gireesh Punathil @gireeshpunathil
* Anton Whalley @No9

## Agenda

## Announcements

*Extracted from **diag-agenda** labelled issues and pull requests from the **nodejs org** prior to the meeting.

### nodejs/diagnostics

* llnode - Current Status  [#576](https://github.com/nodejs/diagnostics/issues/576)
  * anton: number of PRs opened (by Keyhan) as part of the review / workshop in the collab summit -  promise support, missing features for v16 and documentation (Tony).
  * tony: I had a answer from apple regarding the lldb issue, I’ll publish it on the issue.
  * rafael: I could take documentation issue maybe in 2 or 3 weeks

* User Journey tracking documentation [#502](https://github.com/nodejs/diagnostics/issues/502)
  * rafael: Remove the item “native tools” from the “profiling” section

* reportVersion semantics are not defined [#349](https://github.com/nodejs/diagnostics/issues/349)
  * gireesh: consensus on the single digit version semantics, that bumps when there is a structural change in the report. Raise PR in the core to this effect.

* diagnostics_channel additions:
   for working group awareness and review:
  * storage channel [#44943](https://github.com/nodejs/node/pull/44943)
  * tracing channel [#44894](https://github.com/nodejs/node/pull/44894)
  * https://github.com/nodejs/node/pull/44340

## Q&A, Other

## Upcoming Meetings

* **Node.js Project Calendar**: <https://nodejs.org/calendar>

Click `+GoogleCalendar` at the bottom right to add to your own Google calendar.

repository: nodejs/diagnostics

branch_name: refs/heads/main

repo_name: nodejs/diagnostics


text:
# isaac_sdk_docker

## Introduction
This is Dockerfile to use [NVIDIA Isaac SDK](https://developer.nvidia.com/isaac-sdk) on Docker container.

## Requirements
- NVIDIA graphics driver >= 440.0
- Docker
- nvidia-docker2

## Preparation
### Download NVIDIA Isaac SDK
Please download NVIDIA Isaac SDK from <https://developer.nvidia.com/isaac-sdk>.
And, please put NVIDIA Isaac SDK in the same directory as the Dockerfile.
This time, I used the following package.

- `isaac-sdk-20200527-0159e2bab.tar.xz`
- `isaac_sim_unity3d-20200527-a8205d23.tar.xz`

### Build Docker image
```
$ docker build -t isaac_sdk .
```

### Create Docker container
```
$ ./launch_container.sh
```

## Running sample application
### Build sample application
```
$ cd ~/isaac_sdk
$ bazel build //apps/samples/stereo_dummy
```

### Running sample application
```
$ bazel run //apps/samples/stereo_dummy
```

### Open the visualization
Please open the visualization frontend by opening <http://localhost:3000>. in a browser.

## Running IsaacSim and Carter navigation stack
### Running IsaacSim
```
$ cd ~/isaac_sim_unity3d/builds
$ ./sample.x86_64 --scene small_warehouse -logFile -
```

### Running Carter navigation stack
```
$ cd ~/isaac_sdk
$ bazel run //apps/navsim:navsim_navigate
```

### Open the visualization
Please open the visualization frontend by opening <http://localhost:3000> in a browser.

## Reference
- https://developer.nvidia.com/isaac-sdk
- https://docs.nvidia.com/isaac/isaac/doc/index.html
- https://docs.nvidia.com/isaac/isaac/doc/getting_started.html#tutorials-and-sample-applications
- https://docs.nvidia.com/isaac/isaac/doc/simulation/unity3d.html#warehouse-navigation


text:
# oBundle-Test

I have added a product in a new catagory. The product I have added has two pictures. When you hovered it will show you the second pic.
Then, I have added a button at the top of the catagory page. When you click the button will be added to the cart and it will notify you that the product has been added.
Next, I again added another button which which delete every item in the cart and notify the customer.
Finally, I added a banner that shows customer login details (First and Last name)

URL - https://obundle-test64.mybigcommerce.com/
Preview Code: ngqrhylyk6

repository: MussieBez/oBundle-Test

repo_name: MussieBez/oBundle-Test


text:
---

layout: post
title: Cube
date: Thu Nov 16 2017
image:
  link: /posts/cube/presentation.png

---

This blog post presents the little toy I made while exploring the HTML5's
canvas and a cube's visualisation with changing perspectives.

You can see the result here: [Cube](https://nobe4.fr/cube/).

# Preparing the canvas and brushes

Let start with the canvas wrapper, the non-cube side of the project.

After getting the canvas and its context, we set fixed sizes for various
elements of the page:

```javascript
const canvas = document.getElementById("canvas");
const ctx = canvas.getContext("2d");
const HEIGHT = canvas.height;
const WIDTH = canvas.width;
const pointSize = 10;
var debug = true;
var step = 0;
```

Next, a few different functions to clear/display stuff on the canvas:

```javascript
function clearCanvas(){
	ctx.fillStyle = 'white';
	ctx.fillRect(0, 0, WIDTH, HEIGHT);
}

function drawPoint(point){
	ctx.fillStyle = 'black';
	ctx.fillRect(point.x - pointSize/2, point.y - pointSize/2, pointSize, pointSize);
}

function drawLines(lines, debug){
	if(debug){
		ctx.strokeStyle = 'grey';
		ctx.setLineDash([4, 4]);
		ctx.lineWidth=1;
	} else {
		ctx.strokeStyle = 'black';
		ctx.setLineDash([]);
		ctx.lineWidth=3;
	}
	ctx.beginPath();
	lines.forEach(points => {
		ctx.moveTo(points[0].x, points[0].y);
		ctx.lineTo(points[1].x, points[1].y);
	});
	ctx.stroke();
}
```

The `drawLines` functions will be used to print the debug lines and the cube's
lines, with different styles. Also, since we're displaying a large number of
lines, we can do this in one stroke.

Next, let see the mouse handling, wrapped into 3 little functions. The first of is the `proxyEvent`:

```javascript
function proxyEvent(event, callback){
	canvas[event] = (e) => callback(e.pageX - canvas.offsetLeft, e.pageY - canvas.offsetTop);
}
```

This function will add a new listener to the canvas and will callback the
passed function with the `x` and `y` of the canvas, and not the page.  It's
used like so:

```javascript
function generateMouseMoveHandler(point){
	proxyEvent('onmousemove', function(x, y){
		point.x = x;
		point.y = y;
	});

	// Mouse up clears the mouse move handle.
	canvas.onmouseup = () => canvas.onmousemove = undefined;
}

proxyEvent('onmousedown', function(x, y){
	if(distanceTo(x, y, handle1) < 300) {
		generateMouseMoveHandler(handle1);
	} else if(distanceTo(x, y, handle2) < 300) {
		generateMouseMoveHandler(handle2);
	} else if(distanceTo(x, y, handle3) < 300) {
		generateMouseMoveHandler(handle3);
	}
});
```

For the `mousedown` we're using the proxy to compare the mouse's coordinate
with the three handles, and calling `generateMouseMoveHandler`, which is really
a `grab that handle` function.

It's adding, using the proxy, a `mousemove` event and setting the new position
of the point. Also, when the `mouseup` event is called, the previously defined
`mousemove` handler is removed.

Finally, the obligatory `requestAnimationFrame`, as simple as:

```javascript
(function animationFrame() {
	window.requestAnimationFrame(animationFrame);
	render();
})()
```

And a few event handlers, nothing too much.

```javascript
changeDebug = e => debug = e.checked;
changeStep  = s => {
	step = s;
	document.getElementsByClassName('displayed')[0].classList.remove('displayed');
	document.getElementById('step'+step).classList.add('displayed');
}
```

# A happy little cube

Now on the cube's side, and let's start with the render function:

```javascript
function render(){
	clearCanvas();

	middle1 = computeMiddle(handle1, center)
	middle2 = computeMiddle(handle2, center)
	middle3 = computeMiddle(handle3, center)

	intersection1 = computeIntersection(handle1, middle2, handle2, middle1)
	intersection2 = computeIntersection(handle2, middle3, handle3, middle2)
	intersection3 = computeIntersection(handle1, middle3, handle3, middle1)

	center2 = computeIntersection(handle1, intersection2, handle2, intersection3);

	// Draw stuff
	// ...
}
```

I won't get into the drawing part, it's only a matter of `drawPoint` and
`drawLines`, what's interesting is the logic to attain the cube's points.

First, the three handles are really the three vanishing points of the scene,
and the only fixed point of the cube is the "front center". We can get corners
linked to the center by taking the middle point of the "center/vanishing point"
line. This is done with rather simple vector calculus:

```javascript
function computeMiddle(point1, point2){
	return {
		x: point2.x/2 + point1.x/2,
		y: point2.y/2 + point1.y/2,
	};
}
```

Then, we need the first "parallel" lines. Parallel is quoted here because
although a cube has parallel lines, in the 3-vanishing-points-perspective none
of those lines are parallels. They are built by joining the middle points with
the handles. We get from this all the "front" and "top" vertex. Ultimately
where the "top"/"front" is depends on how you view the cube. This doesn't
involve any math, because we're not creating any new points.

The next step is to get the intersections for the back points, this is done with the following piece of code:

```javascript
function computeIntersection(point1, point2, point3, point4){
	let d = (point1.x - point2.x)*(point3.y - point4.y) - (point3.x - point4.x)*(point1.y - point2.y);
	let t = (point1.x*point2.y-point1.y*point2.x)/d;
	let s = (point3.x*point4.y-point3.y*point4.x)/d;

	return {
		x: (point3.x-point4.x)*t-(point1.x-point2.x)*s,
		y: (point3.y-point4.y)*t-(point1.y-point2.y)*s
	};
}
```

This is an adaptation of the formula found
[here](https://en.wikipedia.org/wiki/Line%E2%80%93line_intersection#Given_two_points_on_each_line).
This function will allows us to find all the "back" points, the center and the
three corners, completing the cube.

We can now trace all the vertex and our cube is complete.

Again to see the result, go here: [https://nobe4.fr/cube](https://nobe4.fr/cube).


text:
# Getting Started
## Tutorials
Watch the video here -

https://www.typescriptlang.org/

https://facebook.github.io/react/tutorial/tutorial.html

https://egghead.io/lessons/javascript-mobx-and-react-intro-syncing-the-ui-with-the-app-state-using-observable-and-observer

# Folder Structure
<pre>
src
|
package.json --> The top level package file is for installing dev/test node module dependencies.
   |
   node_modules --> This folder contains all the installed node modules for dev dependencies.
     |
   dist -> This folder contains all assets needed to run the app.
     |
     resources
       |
       app -> The folder where html/js/css etc need to be placed.
        |
        package.json --> This package file lists all distributable dependencies.
</pre>

# Adding Node Modules
OneBranch does not support NPM at the moment.
To add new node module dependencies:

1. Before you add a new package, clear it with LCA using http://aka.ms/osstool. Usually this process is instant and automated.
* Decide whether this is a dev dependency or a dist dependency. A dev dependency is a package required for building/testing like gulp, electron-winstaller, etc. A dist dependency is on packages you intend to ship with orb like react, mobx etc.
* For a dev dependency,
   i. In the src folder, run npm install --save-dev <packageName>
* For a dist dependency, in the app folder, run run npm install --save <packageName>
* cd node_modules_Dev_nuget or cd node_modules_Dist_nuget
* Update the PackageVersion in nuproj
* Run build under node_modules_Dev_nuget or cd node_modules_Dist_nuget
* This creates a manual nuget package that should be pushed to the OneBranch nuget store using the following steps:
   i. Copy the nuget package to \\wanuget\DevStaging. This automatically pushes the package to the nuget store.
* Run 'corext' to modify the corext config file to reference the new version of the package

DO NOT Skip steps the last few steps since these are required for official builds to succeed!!!

# Install typings.
Typeings are required to transpile tsx/ts files to plain js.

In the app folder, run
```
  typings install dt~package --save --global
```

or

```
  typings install package --save
```

You can also check in any typing file directly obtained from npm, github, etc.
If you cannot find typings, you can create your own modules in typings\custom.d.ts.
Alternatively, you can skip the need for typings by using "require" directly in your typescript files.
Example:

```
  const Markdown = require('react-remarkable');
```

# Debugging
Launch orb by typing "orb".
To bring up the chrome dev tools, use Ctrl+Shift+D.
You can hit F5 in the debug tools to refresh without restarting after code changes.
You can "disable cache (while DevTools is open)" and hitting F5 in the debugger reloads the app without restarting.

# Building
To enable compile on save, in VSCode, run Ctrl+Shift+B once. The watcher task will auto compile on any *ts* file modifications.
For a local build, type "b"
To enable official builds (creates installer, etc), type "official" followed by "b". To reset, type "noOfficial"

# Logging
loglevel replaces console.log() and friends with level-based logging and filtering, with none of console's downsides.

Usage:
```javascript
  let log = require('loglevel');
  log.info("unreasonably simple");
```

5 actual logging methods, ordered and available as:
```javascript
  log.trace(msg);
  log.debug(msg);
  log.info(msg);
  log.warn(msg);
  log.error(msg);
```

Documentation - https://github.com/pimterry/loglevel

An h1 header
============

Paragraphs are separated by a blank line.

2nd paragraph. *Italic*, **bold**, and `monospace`. Itemized lists
look like:

  * this one
  * that one
  * the other one

Note that --- not considering the asterisk --- the actual text
content starts at 4-columns in.

> Block quotes are
> written like so.
>
> They can span multiple paragraphs,
> if you like.

Use 3 dashes for an em-dash. Use 2 dashes for ranges (ex., "it's all
in chapters 12--14"). Three dots ... will be converted to an ellipsis.
Unicode is supported. ☺

An h2 header
------------

Here's a numbered list:

 1. first item
 2. second item
 3. third item

Note again how the actual text starts at 4 columns in (4 characters
from the left side). Here's a code sample:

    # Let me re-iterate ...
    for i in 1 .. 10 { do-something(i) }

As you probably guessed, indented 4 spaces. By the way, instead of
indenting the block, you can use delimited blocks, if you like:

~~~
define foobar() {
    print "Welcome to flavor country!";
}
~~~

(which makes copying & pasting easier). You can optionally mark the
delimited block for Pandoc to syntax highlight it:

```python
import time
# Quick, count to ten!
for i in range(10):
    # (but not *too* quick)
    time.sleep(0.5)
    print i
```

### An h3 header ###

Now a nested list:

 1. First, get these ingredients:

      * carrots
      * celery
      * lentils

 2. Boil some water.

 3.

Notice again how text always lines up on 4-space indents (including
that last line which continues item 3 above).

Here's a link to [a website](http://foo.bar), to a [local
doc](main2.md), [local
doc2](../main3.md), [local
doc3](docs/main3.md), [local
doc4](docs\main4.md) and to a [section heading in the current
doc](#an-h2-header). Here's a footnote [^1].

[^1]: Footnote text goes here.

Tables can look like this:

First Header | Second Header
------------ | -------------
Content from cell 1 | Content from cell 2
Content in the first column | Content in the second column

Table: Shoes, their sizes, and what they're made of

(The above is the caption for the table.) Pandoc also supports
multi-line tables:

--------  -----------------------
keyword   text
--------  -----------------------
red       Sunsets, apples, and
          other red or reddish
          things.

green     Leaves, grass, frogs
          and other things it's
          not easy being.
--------  -----------------------

A horizontal rule follows.

***

Here's a definition list:

apples
  : Good for making applesauce.
oranges
  : Citrus!
tomatoes
  : There's no "e" in tomatoe.

Again, text is indented 4 spaces. (Put a blank line between each
term/definition pair to spread things out more.)

Here's a "line block":

| Line one
|   Line too
| Line tree

and images can be specified like so:

Inline math equations go in like so: $\omega = d\phi / dt$. Display
math should get its own line and be put in in double-dollarsigns:

$$I = \int \rho R^{2} dV$$

And note that you can backslash-escape any punctuation characters
which you wish to be displayed literally, ex.: \`foo\`, \*bar\*, etc.

repository: microsoft/Orb

repo_name: microsoft/Orb


text:
# PEP 503 Simple Repository from routing rules

Install simpleindex ([pipx](https://pipxproject.github.io/pipx/) is recommended):

```
$ pipx install simpleindex
```

Generate distributions:

```
$ tree .
.
├── configuration.toml
├── uranusjr-core
│   ├── uranusjr_core-1.0.py3.none-any.whl
│   └── uranusjr_core-2.0.py3.none-any.whl
└── uranusjr-web
    └── uranusjr_web-2.0.py3.none-any.whl
```

Write a configuration:

```toml
# ./configuration.toml

# Serve local files for packages with prefix "uranusjr-".
[routes."uranusjr-{subproject}"]
source = "path"
to = "./uranusjr-{subproject}"

# Otherwise use PyPI.
[routes."{project}"]
source = "http"
to = "https://pypi.org/simple/{project}/"

[server]
host = "<IP_ADDRESS>"
port = 8000
```

Run the server:

```
$ simpleindex /path/to/configuration.toml
```

Install projects:

```
$ python -m pip install -i http://<IP_ADDRESS>:8000 uranusjr-web
```

## Custom route types

`simpleindex` can be made aware of new route types via the `simpleindex.routes` [entry point] group.

[entry point]: https://setuptools.readthedocs.io/en/latest/userguide/entry_point.html#advertising-behavior

A new route type should subclass `simpleindex.routes.Route`, and implement behaviour to respond to HTTP requests.

The `Route` instance has two attributes:

* `root`: A `pathlib.Path` pointing to the directory containing the configuration file current being served.
* `to`: The `to` string in the configuratio block.

For example, here's how you might want to implement Amazon S3 support:

```python
# simpleindex_s3.py

from simpleindex.routes import Response, Route

class AmazonS3Route(Route):
    async def get_page(self, params: dict[str, Any]) -> Response:
        # "params" is a mapping of parameters captured from the URL.
        s3_bucket = self.to.format(**params)
        list_of_files = _list_s3_files(s3_bucket)
        html = _create_html_for_files(list_of_files)
        return Response(status_code=200, content=html, media_type="text/html")
```

`Response` accepts an optional argument `headers` if you want to add additional response headers.

Now add the class to the entry point group:

```ini
# setup.cfg

[options.entry_points]
simpleindex.routes =
    s3 = simpleindex_s3:AmazonS3Route
```

You'll be able to use `source = "s3"` in the a `routes` block after installing the package:

```
$ pipx inject simpleindex simpleindex-s3
```

repository: AndyBryson/simpleindex

repo_name: AndyBryson/simpleindex


text:
# Architecture Overview

This is a short architectural overview of Tremor.

## Scope

We cover the runtime, data and distribution model of Tremor from 50,000 feet.

## Goodness of fit

Tremor is designed for high volume messaging environments and is good for:

- Man in the middle bridging - Tremor is designed to bridge asynchronous upstream sources with synchronous downstream sinks. More generally, Tremor excels at intelligently bridging from sync/async to async/sync so that message flows can be classified, dimensioned, segmented, routed using user defined logic whilst providing facilities to handle back-pressure and other hard distributed systems problems on behalf of its operators.
  - For example - Log data distributed from Kafka to ElasticSearch via Logstash can introduce significant lag or delays as logstash becomes a publication bottleneck. Untimely, late delivery of log data to the network operations centre under severity zero or at/over capacity conditions reduces our ability to respond to major outage and other byzantine events in a timely fashion.
- In-flight redeployment - Tremor can be reconfigured via it's API allowing workloads to be migrated to/from new systems and logic to be retuned, reconfigured, or reconditioned without redeployment.
- event processing - Tremor adopts many principles from DEBS ( Distributed Event Based Systems ), ESP ( Event Stream Processor ) and the CEP ( Complex Event Processing ) communities. However in its current state of evolution Tremor has an incomplete feature set in this regard. Over time Tremor MAY evolve as an ESP or CEP solution but this is an explicit non-goal of the project.

## Tremor URLs

Since Tremor v0.4, all internal artefacts and running instances of **onramps**, **offramps** and **pipelines** are dynamically configurable. The introduction of a dynamically configurable deployment model has resulted in the introduction of Tremor URLs.

The Tremor API is built around this URL and the configuration space it enshrines:

| Example URL                  | Description                                                                                |
| ---------------------------- | ---------------------------------------------------------------------------------------------------------- |
| `tremor://localhost:9898/`   | A local Tremor instance
_ Accessible on the local host
_ REST API on port 9898 of the local host |
| `tremor:///`                 | The current Tremor instance or 'self'                                                                      |
| `tremor:///pipeline`         | A list of pipelines                                                                                |
| `tremor:///pipeline/bob`     | The pipeline identified as bob                                                                             |
| `tremor:///onramp/alice`     | The onramp identified as Alice                                                                             |
| `tremor:///binding/talk`     | A binding that allows alice and bob to connect                                                             |
| `tremor:///binding/talk/tls` | An active conversation or instance of a talk between alice and bob                                         |
|                              |                                                                                |

The Tremor REST API and configuration file formats also follow the same URL format.

In the case of configuration, a shorthand URL form is often used. In the configuration model, we discriminate artefacts by type, so it is often sufficient to infer the `tremor:///{artefact-kind}` component when specifying ( configuring ) artefacts.

In bindings, however, we minimally need to use the full URL path component ( for example:`/pipeline/01` ).

At this time, the full URL form is not used in the configuration model.

## Runtime model

The Tremor runtime is composed of multiple internal components that communicate via queues across multiple threads of control managed/coordinated by a set of control plane actors driven by the Tremor REST API.

### Processing model

Tremor uses an async task model ontop of the [smol runtime](https://github.com/stjepang/smol) and
[async-rs](https://async.rs/).

Currently, the model is:

- A task is spawned per onramp
- A task is spawned per offramp
- A task is spawned per pipeline
- Tasks communicate via queues

The Processing model is very likely to evolve over time as concurrency, threading, async and other primitives available in the rust ecosystem mature and evolve.

## Event ordering

Events generally flow from onramps, where they are ingested into the system, through pipelines, into offramps where they are pushed to external systems.

Tremor imposes causal event ordering over ingested events and processes events deterministically. This does not mean that Tremor imposes a total ordering over all ingested events, however ( ugh, because that is not tractable in a distributed system ).

Events flowing into Tremor from multiple onramps are considered independent. Events flowing from multiple clients into Tremor are also considered independent.

However, events sent by a _specific_ client through a _specific_ onramp into a _passthrough_ pipeline would flow through Tremor in their origin order and be passed to offramps in the same _origin_ order.

Requests from multiple independent sources over the same pipeline may arbitrarily interleave, but should not re-order.

In pipelines, events are processed in depth first order. Where Tremor operators have no intrinsic ordering ( such as a branch split ), Tremor internally _imposes_ an order.

Operator's may _arbitrarily_ reorder messages. For example, a windowed operator might batch multiple events into a single batch. An iteration operator could reverse the batch and forward individual unbatched events in an order that is the reverse of the original ingest order for that batch of events.

However, the engine itself does not re-order events. Events are handled and processed in a strictly deterministic order by design.

## Pipeline Model

The core processing model of Tremor is based on a directed-acyclic-graph based dataflow model.

Tremor pipelines are a graph of vertices ( nodes, or operators ) with directed edges ( or connections, or links ) between operators in the graph.

Events from the outside world in a Tremor pipeline can only flow in one direction from inputs ( specific operators that connect pipeline operators to onramps ) via operators to outputs ( specific operators that connect pipeline operators to offramps).

Operators process events and may produce **zero or many** output events for each event processed by the operator. As operators are the primary building block of Tremor processing logic they are designed for extension.

Tremor pipelines understand three different types of events:

- Data events - these are data events delivered via onramps into a pipeline or to offramps from a pipeline. Most events that flow through a Tremor pipeline are of this type.
- Signal events - these are synthetic events delivered by the Tremor runtime into a pipeline under certain conditions.
- Contraflow events - these are synthetic events delivered by the Tremor runtime into a pipeline under certain conditions that are caused by the processing of events already in a Tremor system. Back-pressure events exploit contraflow.

### Dataflow

Data-flow events are the bread and butter of Tremor.

These are line of business data events ingested via onramps from external upstream systems, processed through pipelines and published downstream via offramps to downstream external systems.

### SignalFlow

Transparent to pipeline authors, but visible to onramp, offramp and operator developers are signal events. Signal events are synthetic events generated by the tremor-runtime and system that can be exploited by operators for advanced event handling purposes.

### Contraflow

A core conceit with distributed event-based systems arises due to their typically asynchronous nature. Tremor employs a relatively novel algorithm to handle back-pressure or other events that propagate _backwards_ through a pipeline.

But pipelines are directed-acyclic-graphs ( DAGs ), so how do we back-propagate events without introducing cycles?

The answer is:

- There can be no cycles in a DAG
- DAGS are traversed in depth-first-search ( DFS ) order
- There can be no cycles in a DAG traversed in reverse-DFS order.
- If we join a DAG d, with its mirrored ( reversed ) DAG d'
  - We get another DAG where
    - Every output in the DAG d, can continue propagating events in its reverse DAG d', without cycles though its d' mirrored input
    - Branches in DAG d, become Combinators in DAG d'
    - Combinators in DAG d, become Branches in DAG d'
    - Any back-pressure or other events detected in the processing of existing events can result in a synthetic signalling event being injected into the reverse-DAG.
  - We call the injected events 'contraflow' events because they move _backwards_ against the primary data flow.
- The cost or overhead of not injecting a contraflow event is zero
- The cost or overhead of an injected contraflow event ( in Tremor ) is minimised through pruning - for example - operators that are not contraflow aware do not need to receive or process contraflow events - Tremor optimises for this case.
- We call the output-input pairs at the heart of contraflow the 'pivot point'

Contraflow has been used in other event processing systems and was designed /invented by one of the members of the Tremor core team ( in a previous life ).

There are many other ways to handle back-pressure ( for example: those used by Spark, Storm, Hazelcast Jet, … ) but they are biasing for other nuances and tradeoffs than Tremor. Contraflow is far simpler to reason about and develop verifiable systems and code against as a user and puts a lot of the pressure for a good solution onto the Tremor project itself. Only time will tell
which philosophy results in less pager duty!

Although the contraflow mechanism _may_ seem complex, its far simpler than back-pressure handling by almost all other reasonable mechanisms and with far fewer negative side-effects and tradeoffs.

## Guaranteed delivery

Tremor supports guaranteed delivery as long as both onramps and offramps support it. Alternatively,
the [qos::wal](tremor-query/operators.md#qos::wal) can be used to introduce a layer of Guaranteed
delivery for onramps that do not support it naturally.

The basic concept is that each event has a monotonically growing ID, once this ID is acknowledged
as delivered all events with the provided ID or a lower Id are considered delivered. If an ID
is marked as failed to deliver all events up until this ID will be replayed.

## Runtime facilities

Tremor's runtime is composed of a number of facilities that work together to provide service.

### Conductor

The Tremor API is a REST based API that allows Tremor operators to manage the lifecycle of onramps, offramps and pipelines deployed into a Tremor based system.

The set of facilities in the runtime that are related to service lifecycle, activation and management are often referred to collectively as the Tremor conductor or Tremor control plane.

These terms can be used interchangeably.

Operators CAN conduct or orchestrate one or many Tremor servers through its REST based API. The REST API is implemented as an actor in the Tremor runtime.

The API actor in turn interfaces with registry and repository facilities. Tremor distinguishes between artefacts and instances. Artefacts in Tremor have no runtime overhead.

Artefacts in Tremor are declarative specifications of:

- Onramps - An onramp specification is a specific configuration of a supported onramp kind
- Offramps - An offramp specification is a specific configuration of a supported offramp kind
- Pipelines - A pipeline specification is a specific configuration of a pipeline graph
- Bindings - A binding specification describes how onramps, pipelines and offramps should be interconnected

Artefacts can be thought of analagously to code. They are a set of instructions, rules or configurations. As such they are registered with Tremor via its API and stored in Tremor's artefact repository.

Deployment in Tremor, is achieved through a mapping artefact. The mapping artefact specifies how artefacts should be deployed into one or many runtime instances, activated, and connected to live instances of onramps or offramps.

In Tremor, publishing a mapping results in instances being deployed as a side-effect. By unpublishing or deleting a mapping instances are undeployed as a side-effect.

### Metrics

Metrics in Tremor are implemented as a pipeline and deployed during startup.

Metrics are builtin and can not be undeployed.

Operators **MAY** attach offramps to the metrics service to distribute metrics to external systems, such as InfluxDB or Kafka.

## Data model

Tremor supports unstructured data.

Data can be raw binary, JSON, MsgPack, Influx or other structures.

When data is ingested into a Tremor pipeline it can be any **supported** format.

Tremor pipeline operators however, often assume _some_ structure. For hierarchic or nested formats such as JSON and MsgPack, Tremor uses the `serde` serialisation and deserialisation capabilities.

Therefore, the _in-memory_ format for _JSON-like_ data in Tremor is effectively a `simd_json::Value`. This has the advantage of allowing Tremor-script to work against YAML, JSON or MsgPack data with no changes or considerations in the Tremor-script based on the origin data format.

For line oriented formats such as the Influx Line Protocol, or GELF these are typically transformed to Tremor's in-memory format ( currently based on `serde`).

For raw binary or other data formats, Tremor provides a growing set of codecs that convert external data to Tremor in-memory form or that convert Tremor in-memory form to an external data format.

In general, operators and developers should _minimize_ the number of encoding and decoding steps required in the transit of data through Tremor or between Tremor instances.

The major overhead in most Tremor systems is encoding and decoding overhead. To compensate that, as JSON is the most dominant format, we [ported](https://github.com/simd-lite/simdjson-rs) [simd-json](https://github.com/lemire/simdjson) this reduces the cost of en- and decoding significantly compared to other JSON implementations in Rust.

### Distribution model

Tremor does not ( yet ) have an out-of-the-box network protocol. A native Tremor protocol is planned in the immediate / medium term.

As such, the distribution model for Tremor is currently limited to the set of available onramp and offramp connectors.

However the websocket [onramp](artefacts/onramps.md#ws) and [offramp](artefacts/offramps.md#ws) can be used for Tremor to Tremor communication.

### Client/Server

Tremor, in its current form, is a client-server system. Tremor exposes a synchronous blocking RESTful API over HTTP for conducting operations related to its high throughput and relatively high performance pipeline-oriented data plane.

Tremor, in the near future, will add a clustering capability making it a distributed system. Tremor will still support client-server deployments through a 'standalone' mode of clustered operation.

Tremor in 'standalone' mode can be thought of as client-server or a 'cluster of one' depending on your own bias or preferences, dear reader.

repository: tremor-rs/tremor-www-docs

repo_name: tremor-rs/tremor-www-docs


text:
# openapi.api.GEOLOCATIONApi

## Load the API package
```dart
import 'package:openapi/api.dart';
```

All URIs are relative to *https://us1.unwiredlabs.com/v2*

Method | HTTP request | Description
------------- | ------------- | -------------
[**geolocation**](GEOLOCATIONApi.md#geolocation) | **POST** /process.php | Geolocation

# **geolocation**
> Object geolocation(geolocationSchema)

Geolocation

The Geolocation API helps developers locate IoT, M2M and other connected devices anywhere in the world without GPS. The device first sends the API data about which Cellular networks and WiFi networks it can see nearby. The API then uses Unwired Labs’ large datasets of Cell towers, WiFi networks backed by numerous algorithms to calculate and return the device’s location

### Example
```dart
import 'package:openapi/api.dart';

var api_instance = new GEOLOCATIONApi();
var geolocationSchema = new GeolocationSchema(); // GeolocationSchema |

try {
    var result = api_instance.geolocation(geolocationSchema);
    print(result);
} catch (e) {
    print("Exception when calling GEOLOCATIONApi->geolocation: $e\n");
}
```

### Parameters

Name | Type | Description  | Notes
------------- | ------------- | ------------- | -------------
 **geolocationSchema** | [**GeolocationSchema**](GeolocationSchema.md)|  |

### Return type

[**Object**](Object.md)

### Authorization

No authorization required

### HTTP request headers

 - **Content-Type**: application/json
 - **Accept**: application/json

[[Back to top]](#) [[Back to API list]](../README.md#documentation-for-api-endpoints) [[Back to Model list]](../README.md#documentation-for-models) [[Back to README]](../README.md)

gha_language: C#


text:
# How to install Synergy
#### 1. Install Apache HTTP server, PHP and MYSQL
Install Apache with PHP and MySQL:
https://www.vultr.com/docs/how-to-install-apache-mysql-and-php-on-ubuntu-16-04

Next enable .htaccess using steps from
https://linode.com/docs/web-servers/apache/how-to-set-up-htaccess-on-apache/

#### 2. Get Synergy sources
assuming apache's document root is in `/var/www/html`, in terminal:

```
cd /var/www/html
svn checkout https://svn.netbeans.org/svn/opensynergy~source-code-repository
mv opensynergy~source-code-repository synergy
cd synergy
```
Now you are in the synergy main directory.

#### 3. Create database
this will also create default project, default version and a new user with username `import` and password `import` - this user is administrator, in terminal:

```
mysql -u root -p < server/db/structure.sql
```

#### 4. If needed change DB connection details
update file `server/setup/conf.php` from line 18 which contains database connection details to match your database credentials

```
define('DHOST', 'mysql:host=localhost;dbname=synergy;charset=UTF8');
define('DUSER', 'user');
define('DPASS', 'password');
define('DB', 'synergy');
define('DBHOST', 'localhost');
```

#### 5. Now Synergy should be almost up and running
you can try it in your browser `http://localhost/synergy/client/app/`

#### 6. Setup directories for attachments and images
By default, images will be stored at `/var/www/media/` and attachments at `/var/www/att/`. Either make sure these 2 paths exist and
that apache server can write there, or you'll need to change the setting to point to paths which meet the criteria.

The change can be done via Synergy UI in `Administration -> Server` setting where you can find 2 setting fields: `ATTACHMENT_PATH`
and `IMAGE_PATH`. Note also the `IMAGE_BASE` which must correlate with `IMAGE_BASE`, for instance if `IMAGE_PATH` is `/var/www/html/images`,
then `IMAGE_BASE` would be `http://localhost/images/` . Please note that these 2 directories must have proper permissions - for local setup 777 is fine

#### 7. Setting up error log file
In terminal, navigate to the Synergy directory and open file `.htaccess`, line 33 starts with `php_value error_log` and
it ends with path to error log file. Synergy will print error logs there in case something is wrong.

Either create the default path and file (`/var/www/synergy/server/errors/errors.log`) or change the path in `.htaccess` file to your path.
Again make sure it is possible to write to file - setting 777 permissions should be on local deployment.

#### 8. Allow Synergy to store static data from test runs
In terminal in synergy directory, execute following:
```
chmod 777 -R server/data
```

repository: apache/netbeans-tools

gha_language: PHP

repo_name: apache/netbeans-tools


text:
# LuhnAlgorithm

Inspired after reading about Luhn Algorithm (or Modulus 10 Algorithm) article (https://en.wikipedia.org/wiki/Luhn_algorithm) from Wiki, I made this gem to easily validate a variety of identification numbers, for example Social Insurance numbers, or Credit card numbers.

## Installation

Add this line to your application's Gemfile:

```ruby
gem 'luhn_algorithm'
```

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install luhn_algorithm

## Usage

```
class Member
  include ActiveModel::Model

  attr_accessor :social_insurance_number
  validates_luhn_algorithm_of :social_insurance_number
end
```

OR

```
class Member
  include ActiveModel::Model

  attr_accessor :social_insurance_number
  validates :social_insurance_number, luhn_algorithm: true
end
```

```
person = Member.new(social_insurance_number: 'a valid number')

person.valid? # => true
```

You can also pass in a customized message when validating an attribute with Luhn Algorithm, for example

```
validates_luhn_algorithm_of :social_insurance_number, message: 'is not in the correct format'
```

If you want to validate a number with Luhn algorithm on console, you can just type `LuhnAlgorithm.valid?(<your_number_here>)`, for example:

```
require 'luhn_algorithm'

LuhnAlgorithm.valid?(4111111111111111)
```

## Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/thukim/luhn_algorithm. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.

## License

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

## Code of Conduct

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

gha_language: Ruby


text:
# Basic-WPF-Serial-IO
A basic example on how to open a serial port and write/read serial data. Useful for projects involving an Arduino/Raspberry Pi.
Can be used and then changed to fit any project or used as a guide for making your own.

# Demonstration
The data being read is simply the same text that we outputted from the write textbox.
This means that once the Arduino receives any serial data it simply prints it back out through the serial stream.
![Alt text](https://github.com/jeremy1357/Basic-WPF-Serial-IO/blob/master/Basic_Serial_IO_Example/example.png)

You can change more of the specific port settings within the code. Kept it simple for demonstration.

- Make sure to select the COM port that you are using to read from.
- The read/write timeout is in milliseconds. Usually keep this high. Change based on your needs.
- You can add a predefined initial/end character through the two bottom textboxes below the write box.


text:
1. Introduction to MySql
 2. Installation of Mysql
 3. Introduction to my.cnf
 4. MYSQL data types (Using mysql on terminal)
 5. Creating schema, tables.  Adding constraints, default, indexes, relationships
 6. Joins, cascaded operations.
 7. SELECT syntax
 8. Functions (Comparison) and Logical operators
 9. Queries (Basic)
 10. Errors and logs
 11. Import, Export using command line. ([Sample Database] (https://dev.mysql.com/doc/employee/en/))
 12. Introduction to MySql workbench & connection settings, workbench bulk update setting
 13. Functions (Comparison, Control Flow, String, Date Time) and Logical operators (Using MySql workbench)
 14. Queries (Basic, Advanced, Sub-query) on imported data
 15. Optimization - Optimizing queries with explain & others

<!--Previous
1. Installation server + client tool,my.cnf ,  mysql workbench & connection settings, workbench bulk update setting, import, export using command line.
2. Using mysql on terminal.
3. [Sample Database] (https://dev.mysql.com/doc/employee/en/)
3. Creating schema, tables. Adding constraints, default, indexes, relationships
4. Joins, cascaded operations.
5. MYSQL data types
6. SELECT syntax
7. Optimization - Optimizing queries with explain & others
8. Errors and logs
9. Functions (Comparison, Control Flow, String, Date Time) and Logical operators
10. Queries (Basic, Advanced, Sub-query)-->
11. Comparison between MySQL/MariaDB & PostgreSQL
12. Introduction to NOSQL db include MongoDB, Cassandra & Redis
[Database Ranking] (http://db-engines.com/en/ranking)


text:
## Chaining pipelines

A major benefit introduced by Workflows is that you can now chain as many
pipelines as you want, instead of just **build** -> **deploy**.

Chaining pipelines can be done up to 10 times to create the powerful, custom
Workflow that you need.

In the screenshot below you can see three pipelines chained together.

![image](/images/workflow-editor.png)

First, we build our base-image, via the **inital-build** pipeline.
Inspecting the **intial-build** pipeline you can see it gets triggered based on a `git push`.

![image](/images/create-pipeline.png)

Next, we run our unit test through the **tests** pipeline. This pipeline is
triggered automatically after the **initial-build** pipeline has successfully finished.
The screenshot below showcases how this pipeline is chained.

![image](/images/chaining.png)

The **tests** pipeline is triggered on any passing **build** on *any* branch.

The last few pipelines push our images (one debug, one production-ready) to a registry.

repository: frankmalcolmkembery/docs

gha_language: HTML

repo_name: frankmalcolmkembery/docs


text:
[![official JetBrains project](https://jb.gg/badges/official.svg)](https://confluence.jetbrains.com/display/ALL/JetBrains+on+GitHub)
[![GitHub license](https://img.shields.io/badge/license-Apache%20License%202.0-blue.svg?style=flat)](https://www.apache.org/licenses/LICENSE-2.0)

# Full Stack JVM & JS App Hands-On Lab

This repository is the code corresponding to the hands-on lab Full Stack JVM & JS App.

## How to run

Simply fire up the application using gradle:

`.gradlew run`

In order for the application to work, a MongoDB instance needs to be up and running serving the `mongodb-community` service. Information on how to install MongoDB
is available in the respective [documentation](https://docs.mongodb.com/manual/administration/install-community/).

**The master branch is to be used as a template. If you would like to see the completed project, check out the final branch.**

repository: MrMikeFloyd/jvm-js-fullstack

repo_name: MrMikeFloyd/jvm-js-fullstack


text:
---
id: yoshi-flow-editor-runtime
title: yoshi-flow-editor-runtime
sidebar_label: yoshi-flow-editor-runtime
---

Package that exports various Higher Order Components (HOCs) and methods to reduce boilerplate on client's side and organize the app structure in a better way.

## `WixSDK`

WixSDK is a HOC that loads [IStaticWix](https://github.com/wix-private/fed-infra/blob/master/js-sdk-wrapper/src/types.ts) object.

It renders a `children` function with `sdk` argument:

`sdk`: `{ Wix: IWixStatic | null }`

```tsx
import { WixSDK } from "yoshi-flow-editor-runtime";

export default () => (
  <WixSDK>{sdk =>
    <SomeComp Wix={sdk.Wix} /> // IStaticWix | null
  }</WixSDK>
);
```

`sdk.Wix` will be `null` if `WixSDK` is being used in Widget part and rendered in Viewer mode, so make sure you are checking if it's not `null` to use it.

#### Props

**isEditor** - should be passed for Settings part. It triggers a `WixSDK`, so it will use strict types for `sdk.Wix` and it won't be _optional_.

_Settings.ts_

```tsx
import { WixSDK } from "yoshi-flow-editor-runtime";

export default () => (
  <WixSDK isEditor>{sdk =>
    <SomeComp Wix={sdk.Wix} /> // IStaticWix
  }</WixSDK>
);
```

## `BILogger`
Renders a `children` function with `biLogger` relevant for current environment.

You can configure 2 different kinds of BI logger according to user's roles: `owner` and `visitor`:

- **Owner** will be available in `Settings` panel.
- **Visitor** will be available in `Widget`, `controller` and `initAppForPage` in `viewer.app.ts`.

After you generate a project, a demo BI logger (`bi-logger-editor-flow-template`) will be added to `.application.json` configuration.
It's a show case and should be finally repaced in `.application.json` and `package.json` with user's BI logger schema.
To configure own BI logger, please read the [fed-handbook BI section](https://github.com/wix-private/fed-handbook/blob/master/BI.md#overview).

**Settings.tsx**
```tsx
// Somewhere deep in the component tree
const ColorPicker = () => (
  <BILogger owner>
    {biLogger => (
      <ColorPickerColorSpace
        onChange={(color) => {
          logger.logColorChange({ color });
        }}
      />
    )}
  </BILogger>
);
```

**controller.ts**
```tsx
const createController = async ({ flowAPI, controllerConfig }) => {
  const { setProps } = controllerConfig;

  onSomeAction = async () => {
    // Do something...
    await flowAPI.biLogger?.somethingWasDone({});
  };

  return {
    async pageReady() {
      setProps({
        onSomeAction,
      });
      await flowAPI.biLogger?.templateWidgetLoaded({});
    },
  }
}
```

### `BILoggerDefaults`
To update defaults for each event being called from the `BILogger` render prop, you can update the context by wrapping your root component,
which contain consumers.

```Settings.tsx
import { BILogger, BILoggerDefaults } from 'yoshi-flow-editor-runtime'

<BILoggerDefaults defaults={{ someData: 'hey' }}>
  <div>
  // Somwhere deeper...
  <BILogger owner>
    {biLogger => (
      <ColorPickerColorSpace
        onChange={() => {
          logger.logColorChange({ color }); // Event will include `someData` field.
        }}
      />
    )}
  </BILogger>
  </div>
</BILoggerDefaults>
```

> To update defaults in controller, you can just call `flowAPI.biLogger.util.updateDefaults(newDefaults)`.

### Testing
For unit testing components that contain a BI logger you should wrap it in `BILoggerProvider` HOC imported from `yoshi-flow-editor-runtime/test`.

It accepts `logger` property which can be a plain object with bi methods you want to mock.

_Widget.spec.tsx_
```tsx
import { BILoggerProvider } from 'yoshi-flow-editor-runtime/test';

it('should send a BI event on button click', async () => {
  const buttonClickedBIEvent = jest.fn();
  const { getByTestId } = render(
    <BILoggerProvider logger={{ onButtonClicked: buttonClickedBIEvent }}>
      <Widget />
    </BILoggerProvider>
  );
  expect(buttonClickedBIEvent).toHaveBeenCalled();
});
```

## `translate`
It's a HOC from `react-i18next` that allows using translations for `Widget` and `Settings` components.

All translations should be located under `assets/locales/messages_:LANGUAGE.json` by default.
If you want to change the prefix of translations file name, set `prefix` field to `.application.json`'s translations object.

⚠ You should not use `I18NextProvider`. Editor flow already provides needed context based on website's language.

Just wrapping any component will give an access to app's translations via `t` property:

_Widget.tsx_
```tsx
import { translate, InjectedTranslateProps } from 'yoshi-flow-editor-runtime';

export default translate()(({ t }: InjectedTranslateProps) => {
  return <h1 data-hook="app-title">{t('app.widget.welcome')}</h1>;
});
```

### Testing
For unit testing components that use `translation` HOC, you can use `I18NextProvider` from `yoshi-flow-editor-runtime/test`.

It will configue 18n mock and won't send any additional network requests:

_Widget.spec.tsx_
```tsx
import { I18nextProvider } from 'yoshi-flow-editor-runtime/test';

it('should render a title correctly', async () => {
  const { getByTestId } = render(
    <I18nextProvider>
      <Widget />
    </I18nextProvider>
  );

  expect(getByTestId('app-title').textContent).toBe('app.widget.welcome');
});
```

## `withExperiments`
Connects a React component to underlying experiments.
A higher-order React component class that builds props from the experiments state and passes them to the wrapped component for Widget and Settings.

⚠ You should not use `ExperimentsProvider`. Editor flow already provides needed context based on your experiments configuration under `.application.json`.

For more info about `withExperiments` HOC, please read [official README](https://github.com/wix-private/fed-infra/tree/master/experiments/wix-experiments-react#withexperimentscomponent).

_Widget.tsx_
```tsx
import { withExperiments } from 'yoshi-flow-editor-runtime';

export default withExperiments<WidgetProps>(({ experiments }) => {
  return <h1 data-hook="app-title">{experiments.isEnabled('specs.scope.ShowEmoji') ? '👋' : 'Hey!'}</h1>;
});
```

### Testing
Editor flow provides easy way to mock experiments you want to test via `ExperimentsProvider` from `yoshi-flow-editor-runtime/test`.

Just pass experiments needed to be mocked via `experiments` property:

```tsx
import { ExperimentsProvider } from 'yoshi-flow-editor-runtime/test';

it('should render a title correctly', async () => {
  const { getByTestId } = render(
    <ExperimentsProvider experiments={{ 'specs.scope.ShowEmoji': true }}>
      <Widget />
    </ExperimentsProvider>
  );

  expect(getByTestId('app-title').textContent).toBe('👋');
})
```

gha_language: TypeScript


text:
<!--
  Thank you for submitting a Pull Request. Please:
    - Read our CONTRIBUTING guidelines.
      https://github.com/kuzzleio/kuzzle/blob/master/CONTRIBUTING.md
    - Associate an issue with the Pull Request.
    - IMPORTANT - Add the corresponding "changelog:xxx" label to your PR.
-->

<!--- This template is optional. -->

## What does this PR do ?

<!--
  Please include a summary of the change, relevant motivation and context.
  Also, list any dependencies that are required for this change.
-->

### How should this be manually tested?

<!--
  Please describe your test configuration, the tests ran to verify your changes
  And give us instructions on how to reproduce them.
-->
  - Step 1 :
  - Step 2 :
  - Step 3 :

### Other changes

<!--
  Please outline any changes not directly linked to the main issue, but made because of it.
  For instance: on-the-fly fixes, dependencies updates and so on.
-->

### Boyscout

<!--
  Finally, describe any improvements in the code base like:
  Typo fixes, improved/new comments, debug messages and so on.
-->

repository: kuzzleio/kuzzle

repo_name: kuzzleio/kuzzle


text:
# A Simple Gallery

`A Simple Gallery` is a static, serverless site generator for making simple gallery-focused sites. To preview what it looks like, visit (https://sharedphysics.github.io/ASimpleGallery/Demo/)

# Getting Started

## Requirements:
Running `A Simple Gallery` requires you to have `python3` installed and access to a server to host your site somewhere. If you want to try it out really quickly, you can host your site using [GitHub pages](https://pages.github.com).

You also need to have `ImageMagick` installed for image processing. You can set it up via `brew install ImageMagick`

## Site Management
Your site is really easy to manage! Just add images into the `/images/` folder and subfolders, and **make sure you don't accidentally delete the .py files in /images/.**

## Building the Site
1. Download this repo and unzip it somewhere.
2. Make sure you have python3 running on your computer.
3. To build your site, you'll need to run the `Build.sh` file in your terminal.
4. To run that, open up your terminal and navigate the directory where you unzipped everything. Type in `chmod +x Build.sh` and press enter. You only need to do this one time, the first time.
5. Now type in `./Build.sh`
6. Your site will compile with the images in the /images/ folder, and it will launch your local `index.html` file in the browser.

When you build the site, `A Simple Gallery` will:
* Optimise images for web display
* Generate and compile the .html files for your folders and subfolders
* Launch the site locally.

# Coming Soon
Some features coming soon include:
* ImageMagik scripts to create thumbnails to support multiple galleries
* ImageMagick and retina.js support for extra-optimised images
* Support for image metadata and captions
* Support for variables to customize your gallery
* Support for LazyLoading images to reduce bandwidth.

# Recently Added
2020/5/24 - v2.0.0
* Better mobile layouts
* Support for nested galleries and multi-directory images
* ImageMagik scripts to optimize image sizes for web

repository: sharedphysics/crosscountrytravelers

repo_name: sharedphysics/crosscountrytravelers


text:
:warning: This project is archived and the repository is no longer maintained.

formcore
========

[![npm version](https://badge.fury.io/js/formcore.svg)](https://badge.fury.io/js/formcore)
[![Build Status](https://img.shields.io/travis/filamentgroup/formcore/master.svg)](https://travis-ci.org/filamentgroup/formcore)
[![Dependency Status](https://david-dm.org/filamentgroup/formcore.svg?theme=shields.io)](https://david-dm.org/filamentgroup/formcore)

A set of forms.

* [Demo](https://filamentgroup.github.io/formcore/)

## Maxlength

The Maxlength component currently watches inputs and replaces returns with
`\r\n` to normalize behavior across browsers which count returns differently.

Credit to Keith Wood for his implementation which acted as inspiration:
http://keith-wood.name/maxlength.html

## Numeric Input

A number of features around normalizing the behavior of `<input type="number">` form fields. To start, add the `data-numeric-input` attribute to your `<input type="number">` element:

```html
<input type="number" data-numeric-input>
```

Next, include the `js/numeric-input.js` and `js/numeric-input-init.js` files.

### Features

1. Suppresses non-numeric input into the form field, similar to how Chrome desktop behaves with `<input type="number">`. This will also prevent scientific or E notation from being entered into the form field (since `E` and `e` are alphabetic).
1. Works to enforce the `maxlength` attribute (also works with the number of digits on `max`)
1. Works around bugs with `<input type="number">` in Safari 6 and Firefox desktop (large numbers may be rounded or leading zeros may be truncated). In these browsers, the type is toggled to `text`.
1. `data-numeric-input-nav-disabled` attribute option: Prevent the up and down arrow keys from incrementing and decrementing the number value.

#### Manual Initialization

* Alternatively, if you don’t want to use our auto-initialization code (the `numeric-input-init.js` file, which relies on a global `enhance` event), you can manually initialize with `new NumericInput( element );` You’re on the hook to prevent duplicate initialization when doing this manually.

repository: filamentgroup/formcore

repo_name: filamentgroup/formcore


text:
---
layout: default
---

# 1994-05-05 - (fwd) Join our Betting Systems Re-development Project...

## Header Data

From<EMAIL_ADDRESS>(Timothy C. May)

To<EMAIL_ADDRESS>Message Hash: e0273a094321e8005e3b23e4ae660248ae5acc5200e2dadc5f4c3a91dbbb1cf1

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1994-05-05 18:04:26 UTC

Raw Date: Thu, 5 May 94 11:04:26 PDT

## Raw message

```
{% raw  %}From<EMAIL_ADDRESS>(Timothy C. May)
Date: Thu, 5 May 94 11:04:26 PDT
To<EMAIL_ADDRESS>Subject: (fwd) Join our Betting Systems Re-development Project...
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

I'm attaching a job offer here for a couple of reasons:

- it mentions a new betting system programming job in Hong Kong
(shades of the "Internet Casino"? Actually, no, not in this case...but
it _could_ be...)

- the focus on object-oriented methods to rewrite their
transaction-processing system has echoes of the "protocol" problem
we're talking about here

- expect very similar projects, someday, for projects in the
cypherspace

--Tim

Newsgroups: comp.object
From<EMAIL_ADDRESS>(Steven Wong)
Subject: Join our Betting Systems Re-development Project Reengineering team
Message-ID<EMAIL_ADDRESS>Sender<EMAIL_ADDRESS>(usenet account)
Organization: Hong Kong University of Science and Technology
Date: Wed, 4 May 1994 06:29:24 GMT

Technology Architect

Join our Betting Systems Re-development Project Re-
engineering team

The Royal Hong Kong Jockey Club is evolving into a
sophisticated user of high volume transaction processing
technology for one of the largest wagering systems in the world
which handles over US$100 million each race meeting.

To meet our user demands of tomorrow - for example design
for real-time support of horse racing events around the globe -
we now face the enormous challenge of re-developing the
total technology base and infrastructure of these betting
systems which will reach the end of  their life by the end of the
millennium.

We are re-engineering with an objective to implement an up-to-
date Open Distributed Systems and Object Orientation
approach, in order to create flexible systems capable of
supporting the demanding needs of the Hong Kong market
place and to position us for absorbing change well into the next
century.

We are replacing systems at the client, network and senior
levels.  The re-development of our network includes the
metropolitan area branch offices, two racetracks and a 1,600
workstation Telebet Auditorium.

As Technology Architect working with the Application
Architect and other members of the technical team you will
undertake the task of developing benchmarks and supporting
the Development and Technical Research and Planning teams
to develop strategies for system development.

With a penchant for problem solving, you must have strong
practical experience in our planned technologies, and still be
hands on with regard to coding and debugging.  Experience
with OO, C++ and Unix is essential.  A knowledge of both
written and spoken Cantonese would also be a distinct
advantage.

This Hong Kong based position will be on a fixed 2-3 year
contract.  To attract outstanding people, the packages will be
mainly cash remuneration at a level reflecting experience and
Hong Kong relocation/living costs.

In the first instance, apply with full career details
quoting relevant ref. number, by E-mail:
<EMAIL_ADDRESS>or by writing to The
Senior Personnel Manager,
The Royal Hong Kong Jockey Club, 2
Sports Road, Happy Valley, Hong Kong.
Fax:<PHONE_NUMBER> or<PHONE_NUMBER>.

{% endraw %}
```

## Thread

+ Return to [May 1994](/archive/1994/05)

+ Return to<EMAIL_ADDRESS>(Timothy C. May)](/authors/tcmay_at_netcom_com_timothy_c_may_)"

+ 1994-05-05 (Thu, 5 May 94 11:04:26 PDT) - (fwd) Join our Betting Systems Re-development Project... -<EMAIL_ADDRESS>(Timothy C. May)_


text:
---
id: 678
title: MvvmCross WPF Tabs Presenter
date: 2016-11-19T09:37:36+00:00
author: benjamin hysell
layout: post
guid: http://benjaminhysell.com/?p=678
permalink: /archive/2016/11/mvvmcross-wpf-tabs-presenter/
categories:
  - Uncategorized
tags:
  - mvvmcross
  - wpf
---

[https://github.com/benhysell/V.Tabs](https://github.com/benhysell/V.Tabs)

Sample MvvmCross WPF application with a tabs presenter. A tab bar is defined in the `HomeView` allowing one to switch between all three tabs. `TabOne` has a button to show a full screen view, replacing the tab view with a full screen view.

## Usage

Application is made up of four `Views`:

* Home - Main screen that holds the tab bar and where tabs are shown
* TabOne - Sample tab that also includes a button to show a full screen view
* TabTwo and TabThree - Extra tabs to fill out the application
* DetailFullScreen - A full screen view that replaces the `HomeView`, creating a 'modal' screen.  Button allows one to close this and return to the `HomeView`

## TabPresenter
`TabPresenter.cs` in `V.Tabs.Wpf\Utilitiles` manages swapping and replacing `Views` based on user input.  By decorating a View's `xaml.cs` class definition with a `Region` attribute will define where that `View` is shown.

i.e. From `TabOneView.xaml.cs`

```
[Region(Region.Tab)]
public partial class TabOneView
{
```

Tells the `TabPresenter` this region is a tab and to replace the currently shown tab in the `HomeView`.

For a full screen `View` `DetailFullScreenView.xaml.cs` is decorated with

```
[Region(Region.FullScreen)]
public partial class DetailFullScreenView
{
```

Telling the `TabPresenter` to replace the entire `HomeView` with the contents of `DetailFullScreenView`.  Once the user closes `DetailFullScreenView` the `HomeView` with the tabs will again be shown the user.  `DetailFullScreenView` is stacked on top of `HomeView` to take over the whole screen.


text:
# Albion Market Data Relay (amdr)
AMDR is designed to help aggregate and share market information
for the MMO Albion Online. It is heavily influenced by the EVE
Market Data Relay project for EVE Online.

Those looking to get market data simply need to open a websocket
connection and they will have access to a firehose of data.

# Documentation
Documentation will come after getting a working version hosted and
running.

# License
This project, and all contributed code, are licensed under the MIT
License. A copy of the MIT License may be found in the repository.

repository: offner/albion-market-data-relay

repo_name: offner/albion-market-data-relay