text:
# Supple CSS | utilities.visually-hidden

Hides an element visually while still allowing the content to be accessible to assistive technology, e.g. screen readers.

Read more about [Supple CSS](https://github.com/supple-css/supple).

## Table of contents

* [Use](#use)
* [Available classes](#available-classes)
* [Configurable variables](#configurable-variables)
* [Installation](#installation)
* [Testing](#testing)
* [Browser support](#browser-support)

## Use

```html
<button>
  This button has text that is
  <span class="u-visually-hidden">hidden visually but still available for screenreaders etc.</span>
</button>
```

### responsive modifiers
When you set media queries in `$in-query` you can use them like this:

```html
<button>
  This button has text that is
  <span class="u-visually-hidden@lap">Hidden visually from lap breakpoint but still available for screenreaders etc.</span>
</button>
```

## Available classes

**On the `.u-visually-hidden` block**

* `.u-visually-hidden`: core visually hidden block
* `.u-visually-hidden@[QUERY-NAME]`: applies visually-hidden at the given media query. (available in `$in-query` SCSS setting)

## Configurable variables

### SCSS variables

* `$in-query`: a list of breakpoints where `.u-visually-hidden@[QUERY-NAME]` is generated for, defaults to: `()`

You can overwrite the SCSS variables the following ways:

```scss
// in your manifest file, eg. `styles.scss`
@use 'node_modules/@supple-kit/supple-css/utilities/visually-hidden' with (
  $in-query: (lap, desk),
);
```
or
```scss
// in your own variable file, eg. `_vars.scss`
@use 'node_modules/@supple-kit/supple-css/utilities/visually-hidden/variables' with (
  $in-query: (
    lap
  ),
);

// in your manifest file, eg. `styles.scss`
@use 'node_modules/@supple-kit/supple-css/utilities/visually-hidden';
```

## Installation
Make sure you've installed/downloaded the Supple CSS library: [Supple CSS installation](../../#installation)

## Testing
Basic visual tests are in [test.html](https://supple-kit.github.io/supple-css/utilities/visually-hidden/test.html).

## Browser support

* Chromium-based browsers (Chrome, Edge, Brave, Opera)
* WebKit-based browsers (Safari, iOS Safari)
* Firefox (Gecko)

repository: maleksandrov/supple-css

repo_name: maleksandrov/supple-css


text:
# nt - simple note taker

## SYNOPSIS

`nt` [**-Dilvy**] [**-f** *FILE*] [**-e** *NOTE*] [**-d** *NOTE*] [**-t** [*TAG*]] [**-n** *NUM* | **-NUM**] [*NOTE* ...]

## DESCRIPTION

Simple note taker for the command line. To take a note simply run the command
with the new note as arguments or from stdin. The note will be saved to a plain
text file with each line being a note. The file is saved to the file either
specified with **-f** or in the default one from `config.h`. Notes can have tags
by prefixing the note with a tag followed by a colon. For example a note
`chores: take out trash` will have the tag `chores`.

## OPTIONS

**-d** *NOTE*
	Delete *NOTE* from notes

**-D**
	Delete all notes from *FILE*

**-e** *NOTE*
	Edit *NOTE* with new text given through stdin

**-f** *FILE*
	Load *FILE* instead of default one

**-i**
	Force prompt to confirm action

**-l**
	List notes

**-n** *NUM*, **-NUM**
	List last *NUM* notes

**-t** [*TAG*]
	Search for *TAG* in notes, list all tags if no *TAG* is given

**-v**
	Print version info and exit

**-y**
	Auto reply yes to confirmation prompts

## USAGE

Add simple note and list it:

	$ nt clean dishes
	$ nt -l
	clean dishes

Create note in specified file:

	$ nt -f list take out trash
	$ nt -f list -l
	take out trash

Add more notes by running command again:

	$ nt wash car
	$ nt -l
	clean dishes
	wash car
	$ nt buy pie
	$ nt -l
	clean dishes
	wash car
	buy pie

List just the *NUM* most recent notes:

	$ nt -1
	buy pie
	$ nt -n 1
	buy pie
	$ nt -2
	buy pie
	wash car
	$ nt -n 2
	buy pie
	wash car

Search notes through an external program:

	$ nt -l | grep pie
	buy pie
	$ nt make pie
	$ nt -l | grep pie
	buy pie
	make pie

Remove given note:

	$ nt -yd buy pie
	$ nt -l
	clean dishes
	wash car
	make pie

Edit note with new text given from stdin:

	$ echo eat pie | nt -e make pie
	$ nt -l
	clean dishes
	wash car
	eat pie

Remove all notes:

	$ nt -yD
	$ nt -l
	$ nt -f list -yD
	$ nt -f list -l

## AUTHOR

Ed van Bruggen<EMAIL_ADDRESS>
## SEE ALSO

View source code at: <https://gitlab.com/edvb/nt>

## LICENSE

zlib License

license: Zlib

repository: edvb/nt

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: edvb/nt


text:
## Store.finishTransaction()

> Store.finishTransaction(transaction)

Notifies the App Store that a transaction is complete.

After you finish handling a transaction, you must call framework.api.Store.finishTransaction() on the transaction object. If you don't do this, the App Store will think your transaction was interrupted and will attempt to resume it on the next application launch.

**Syntax:**

    framework.api.Store.finishTransaction(transaction)

@tparam table transaction
The transaction object belonging to the transaction you want to mark as finished.

### Returns

-   Nothing.

license: MIT


text:
# Modals

Modal is a fully accessible dialog that announces itself to the screen, traps tab focus (and shift+tab), and resets focus on open and close to ensure that keyboard users can't access content behind it. It closes on 'x', 'ESC' key, and clicking on the gray semi-opaque background.

Modal should be rendered once to the screen, ideally having its contents and closing functionality handled via Redux.

For recommended implementation, see [docs related to integrating with redux](https://github.com/vineyard-bloom/bloom-layout/blob/master/docs/alert-and-modal-with-redux.md).

Every modal renders the same `x` button to close, but this can be styled via the `Modal-close` class in CSS.

** All focusable elements inside the modal MUST have ids. There are several diffing event handlers that trap tab focus for accessibility, and it uses ids of those elements **

You shouldn't have more than one modal open at a time. This is why it's recommended to render it to the DOM once and update its content via Redux ([recommended method](https://github.com/vineyard-bloom/bloom-layout/blob/master/docs/Modal-and-modal-with-redux.md)).

Styling of Modal is through the `.Modal` class.

### Required Props:
- `closeModal`:
    function that deletes the `modalContents`

- `modalContents`:
    either: a React Element to fill the modal or `null`
    * the modal will hide if it has no contents

- `modalTriggerId`:
    a string that maps to an id of the button that opened the modal
    * must be defined if you have modalContents
    * used to refocus the document activeElement after closing the modal
    * if you triggered a modal programmatically, and no button triggered its opening, choose a focusable element in the content behind the modal

### Example:
```
import { Modal } from 'bloom-layout'

...
state = {
  modal: {
    contents: null,
    triggerId: null
  }
}

...

closeModal = (e) => {
  if (e) {
    e.preventDefault()
  }

  this.setState({
    modal: {
      contents: null,
      triggerId: null
    }
  })
}

openModal = (e, contents, triggerId) => {
  if (e) {
    e.preventDefault()
  }

  this.setState({
    modal: {
      contents,
      triggerId
    }
  })
}

return (
  const { modal } = this.state

  ...

  <Modal
    modalContents={modal && modal.contents}
    modalTriggerId={modal && modal.triggerId}
    closeModal={this.closeModal}
  />

  ...

  <Button
    id='modal-opener'
    onClick={(e) => this.openModal(e, <ModalContentComponent />, e.target.id)}
  />
)
```

[Back to Contents](https://github.com/vineyard-bloom/bloom-starter#contents)

repository: vineyard-bloom/bloom-layout

gha_language: JavaScript

gha_license_id: MIT

repo_name: vineyard-bloom/bloom-layout


text:
# Android-Service-Example
Android Service Code Example<br>
![Sample App](http://i.imgur.com/WPvC72t.png)

include 5 kinds of sample codes
 - IntentService
 - Service
 - Bind Service
   - Use `Binder`
   - Use `Message`
   - AIDL (Android Interface Definition Language.)

More information please check [Android Developer](https://developer.android.com/guide/components/services.html)

repository: Bhavikom/BackgroundServiceAllTypes

repo_name: Bhavikom/BackgroundServiceAllTypes


text:
---
layout: docwithnav
title: "Examples: Multi-tier Applications"
---

## {{ page.title }} ##

Use the following examples to learn how to setup and configure simple multi-tier applications in a Kubernetes cluster.

Table of Contents:


text:
# How to Port the Azure IoT C SDK  to Other Platforms

The purpose of this document is to provide guidance on how to port the C Shared utility library to platforms not supported out of the box.
The C shared utility library is used by C SDKs like IoTHub client SDK and EventHub client SDK.

The document does not cover the specifics of any particular platform.

## References

###### Specifications
- [tickcounter FreeRTOS reference](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/tickcounter_freertos_requirement.md)

- [agenttime adapter specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/agenttime_requirements.md)

- [threadapi and sleep adapter specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/threadapi_and_sleep_requirements.md)

- [platform adapter specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/platform_requirements.md)

- [tlsio specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/tlsio_requirements.md)

- [xio specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/xio_requirements.md)

- [lock adapter specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/lock_requirements.md)

###### Header files
- [tickcounter.h](https://github.com/Azure/azure-c-shared-utility/blob/master/inc/azure_c_shared_utility/tickcounter.h)

- [threadapi.h](https://github.com/Azure/azure-c-shared-utility/blob/master/inc/azure_c_shared_utility/threadapi.h)

- [xio.h](https://github.com/Azure/azure-c-shared-utility/blob/master/inc/azure_c_shared_utility/xio.h)

- [tlsio.h](https://github.com/Azure/azure-c-shared-utility/blob/master/inc/azure_c_shared_utility/tlsio.h)

- [socketio.h](https://github.com/Azure/azure-c-shared-utility/blob/master/inc/azure_c_shared_utility/socketio.h)

- [lock.h](https://github.com/Azure/azure-c-shared-utility/blob/master/inc/azure_c_shared_utility/lock.h)

- [platform.h](https://github.com/Azure/azure-c-shared-utility/blob/master/inc/azure_c_shared_utility/platform.h)

# Table of contents

- [Overview](#Overview)
- [tickcounter adapter](#tickcounter-adapter)
- [agenttime adapter](#agenttime-adapter)
- [sleep adapter](#sleep-adapter)
- [platform adapter](#platform-adapter)
- [tlsio adapter overview](#tlsio-adapter-overview)
- [socketio adapter overview (optional)](#socketio-adapter)
- [tlsio adapter implementation](#tlsio-adapter-implementation)
- [threadapi and lock adapters (optional)](#threadapi-and-lock-adapters)

## Overview

The C shared utility library is written in C99 for the purpose of portability to most platforms.
However, several components rely on platform-specific resources in order to achieve the functionality required.
Thus, porting the C shared utility library is done by porting the PAL components (adapters) that are
part of the library. Below is a rough overview of the components:

![](img/porting_guide_overview.png)

There are several mandatory components for which an adapter must be provided:

- A `tickcounter` implementation: this provides the SDK an adapter for getting a tick counter expressed in ms.
The precision does not have to be milliseconds, but rather the value provided to the SDK has to be
expressed in milliseconds.

- An `agenttime` implementation: this provides the SDK adapters for the C time management functions like
`time`, `difftime`, etc. This is needed due to the very wide spread differences in the way time is
handled by different platforms.

- A `sleep` implementation to provide a device-independent sleep function.

- A `platform` implementation to perform global init and de-init.

- A `tlsio` implementation to allow the SDK to communicate over TLS. The IoT Hub does not support insecure
communication.

Additionally, there are two optional components, `threadapi` and `lock`, that allow the SDK to communicate with
an IoT Hub on a dedicated thread. Yet another optional component is the `socketio` adapter, which is used with
some kinds of `tlsio` adapter implementations.

There are several existing adapters that can be found under the  SDK's
[adapters directory](https://github.com/Azure/azure-c-shared-utility/blob/master/adapters)
and
[source directory](https://github.com/Azure/azure-c-shared-utility/blob/master/src).
If any of these adapters work for your device, simply include that file in your project directly.

### tickcounter adapter

Tickcounter behavior is exemplified by the
[tickcounter FreeRTOS reference](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/tickcounter_freertos_requirement.md).

To get started, copy
[this version of tickcounter.c](https://github.com/Azure/azure-c-shared-utility/blob/master/pal/freertos/tickcounter.c)
file and modify it to suit your device.

### agenttime adapter

The agenttime adapter is specified in
[agenttime adapter specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/agenttime_requirements.md)
and provides platform-independent time functions.

For most platforms/OSs you can include the standard [agenttime.c](https://github.com/Azure/azure-c-shared-utility/blob/master/pal/agenttime.c)
file in your build. This adapter simply calls the C functions `time`, `difftime`, `ctime`, etc.

If this file does not work for your implementation, make a copy of it and modify it appropriately.

The Azure IoT SDK only requires the `get_time` and `get_difftime` functions. The other functions
in this adapter -- `get_gmtime`, `get_mktime`, and `get_ctime` -- are deprecated and
may be omitted or left non-functional.

### sleep adapter

The sleep adapter is a single function that provides a device-independent thread sleep. Unlike other
adapters, it does not have its own header file. Instead, its declaration is contained in the
[threadapi.h](https://github.com/Azure/azure-c-shared-utility/blob/master/inc/azure_c_shared_utility/threadapi.h)
file along with the declarations for the optional threadapi adapter, and its implementation is typically
contained in an associated threadapi.c file.

Unlike the rest of the functions in
[threadapi.h](https://github.com/Azure/azure-c-shared-utility/blob/master/inc/azure_c_shared_utility/threadapi.h),
however, `ThreadAPI_Sleep` is required by the SDK and must always be functional.

The specification for the sleep adapter is found in the
[threadapi and sleep adapter specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/threadapi_and_sleep_requirements.md).

### platform adapter

The platform adapter performs one time initialization and deinitialization for the platform and also supplies the SDK with an appropriate TLSIO.

The
[platform adapter specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/platform_requirements.md)
gives full instructions for writing the platform adapter.

To get started creating your platform adapter, copy
[this Windows platform.c file](https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/platform_win32.c)
and modify it to suit your needs.

### threadapi and lock adapters

The **threadapi** and **lock** adapters must exist for the SDK to compile, but their functionality is optional.
Their specification documents (see below) detail what each empty function should do if threading functionality
is not needed.

These components that allow the SDK to
communicate with an IoT Hub within a dedicated thread. The use of a dedicated thread has some cost
in memory consumption because of the
need for a separate stack, which may make the dedicated thread difficult to use on devices with little free
memory.

The upside of the dedicated thread is that all current tlsio adapters may repeatedly
block for some fraction
of a minute when attempting to connect to their IoT Hub when the network is unavailable, and having a thread
dedicated to the Azure IoT SDK will allow other device functions to remain responsive while the SDK is blocked.

Future versions of the SDK may eliminate this potential blocking behavior, but for now, devices which must
be responsive will need to use a dedicated thread for the SDK, which requires implementing the ThreadApi
and Lock adapters.

Here are the specs for the threadapi and lock adapters:
- [threadapi and sleep adapter specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/threadapi_and_sleep_requirements.md)

- [lock adapter specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/lock_requirements.md)

These specs explain how to create null _lock_ and _threadapi_ adapters for when threading is not desired.

To get started creating your threadapi and lock adapters, copy these Windows adapter files and modify
them appropriately:
- [threadapi.c](https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/threadapi_win32.c)
- [lock.c](https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/lock_win32.c)

### tlsio adapter overview

A **tlsio** adapter provides the SDK with secure TLS communication wtih the Azure IoT Hub.

Tlsio adapters expose their functionality to the SDK via `xio`, which
is a generic C-language bits-in-bits-out interface
[defined here](https://github.com/Azure/azure-c-shared-utility/blob/master/inc/azure_c_shared_utility/xio.h).

A tlsio adapter instance is created via the adapter's
[`xio_create`](https://github.com/Azure/azure-c-shared-utility/blob/bc5d4eb8f9dbe3092c9cf046db9b7187b5baad4b/inc/azure_c_shared_utility/xio.h#L64)
function, and the configuration parameter `const void* io_create_parameters`
must be of the specialized type
[`TLSIO_CONFIG`](https://github.com/Azure/azure-c-shared-utility/blob/master/inc/azure_c_shared_utility/tlsio.h)
when creating the tlsio instance.

Implementation of tlsio adapters for new devices is done by selecting the existing tlsio adapter (and perhaps also
a socketio adapter) that most closely fits your needs and modifying it accordingly.

##### The two styles of tlsio

There are two possible design patterns for a tlsio adapter: _direct_, and _chained_. In the _direct_ style, the
tlsio adapter owns a TCP socket which it uses to directly perform TLS communication with the remote host. In the
_chained_ style, the tlsio adapter does not own a TCP socket and does not communicate directly with the remote host.
Instead, it still does all the TLS chores like encryption, decryption, and negotiation, but it communicates with
the remote host indirectly via yet another xio-style adapter of some sort.

The _direct_ style adapters require less code and avoid extra memory buffer copying, so they are more suited to
microcontrollers. The tlsio adapters for Arduino and ESP32 are both _direct_ types. The _chained_ style adapters
are more resource-hungry, but they offer more flexibilty. The tlsio adapters for Windows, Linux, and Mac
are all _chained_ style adapters.

The choice of TLS implementation may dictate the style of tlsio. For example, the TLS implementations for Arduino and
Espressif's OpenSSL implementation for ESP32 can only work directly with their own internal TCP socket,
so they can only be used as part of a _direct_ style tlsio. By contrast, the full official version
of OpenSSL can be used either way.

### socketio adapter overview

In order to connect to the internet, a _chained_ tlsio must at some point talk through an `xio` adapter
that contains
a TCP socket. In the Azure IoT SDK, an `xio` adapter managing a TCP socket is called a `socketio` adapter.

Multiple xio components can be chained together if desired. Here is a diagram illustrating the differences
between a _direct_ tlsio, a _chained_
tlsio, and a _chained_ tlsio with an xio-based http proxy component:
![](img/xio_chain.png)
The `xio_http_proxy` component is only shown to illustrate xio capability. Its details are beyond the
scope of this document.

### tlsio adapter implementation

Adapters other than tlsio are easy to implement, even for inexperienced developers. The tlsio adapters, however,
are quite complicated, and writing a tlsio adapter is a task only for experienced developers who are comfortable
setting up include directories and external libraries without instruction.

The most up-to-date information on tlsio implementation is contained in the
[tlsio specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/tlsio_requirements.md).

All of the existing tlsio adapters use TLS libraries that are not part of the Azure IoT SDK. Refer to the
documentation for the specific TSL libraries for instructions on library usage such as setting include
directories and linking library files.

#### Existing _direct_ tlsio implementations
There are two existing _direct_ adapter implementations:
- [tlsio_openssl_compact for ESP32](https://github.com/Azure/azure-iot-pal-esp32/blob/master/pal/src/tlsio_openssl_compact.c)
- [tlsio_arduino for Arduino](https://github.com/Azure/azure-iot-pal-arduino/blob/master/pal/src/tlsio_arduino.c)

Of these two, the
[tlsio_openssl_compact for ESP32](https://github.com/Azure/azure-iot-pal-esp32/blob/master/pal/src/tlsio_openssl_compact.c)
is probably the better candidate for copying for re-use because it is more likely to resemble newer devices,
and it was written in tandem with the
[tlsio specification](https://github.com/Azure/azure-c-shared-utility/blob/master/devdoc/tlsio_requirements.md).

The
[tlsio_openssl_compact for ESP32](https://github.com/Azure/azure-iot-pal-esp32/blob/master/pal/src/tlsio_openssl_compact.c)
abstracts its operating system dependencies using these two files:
- [socket_async.c](https://github.com/Azure/azure-c-shared-utility/blob/master/pal/socket_async.c)
- [dns_resolver_ares.c](https://github.com/Azure/azure-c-shared-utility/blob/master/src/dns_resolver_ares.c)

It is recommended that all _direct_ tlsio implementatons follow this pattern.

The
[socket_async.c](https://github.com/Azure/azure-c-shared-utility/blob/master/pal/socket_async.c)
and
[dns_resolver_ares.c](https://github.com/Azure/azure-c-shared-utility/blob/master/src/dns_resolver_ares.c)
files can be re-used without change for most socket implementations by merely changing the content of
the included "socket_async_os.h" file, which contains os-specific headers.

#### Existing _chained_ tlsio implementations
_Chained_ adapter implementations include:
- [tlsio_openssl for Windows, Linux, and Mac](https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/tlsio_openssl.c)
- [tlsio_schannel for Windows only](https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/tlsio_schannel.c)
- [tlsio_wolfssl for embedded devices](https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/tlsio_wolfssl.c)
- [tlsio_mbedtls for embedded devices](https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/tlsio_mbedtls.c)

#### Existing socketio implementations for _chained_ tlsio adapters
There is no spec for socketio adapters, so it is necessary to copy the behavior of an existing one, and
[socketio_berkeley](https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/socketio_berkeley.c)
is the best candidate for copying. However, be aware that all existing socketio adapters including
[socketio_berkeley](https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/socketio_berkeley.c)
purge their pending io lists during socketio_destroy, which is incorrect. The pending io
lists should be purged during socketio_close instead.
- [socketio_berkeley for Linux, easily adapted to any Berkeley socket](https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/socketio_berkeley.c)
- [socketio_win32 for Windows](https://github.com/Azure/azure-c-shared-utility/blob/master/adapters/socketio_win32.c)
- [tlsio_cyclonessl_socket for use with cyclonessl](https://github.com/Azure/azure-c-shared-utility/blob/master/src/tlsio_cyclonessl_socket.c)

### Adding device support repositories

Newly supported devices are likely to use a wide variety of possible build systems, so no single standard source
tree can be prescribed. The [support repository for ESP32](https://github.com/Azure/azure-iot-pal-esp32) is the
one we recommend considering as a model for creating a new device support repository.

repository: Azure/azure-c-shared-utility

gha_language: C

gha_license_id: NOASSERTION

repo_name: Azure/azure-c-shared-utility


text:
[![Build Status](https://drone.io/github.com/GlassyMedia/go-arrays/status.png)](https://drone.io/github.com/GlassyMedia/go-arrays/latest)
[![GoDoc](https://godoc.org/github.com/GlassyMedia/go-arrays?status.png)](https://godoc.org/github.com/GlassyMedia/go-arrays)

## To-do Features

This library is in a pre-release state. I am adding methods as I need them. Pull requests are more than welcomed if there's something that you want included.

- Type assertion
- Predicates
- Type conversion
- Sorting
- Searching

repository: Spokepoint/go-arrays

repo_name: Spokepoint/go-arrays


text:
Date: 2015-11-30 12:08
tags: job, core

Jobs
======================

No, this post is not about recruitment, it's about the [__Jobs__ artifact](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/user-guide/jobs.md) that was introduced with version 1.1.

Jobs are the way in Kubernetes of running on-off containers (or pods). Until now, to run a container you could define a pod and schedule it without a replication controller. Now, we have the concept of a "job". In reality, "Task" would be more appropriate, but as we can see in the roadmap, scheduling jobs will come in version 1.2.

If we read the definition in the docs it says:

    A job creates one or more pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the job tracks the successful completions. When a specified number of successful completions is reached, the job itself is complete. Deleting a Job will cleanup the pods it created.

So, What can we do with jobs now? One of the things we do is to run Integration Test. You deploy your artifacts: pods, replication controllers, and servcies and then, we run a job to test that everything works as expected.

Building a CI pipeline is hard. Using kubernetes simplifies a bit certain aspects (like the deployment) but it makes harder other bits (like knowing when everything is ready). We're preparing a big post about CI, so, stay tunned.

A job definition is very similar to a Replication controller or a Pod:

    apiVersion: extensions/v1beta1
    kind: Job
    metadata:
      name: pi
    spec:
      selector:
        matchLabels:
          app: pi
      template:
        metadata:
          name: pi
          labels:
            app: pi
        spec:
          containers:
          - name: pi
            image: perl
            command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
          restartPolicy: Never

Note that the __apiVersion__ uses [extensions](https://github.com/kubernetes/kubernetes/blob/release-1.1/docs/api.md#api-groups). The schema of a job will change once the scheduling features land in version 1.2, but for now, it's very straight forward: define the artifact kind as a job, include the pod template definition and off you go. Another thing to note is the __restartPolicy__, you can set it to Always, OnFailure, or Never, depending on what you think it's appropriate.

gha_language: HTML


text:
# Pure functions vs procedures

### A pure function - a `function` that maps `arguments` to results.

```js
function double(num) {
  return num * 2
}

console.log(double(10))
//result - 20
```

### An impure function - a `function` as `procedure` - `function` with side-effect.

In the example below the `function` "user" reassigns a new value to "count" `variable`, that is out of the `scope` of the `function` itself.

```js
let count = 0

function user(num) {
  count = count + num
}

console.log(user(10),
  		    count)
// result - count itself was changed to 10

function check(countValue) {
  if (countValue === 0) {
    return "success"
  } else {
    return "error"
  }
}
console.log(check(count))
//result - "error", cos the count itself was already changed to 10
```
### One more example of a pure function

```js
const permissions = {
  isAdmin: true,
  name: "Anastasia",
}

// 1. function gets called
// 2. first argument of this function gets parametarized, means the passed arguments in this case "permissions" variable, becomes "user" parameter in the function.
// pure function: maps arguments to results

function checkPermission(user) {
  const isAdmin = user.isAdmin
  const name = user.name

  if (isAdmin) {
    return "success"
  } else {
    return "error"
  }
}

console.log(
    checkPermission({isAdmin: true, name: "Anastasia"}),
  	checkPermission(permissions),
)
//result - "success"
//result - "success"
```

In `const` variable if it is an `object` or `array`. You can still change the properties.

```js
const user2 = {name: "Anastasia"}

// pure function: maps arguments to results
function getName(user2){
  const name = user2.name
  return name
}

console.log(getName(user2))
//result - "Anastasia"

// function as procedure (function with side-effect)
function changeName(user2){
  const name = user2.name
  user2.name = "Dimitri"
  return user2
}

console.log(
  		changeName(user2),
  		user2
)
//result - {name: "Dimitri"}
```

### Example

```js
// race is in the global scope, and can be accessed/modified by any functions
const race = "100m Dash"
const winners = ["Hunter Gath", "Singa Song", "Imda Bos"];

// in parens (winner , i, array) are called parameters
const make = (winner, i, array) => ({name: winner, race: race, place: i + 1})

//const win = winners.map(make) - behind the scenes
// const win = winners.map(make(winner[0], 0))
// const win = winners.map(make(winner[1], 1))
// const win = winners.map(make(winner[2], 2))
const win = winners.map(make)
// win function is impure

const pureWin = (winners, race)=> {
  const result = winners.map((winner, i) => ({name: winner, race: race, place: i +1}))
  return result
}

const result = pureWin(winners, race)

console.log(
  win,
  result,
)

//result [{...}, {...},{...}]
//0: {name: "Hunter Gath", race: "100m Dash", place: 1}
//1: {name: "Singa Song", race: "100m Dash", place: 2}
//2: {name: "Imda Bos", race: "100m Dash", place: 3}
```

url: https://raw.githubusercontent.com/anmud/learntocode/7a7fcd3f4922f3029c74fba1596d20f9181f7c06/Dimi's classes/001_Pure functions vs procedures.md

repository: anmud/learntocode

filename: 001_Pure functions vs procedures.md

repo_name: anmud/learntocode


text:
Rxact Xstream

[![npm version](https://img.shields.io/npm/v/rxact-xstream.svg?style=flat-square)](https://www.npmjs.com/package/rxact-xstream)
[![CircleCI master](https://img.shields.io/circleci/project/github/Darmody/rxact-xstream/master.svg?style=flat-square)](https://circleci.com/gh/Darmody/rxact-xstream/tree/master)
[![Coveralls master](https://img.shields.io/coveralls/github/Darmody/rxact-xstream/master.svg?style=flat-square)](https://coveralls.io/github/Darmody/rxact-xstream)

Rxact Xstream is a Rxact plugin for adding Xstream supporting to Rxact.

## Installation

```
  yarn add rxact rxact-xstream
```

## Usage

```javascript
  import { setup, StateStream } from 'rxact'
  import { Observable } from 'rxact-xstream'

  setup({ Observable: Observable })
  // it works now.

  const stream = new StateStream('stream', { name: 'rxact' })

  // state$ is a xstream instance now.
  stream.state$
  ...
```

## License

[MIT](https://github.com/Darmody/rxact-xstream/blob/master/LICENSE)

repository: Darmody/rxact-xstream

repo_name: Darmody/rxact-xstream


text:
# master

- Compatibility with the latest `juniper`.

# [[0.6.4] 2021-06-07](https://github.com/graphql-rust/juniper/releases/tag/juniper_warp-0.6.4)

- Compatibility with the latest `juniper`.

# [[0.6.3] 2021-04-03](https://github.com/graphql-rust/juniper/releases/tag/juniper_warp-0.6.3)

- Compatibility with the latest `juniper`.

# [[0.6.2] 2021-01-27](https://github.com/graphql-rust/juniper/releases/tag/juniper_warp-0.6.2)

- Compatibility with the latest `juniper`.

# [[0.6.1] 2021-01-15](https://github.com/graphql-rust/juniper/releases/tag/juniper_warp-0.6.1)

- Compatibility with the latest `juniper`.

# [[0.6.0] 2020-12-09](https://github.com/graphql-rust/juniper/releases/tag/juniper_warp-0.6.0)

- Compatibility with the latest `juniper`.
- Changed the implementation place of GraphQLBatchRequest and GraphQLBatchResponse in `juniper_warp`
to `juniper` to be reused in other http integrations, since this implementation was private.

## Breaking Changes

- Update `playground_filter` to support subscription endpoint URLs.
- Update `warp` to 0.2.
- Rename synchronous `execute` to `execute_sync`, add asynchronous `execute`
- `juniper_warp::graphiql_filter` now requires a second parameter for subscriptions.
- `make_graphql_filter` and `make_graphql_filter_sync` now ignore POST HTTP requests with no or invalid `Content-Type` header.

# [[0.5.2] 2019-12-16](https://github.com/graphql-rust/juniper/releases/tag/juniper_warp-0.5.2)

- Compatibility with the latest `juniper`.

# [[0.5.1] 2019-10-24](https://github.com/graphql-rust/juniper/releases/tag/juniper_warp-0.5.1)

- Compatibility with the latest `juniper`.

# [[0.5.0] 2019-09-29](https://github.com/graphql-rust/juniper/releases/tag/juniper_warp-0.5.0)

- Compatibility with the latest `juniper`.

# [[0.4.1] 2019-07-29](https://github.com/graphql-rust/juniper/releases/tag/juniper_warp-0.4.1)

- Compatibility with the latest `juniper`.

# [[0.4.0] 2019-07-19](https://github.com/graphql-rust/juniper/releases/tag/juniper_warp-0.4.0)

- Compatibility with the latest `juniper`.

# [[0.3.0] 2019-05-16](https://github.com/graphql-rust/juniper/releases/tag/juniper_warp-0.3.0)

- Compatibility with the latest `juniper`.

# [0.2.0] 2018-12-17

- **[Breaking Change]** The minimum required `warp` version is now `0.1.8`.

  [#271](https://github.com/graphql-rust/juniper/pull/271)

- **[Breaking Change]** The `graphql_handler` and `graphiql_handler` functions have been renamed to`graphql_filter` and `graphiql_filter` respectively.

  [#267](https://github.com/graphql-rust/juniper/pull/267)

- **[Breaking Change]** A `CpuPool` from `futures_cpupool` is no longer used. Instead, `warp`'s underlying `tokio_threadpool` is leveraged. Because of this, `make_graphql_filter_with_thread_pool` is no longer necessary and has been removed.

  [#258](https://github.com/graphql-rust/juniper/pull/258)

# juniper_warp [0.1] 2018-09-13

- Initial Release

repository: LegNeato/juniper

gha_language: Rust

repo_name: LegNeato/juniper


text:
---
title: Memo Q&A
date: 2066-06-06
---

Q: Can you insert a iptable rule with a non-existent interface ?
A: Yes, You can insert any iptable rule like
	`ip6table -A OUTPUT -o abcdefg -p ipv6-icmp --icmpv6-type router-solicitation -j DROP`.

Q: How much memory can be allocated by the malloc command ?
A: [Link](https://www.zhihu.com/question/20836462/answer/1750349532)


text:
# destroy, destruction, annihilate

## Definition:

The term “destroy” means to completely make an end to something, so that it no longer exists.

* The term “destroyer” means “a person who destroys.”
* This term is often used in the Old Testament as a general reference to anyone who destroys other people, such as an invading army.
* When God sent the angel to kill all the firstborn males in Egypt, that angel was referred to as “the destroyer of the firstborn.” This could be translated as “the one (or angel) who killed the firstborn males.”
* In the book of Revelation about the end times, Satan or some other evil spirit is called “the Destroyer.”

(See also: [angel](../kt/angel.md), [Egypt](../names/egypt.md), [firstborn](../other/firstborn.md), [Passover](../kt/passover.md))

## Bible References:

* [Exodus 12:23](rc://en/tn/help/exo/12/23)
* [Hebrews 11:28](rc://en/tn/help/heb/11/28)
* [Jeremiah 06:26](rc://en/tn/help/jer/06/26)
* [Judges 16:24](rc://en/tn/help/jdg/16/24)

## Word Data:

* Strong’s: H6, H7, H622, H398, H1104, H1197, H1820, H1826, H1942, H2000, H2015, H2026, H2040, H2254, H2255, H2717, H2718, H2763, H2764, H3238, H3341, H3381, H3423, H3582, H3615, H3617, H3772, H3807, H4191, H4229, H4591, H4658, H4889, H5218, H5221, H5307, H5362, H5420, H5422, H5428, H5595, H5642, H6365, H6789, H6979, H7665, H7667, H7703, H7722, H7760, H7843, H7921, H8045, H8074, H8077, H8316, H8552, G355, G396, G622, G853, G1311, G1842, G2049, G2506, G2507, G2647, G2673, G2704, G3089, G3645, G4199, G5351, G5356

repository: mandolyte/obsidian-ebook

branch_name: refs/heads/main

repo_name: mandolyte/obsidian-ebook


text:
This intrinsic function assigns zero or more elements of its source to the corresponding target variable(s). It returns a copy of the source.  For example:

```Hack
$v = vec[10, 20, 30, 40];
list($_, $b, $_, $d) = $v;
```

When the source is a vec, the element having an `int` key of 0 is assigned to the first target variable, the element having an `int` key
of 1 is assigned to the second target variable, and so on, until all target variables have been assigned.

If `$_` is used as a target variable, the value of the corresponding source element is ignored; no assignment takes place.

If the source elements and the target variables overlap in any way, the behavior is unspecified.

Here is an example of a source tuple:

```Hack
list($x1, $x2, $x3) = tuple(123, "red", tuple(2.5, 999));
```

Elements 0, 1, and 2, respectively, of the tuple are assigned to `$x1`, `$x2`, and `$x3`, which have types `int`, `string`, and tuple-of-`float`-and-`int`.

```Hack
list($y1, $y2, list($y3, $y4)) = tuple(123, "red", tuple(2.5, 999));
```

Here, the target contains a nested list, in which case, elements 0 and 1 of the nested tuple are assigned to `$y3` and `$y4`, respectively.

repository: carlendev/user-documentation

repo_name: carlendev/user-documentation


text:
# Getting Started

To begin using Temple, load it into your environment.

- Download the latest version from our [release page](https://github.com/BeneathTheInk/Temple/releases) and use via a script tag.

	```html
	<script type="text/javascript" src="temple.js"></script>
	<script type="text/javascript">
		Temple.render("<my-template>Hello World</my-template>");
	</script>
	```

- For Browserify or Node.js, install via NPM.

	```sh
	$ npm install templejs
	```

	```js
	var Temple = require("templejs");
	Temple.render("<my-template>Hello World</my-template>");
	```

### A Basic View

Using Temple is really simple; all you need is some data, a template, and a place in the DOM to put everything. Let's use an altered version of the example in the [Mustache manpage](http://mustache.github.io/mustache.5.html).

1. A typical Temple M+XML template:

	```html
	<my-template>
		<script>
		this.helpers({
			after_taxes: function(val) {
				return val - (val * 0.4);
			},
			format_money: function(dollars) {
				return "$" + dollars.toFixed(2);
			}
		});
		</script>

		<p>Hello {{ name }}</p>
		<p>You have just won <b>{{ value | format_money }}</b>!</p>
		{{# in_ca }}
		<p><small>Well, {{ value | after_taxes | format_money }}, after taxes.</small></p>
		{{/ in_ca }}
	</my-template>
	```

2. Given the following data:

	```json
	{
		"name": "Chris",
		"value": 10000,
		"in_ca": true
	}
	```

3. Will produce the following in the `document` body:

	```html
	<my-template>
		<p>Hello Chris</p>
		<p>You have just won <b>$10000.00</b>!</p>
		<p><small>Well, $6000.00, after taxes.</small></p>
	</my-template>
	```

4. When rendered using the following JavaScript:

	```js
	Temple.render(template);
	var view = Temple.create("my-template", data).paint("body");
	```

The `.render()` method compiles the _template_ and turns them into view classes. Next, the `.create()` creates an instance of the template with some _data_. Finally, `.paint()` renders the view and appends it to the bottom of `<body>` as matched by the `"body"` CSS selector. Now rendered, the view is reactive and will update for any changes to data until it is removed from the DOM by calling `.detach()`.

repository: gitter-badger/Temple

repo_name: gitter-badger/Temple


text:
# Regular expression injection
Constructing a regular expression with unsanitized user input is dangerous as a malicious user may be able to modify the meaning of the expression. In particular, such a user may be able to provide a regular expression fragment that takes exponential time in the worst case, and use that to perform a Denial of Service attack.

## Recommendation
Before embedding user input into a regular expression, use a sanitization function such as lodash's `_.escapeRegExp` to escape meta-characters that have special meaning.

## Example
The following example shows a HTTP request parameter that is used to construct a regular expression without sanitizing it first:

```javascript
var express = require('express');
var app = express();

app.get('/findKey', function(req, res) {
  var key = req.param("key"), input = req.param("input");

  // BAD: Unsanitized user input is used to construct a regular expression
  var re = new RegExp("\\b" + key + "=(.*)\n");
});

```
Instead, the request parameter should be sanitized first, for example using the function `_.escapeRegExp` from the lodash package. This ensures that the user cannot insert characters which have a special meaning in regular expressions.

```javascript
var express = require('express');
var _ = require('lodash');
var app = express();

app.get('/findKey', function(req, res) {
  var key = req.param("key"), input = req.param("input");

  // GOOD: User input is sanitized before constructing the regex
  var safeKey = _.escapeRegExp(key);
  var re = new RegExp("\\b" + safeKey + "=(.*)\n");
});

```

## References
* OWASP: [Regular expression Denial of Service - ReDoS](https://www.owasp.org/index.php/Regular_expression_Denial_of_Service_-_ReDoS).
* Wikipedia: [ReDoS](https://en.wikipedia.org/wiki/ReDoS).
* npm: [lodash](https://www.npmjs.com/package/lodash).
* Common Weakness Enumeration: [CWE-730](https://cwe.mitre.org/data/definitions/730.html).
* Common Weakness Enumeration: [CWE-400](https://cwe.mitre.org/data/definitions/400.html).


text:
# java-orders

A student that completes this project shows that they can:
* perform CRUD operations on an RDBMS using JPA and Hibernate.

## Introduction

This is a basic database scheme with customers, orders, and sales agents.

## Instructions

Create a REST api server to store and read data from an in memory H2 database.

The table layouts are as follows

* AGENTS
  * AGENTCODE primary key, not null Long
  * AGENTNAME string
  * WORKINGAREA string
  * COMMISSION double
  * PHONE string
  * COUNTRY string

* CUSTOMERS
  * CUSTCODE primary key, not null Long
  * CUSTNAME String, not null
  * CUSTCITY String
  * WORKINGAREA String
  * CUSTCOUNTRY String
  * GRADE String
  * OPENINGAMT double
  * RECEIVEAMT double
  * PAYMENTAMT double
  * OUTSTANDINGAMT double
  * PHONE String
  * AGENTCODE Long foreign key (one agent to many customers) not null

* ORDERS
  * ORDNUM primary key, not null Long
  * ORDAMOUNT double
  * ADVANCEAMOUNT double
  * CUSTCODE Long foreign key (one customer to many orders) not null
  * ORDERDESCRIPTION String

* PAYMENTS
  * PAYMENTID primary key, not null long
  * TYPE String not null

* ORDERSPAYMENTS (join table)
  * ORDERNUM foreign key to ORDERS
  * PAYMENTID foreign key to PAYMENTS.

* Customers has a foreign key to Agents (AGENTCODE) this means:
  * Customers has a Many to One relationship to Agents and
  * Agents has a One to Many relationship to Customers

* Orders has a foreign key to Customers (CUSTCODE)
  * Orders has a Many to One relationship to Customers and
  * Customers has a One to Many relationship to Orders

* Orders has a many to many relationship with payments
  * multiple orders can use the same payment type and an order can have multiple payment types.
  * For example you can use both gift card and credit card to pay for an order.

* Create the entities needed to store this data
* A data.sql file has been provided with seed data. You can use this class directly or modify it to fit your models. However, the data found in the file is the seed data to use!


text:
## Compare two Linked Lists

If two linked lists are given as:

Linked List 1: 1->2->3->4

Linked List 2: 1->4->5->7

Then Compare them and if the lists are equal, print "Lists are equal"

else print "Lists are not equal".

In this case "Lists are not equal" will bwe printed.

url: https://raw.githubusercontent.com/Aryaman-Pandey187/Hacktoberfest_2021/3855ded44c61b562d00cdf8a91f9019a5b7bb592/Task 1/Compare Two Linked List/Question.md


text:
# Note Taking Application

[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)

- Github Repo: https://github.com/jacksolaro/note_taking_app
- Deployed App: https://notetakingappjack.herokuapp.com/

[![Demo](https://github.com/jacksolaro/note_taking_app/blob/main/app_demo.gif?raw=true)

## DESCRIPTION
---------------------
This application allows a user to write and save notes for future reference.

## TABLE OF CONTENTS
---------------------

* [Installation](#installation)
* [Usage](#usage)
* [Tests](#tests)
* [License](#license)
* [Contributions](#contributions)
* [Questions](#questions)

## INSTALLATION
------------
To use this repo, you must install node js

## USAGE
------------
This application is hosted at https://notetakingappjack.herokuapp.com/. To use:
1. Click the button to go to the notes page.
2. On the notes page you can click the note title and note text to fill with info.
3. Then click the save button in the top right to save that note to memory.
4. To edit a note in memory, just select it from the list of notes on the left side of the screen.
5. To delete a note, select the trash icon on the note you would like to delete.

## TESTS
------------
No testing instructions at this time

## FUTURE RELEASES
------------
In future release, I would love to add the ability to edit a previous note as well as some rich text capabilities like bold, underline, etc

## LICENSE
------------
This repository is covered under the [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT) license.

## CONTRIBUTIONS
------------

## QUESTIONS
------------
Please direct all questions related to this repository to https://github.com/jacksolaro


text:
# ThesisUtils

This package controls the appearance of the plots in my thesis.

## `autofig(plotfunc, name, size)`

The function `autofig` wraps your plot command with the appropriate machinery to set the fonts, appearance and figure size appropriately.
You provide it with a function that returns a plot, a name, and the desired size of the figure.
The size can be any one of `Margin`, `Normal` or `Full`.
`autofig` makes the plot, displays it, and also saves it as a pdf under the directory `autofigs/`.

## `placeholder()`

There is also a `placeholder` function that makes a placeholder plot, which you can use by calling `placeholder()`.

[![Build Status](https://travis-ci.org/swt30/ThesisUtils.jl.svg?branch=master)](https://travis-ci.org/swt30/ThesisUtils.jl)

[![Coverage Status](https://coveralls.io/repos/swt30/ThesisUtils.jl/badge.svg?branch=master&service=github)](https://coveralls.io/github/swt30/ThesisUtils.jl?branch=master)

[![codecov.io](http://codecov.io/github/swt30/ThesisUtils.jl/coverage.svg?branch=master)](http://codecov.io/github/swt30/ThesisUtils.jl?branch=master)


text:
# Release process

## Shipping a new version

1. Ensure you are running on the oldest supported Erlang version

2. Update version in /VERSION, bin/elixir and bin/elixir.bat

3. Ensure /CHANGELOG.md is updated, versioned and add the current date

4. Update "Compatibility and Deprecations" if a new OTP version is supported

5. Commit changes above with title "Release vVERSION" and generate a new tag

6. Run `make clean test` to ensure all tests pass from scratch and the CI is green

7. Recompile an existing project (for example, Ecto) to ensure manifests can be upgraded

8. Push branch and the new tag

9. Publish new zips with `make zips`, upload `Precompiled.zip` and `Docs.zip` to GitHub Releases, and include SHAs+CHANGELOG

10. Add the release to `elixir.csv` (all releases), update `erlang.csv` to the precompiled OTP version, and `_data/elixir-versions.yml` (except for RCs) files in `elixir-lang/elixir-lang.github.com`

11. Send an e-mail to<EMAIL_ADDRESS>with title "Elixir vVERSION released". The body should be a link to the Release page on GitHub and the checksums. If it is a security release, prefix the title with the `[security]` tag

## Creating a new vMAJOR.MINOR branch

### In the new branch

1. Set `CANONICAL=` in /Makefile

2. Update tables in /SECURITY.md and "Compatibility and Deprecations"

3. Commit "Branch out vMAJOR.MINOR"

### Back in master

1. Bump /VERSION file, bin/elixir and bin/elixir.bat

2. Start new /CHANGELOG.md

3. Update tables in /SECURITY.md in "Compatibility and Deprecations"

4. Commit "Start vMAJOR.MINOR+1"

repository: rizalgowandy/elixir

gha_language: Elixir

repo_name: rizalgowandy/elixir


text:
# Cosmos DB SQL API: Data Plane RBAC for Azure Active Directory Credentials

This is a sample application for testing Role Based Access Contro (RBAC) for data stored in Cosmos DB (SQL API). This demonstration assumes the following:

1. Administrative control over a Cosmos DB account
2. PowerShell is installed
3. [Azure CLI](https://docs.microsoft.com/en-us/cli/azure/install-azure-cli) version 2.23.0 or higher installed

## Configure Application Settings

Download the [latest build of the sample application](https://github.com/travisnielsen/cosmos-aad-rbac/releases).

In the same directory hosting `CosmosRbac.exe`, create a new file called `appsettings.json` and populate it with the following data:

```json
{
    "endPointUrl": "https://trniel.documents.azure.com",
    "database": "test",
    "container": "demo",
    "AZURE_CLIENT_ID": "",
    "AZURE_TENANT_ID": "",
    "AZURE_CLIENT_SECRET": ""
}
```

Update the values to match your environment. If you plan to use a Service Principal in your testing, update the values of `AZURE_CLIENT_ID`, `AZURE_TENANT_ID`, and `AZURE_CLIENT_SECRET`. Otherwise, leave these settings blank. The application will then use your browser for interactive authentication.

## Configure AAD RBAC

Copy the two .json role definition files located in the `roles` folder of this repo to a folder on your workstation. Open a PowerShell terminal and navigate to that directory. Run the following commands to create role definitions for your Cosmos DB account. The resulting IDs are stored in PowerShell variables.

```powershell
$resourceGroupName='<yourResourceGroup>'
$accountName='<yourCosmosAccount>'

az login

# Make sure Azure CLI is pointing to the subscription you want to work in
az account set --subscription "<your-subscription-name>"

az cosmosdb sql role definition create --account-name $accountName --resource-group $resourceGroupName --body @role-definition-ro.json
$roleDefIdReadOnly = az cosmosdb sql role definition list --account-name $accountName --resource-group $resourceGroupName --query "[?roleName=='MyReadOnlyRole'].name" --out tsv

az cosmosdb sql role definition create --account-name $accountName --resource-group $resourceGroupName --body @role-definition-rw.json
$roleDefIdReadWrite = az cosmosdb sql role definition list --account-name $accountName --resource-group $resourceGroupName --query "[?roleName=='MyReadWriteRole'].name" --out tsv
```

Next, use *either* of the following two options to get the object ID of the account you will be granting permissions to:

```powershell
# Interactive User account
$principalId = az ad user show --id<EMAIL_ADDRESS>--query objectId --out tsv

# Service Principal
$spDisplayName = "<yourServicePrincipalName>"
$principalId = az ad sp list --display-name $spDisplayName --query "[?appDisplayName=='$spDisplayName'].objectId" -o tsv
```

Finally, assign the `$principalId` to the `MyReadWriteRole` via the following command:

```powershell
az cosmosdb sql role assignment create --account-name $accountName --resource-group $resourceGroupName --scope "/" --principal-id $principalId --role-definition-id $roleDefIdReadWrite
$assignmentRW = az cosmosdb sql role assignment list --account-name $accountName --resource-group $resourceGroupName --query "[?principalId=='$principalId'].name" --out tsv
```

## Run Tests

Make sure that `CosmosRbac.exe` and your `appsettings.json` file are in the same directory and execute the following command to insert a record. If you assigned the `$principalId` to a user account, you will be prompted to authenticate via your browser.

### Insert Record (read/write role assigned)

```powershell
.\CosmosRbac.exe create '"{ \"firstName\": \"Joe\", \"lastName\": \"Smith\" }"'
```

You should see a JSON response similar to this:

```bash
{"id":"4c8854db-ab50-4f1f-a7f4-6879a6c9ccd1","firstName":"Joe","lastName":"Smith"}
```

If not, make sure your `appsettings.json` file is configured correctly. If your `$principalId` is assigned to an AAD Service Principal, make sure the values are correctly set in the file.

### Insert Record (no role)

Remove the role assignment and re-try creating a record.

```powershell
az cosmosdb sql role assignment delete --account-name $accountName --resource-group $resourceGroupName --role-assignment-id $assignmentRW --yes

.\CosmosRbac.exe create '"{ \"firstName\": \"Joe\", \"lastName\": \"Smith\" }"'
```

You should see a response similar to the following:

```bash
Response status code does not indicate success: Forbidden (403); Substatus: 5301; ActivityId: eb482ff1-adbc-47f5-9d34-6d18e71bd9e0; Reason: (Request blocked by Auth trniel : Request is blocked because principal [a2461c6f-d982-481a-ca03-1ad4798a90ff] does not have required RBAC permissions to perform action [Microsoft.DocumentDB/databaseAccounts/readMetadata] on resource [/].
```

### Insert Record (read role)

Now assign your `$principalId` the read role and attempt to insert a record:

```powershell
az cosmosdb sql role assignment create --account-name $accountName --resource-group $resourceGroupName --scope "/" --principal-id $principalId --role-definition-id $roleDefIdReadOnly

.\CosmosRbac.exe create '"{ \"firstName\": \"Joe\", \"lastName\": \"Smith\" }"'
```

You should see the same error as in the previous test.

### Read Records (read role)

Finally, read the records previous inserted into Cosmos DB. This should work

```powershell
.\CosmosRbac.exe create
```

You should see at least one record returned. This is becuase your `$principalId` was assigned the read role.

```bash
{"id":"4c8854db-ab50-4f1f-a7f4-6879a6c9ccd1","firstName":"Joe","lastName":"Smith"}
```

repository: travisnielsen/cosmos-aad-rbac

repo_name: travisnielsen/cosmos-aad-rbac


text:
---
layout: layout.pug
navigationTitle:  Release notes
title: Release notes
menuWeight: 101
excerpt: Provides release-specific information for Edge-LB
enterprise: true
---

These Edge-LB Release Notes summarize release-specific changes that fix issues or update Edge-LB features for DC/OS™ Enterprise clusters.

# DC/OS for Edge-LB Service version 1.5.1 Release Notes

Edge-LB Service version 1.5.1 was released on 17 December 2019.

## Bug Fixes
- Edge-LB TLS certificates now include the full bundle of intermediate certificates in the CC's cert. (DCOS-60770)
- Edge-LB 1.5 is now using the correct container IP address. (DCOS-60517)

## Other Changes
- Upgraded SDK version to v0.57.2 to resolve a deployment issue.
- Began collecting diagnostic bundle for all pools, by default.

## Known issues and limitations
- Auto Pool updates slow down as the number of templates increases, or as large changes to the Apache® Mesos® state occur, such as many apps starting or stopping.

# DC/OS for Edge-LB Service version 1.5.0 Release Notes

Edge-LB Service version 1.5.0 was released on 30 October 2019.

## Breaking Changes
- Templates now use [Sprig](http://masterminds.github.io/sprig/) template functions instead of custom functions. The [`env`](http://masterminds.github.io/sprig/os.html) functions are not exposed to templates.

## Deprecation
- The v1 API is now deprecated and D2iQ® may remove it in a future release.

## New features and capabilities
- The Auto Pools feature allows self-service configuration, and can automatically start a pool from a template with values from Apache® Mesos® task labels.
- The certificate generated for `$AUTOCERT` is now valid for 10 years and has a random serial number.
- Updates the SDK version from 0.55.2 to 0.57.0.
- Adds `apiserver`, `cloud-controller`, `dcos-template`, `lbmgr`, and `mesos-listener` exporter for metrics.
- Metric names renamed in line with Prometheus community guideline.
- The `apiserver` now uses `container/bridge` network type.
- [Pool constraints](/mesosphere/dcos/services/edge-lb/1.5/reference/pool-configuration-reference/v2-reference/#pool) now support region placement constraints.

## Known issues and limitations
- Auto Pool updates become slower as the number of templates increases, or as large changes to the Mesos state occur, such as many apps starting or stopping.

# Edge-LB version 1.4
Edge-LB service version 1.4.0 was released June 24, 2019.

## New features and capabilities
- Introduces automatic provisioning and lifecycle management for AWS® Network Load Balancers® (NLB®).
- Adds a new command-line program for removing AWS load balancer instances created for Edge-LB, if you uninstall Edge-LB.
- Provides a new command-line program for collecting logs and creating diagnostic bundles for Edge-LB operations.
- Updates the HAProxy® version to 2.0.1
- Updates the Golang version to 1.12.7
- Removes the use of sidecar
- Adds haproxy exporter for HAProxy metrics

# Edge-LB version 1.3.1
Edge-LB service version 1.3.1 was released April 29, 2019.

### New features and capabilities
* Includes Apache Mesos health checks when generating the list of active backends.
* Provides Edge-LB artifacts as a .dcos package bundle.
* Updates the SDK version from 0.55.2 to 0.55.4.
* Updates the HAProxy version to 1.9.4.
* Improves support for dynamically-allocated frontend ports.
* Displays the frontend name in the output for the dcos edgelb endpoints command.
* Improves the stability and scalability for the Edge-LB pool dcos-template and in the `mesos-listener` program.
* Provides additional test coverage and other improvements in existing Edge-LB integration tests.

### Issues fixed in this release
* DCOS-45719 - Edge-LB waits for load balanced applications to to be running in a healthy state before routing traffic to them. This change prevents Edge-LB from routing traffic to an application before it completes its startup operations and its first health check.
* DCOS-47839 - Users can specify the Edge-LB pool frontend using either the name or port setting.
* DCOS-44077 - The Mesos-listener program that communicates with Edge-LB includes improvements to tests coverage and code refactoring.
* DCOS-51865 - Edge-LB contiuous integration has been enhanced through testing and code refactoring.
* DCOS-48059 - Edge-LB can successfully return the task id and task status for both server and sidecar tasks.
* DCOS-46502 - Validates regular expressions from user input.
* DCOS-48132 - The Edge-LB dcos-template monitors and reloads its configuration file to prevent Edge-LB pool updates from generating errors when there are frequent pool changes.

# Edge-LB version 1.3.0
Edge-LB service version 1.3.0 was released February 6, 2019.

### New features and capabilities
* Simplifies and optimizes the HAProxy load balancer reload loop.
* Improves the update strategy for the Edge-LB pool.
* Updates the SDK version used by Edge-LB to 0.55.2.
* Adds protection against installing a pool while its previous version is still uninstalling.
* Improves sidecars runs.
* Improves integration test coverage.
* Provides better error messages and logging.

### Issues fixed in this release
* COPS-4272, DCOS-46189 - Restores Edge-LB artifacts that were missing on the Mesosphere Edge-LB Downloads page.
* DCOS-46043 - Updates the Edge-LB API server’s file comparison functions to provide more accurate information.
* DCOS-46510 - Supports load balancer configuration settings that include duplicate backends.
* DCOS-46837 - Protects against installing a pool with given name while a different pool with the same name is still uninstalling. This change prevents the framework scheduler from crashes caused by conflicting uninstall and install operations.
* DCOS-48009 - Updates the location used for `$ENVFILE` certificates to match the location where the Edge-LB load balancer expects to find them.

# Edge-LB version 1.2 series
This section summarizes changes integrated into Edge-LB from Edge-LB 1.2.0 (September 2018) to Edge-LB 1.2.3 (November 2018), with the most recent changes listed first.

### Edge-LB version 1.2.3
Released on November 27, 2018.

* `lbmgr`: Enforces the timeout during the connection phase of the health check command.
* `apiserver`: Makes health checks for pool tasks configurable using the following new pool parameters:
  * `poolHealthcheckGracePeriod` - Defines the period of time after start of the pool container when failed health checks will be ignored (default: 180s).
  * `poolHealthcheckInterval` - Defines the health check execution interval. At most, one health check is going to execute at any given time (default: 12s).
  * `poolHealthcheckMaxFail` - Defines how many consecutive failures mark the task as failed before forcing Mesos to kill it (default: 5).
  * `poolHealthcheckTimeout` - Defines the timeout enforced by Mesos on the healthcheck execution. It includes the container startup (fetch, setup, start, etc...) as well as the time spent by the healthcheck command executing the test.

#### Issues fixed in this release
* COPS-3951, DCOS-43677 - Prevents load balancing tasks from being killed intermittently. This change helps to prevent service outages for applications that are being load balanced.
* COPS-4127, DCOS-45184 - Prevents Edge-LB pools from being KILLED to due missing `/var/state/haproxy/global` files.

### Edge-LB version 1.2.2
Released on November 15, 2018.

* lbmgr:
  * Instead of shelling out to use the `socat` utility, `lbmgr` now natively handles communication with the HAProxy load balancer.
  * Adds more information about successful and failed health checks, including the size of the reply, the time it took to write the command, the time required to fetch the result, and the total time for the operation to complete.
    * Sets the health check timeout to 9 seconds. This timeout expires one second sooner than the default Mesos health check. This change helps you identify when the timeout occurred.
* mesos-listener:
    * Adds support for TASK_GONE_BY_OPERATOR events.
    * Ignores events for non-existent tasks.
    * Marks `goroutines` as done when properly terminated.
    * Prevents overriding of Mesos-failover framework data in carried-over tasks.
    * Prevents carry-over logic from removing frameworks that may still be in use by the tasks in the active snapshot.
    * Prevents sending inactive tasks to the clients. Only tasks in the TASK_RUNNING state are included in the data offered to clients.
    * Increases tests coverage with improved integration tests.
* Updates the SDK used by Edge-LB from 0.42.3 to 0.54.2. This change also updates the Java runtime environment (JRE) to 8u192 from 8u172 to address Java vulnerabilities.
* Updates the HAProxy version used from 1.8.13 to 1.8.14.
* Pool task container improvements:
  * Uses the `-slim` version of Debian for smaller containers.
  * Includes basic debugging tools during installation.
  * Make `LBWORKDIR` the working directory of the container.
  * Removes unnecessary tooling regarding `iptables`, `syslogd`, and other programs.
  * Copies only the necessary artifacts into the container during the build (for example, does not include the Dockerfile).
  * Supports verbose output when copying files during the container startup operation.

#### Issues fixed in this release
* COPS-3823, DCOS-42154 - Fixes a problem in the Edge-LB default template for server name indication (SNI).
* COPS-3891, DCOS-42944 - Improves handling for resource reservations to ensure that Edge-LB pools that have been properly created or relaunched are included when you list pool information using the DC/OS Edge-LB command-line interface (CLI) commands such as `dcos edgelb list` and `dcos edgelb endpoints <pool-name>`.
* COPS-3893, DCOS-42960 - Allows an Edge-LB pool to launch additional load balancer tasks.
* COPS-3901, DCOS-43049 - Reduces the number of sidecars that Edge-LB creates to address segmentation faults in Edge-LB API server logs.
* COPS-4014, DCOS-44199 - Allows Edge-LB pools to be deployed if the app and secret are under namespace/group.
* COPS-4024, DCOS-44207 - Supports strict mode for DC/OS Enterprise clusters and all non-superusers access to Edge-LB pool logs.
* DCOS-41521 - Enables Edge-LB to ignore terminal but not acknowledged tasks from Mesos when subscribing.
* DCOS-43470 - Improves handling for tasks in `mesos-listener` after Mesos master's failover.
* DCOS-43968 - Updates the SDK used by Edge-LB to mitigate Java vulnerability.
* DCOS-44061, DCOS-44346, DCOS-44715 - Improves the Edge-LB build process to support continuous integration.

### Edge-LB version 1.2.1
Released on September 17, 2018.

* Adds a timestamp to log messages produced during continue and start messages.
* Replaces manual log line prefixes with the proper source code file log field.
* Migrates logging to `logrus` to unify logging.
* Increases the log file retention for Edge-LB containers.
* Adds extra logging about the Mesos state snapshot logging for better troubleshooting of Edge-LB.

### Edge-LB version 1.2.0
Released on September 11, 2018.

* dcos-template: Properly handles empty values for some of the Mesos tasks `protobuf` fields.
* dcos-template: Increases the maximum message size allowed by the Edge-LB API server for messages received through gRPC to 100MIB.
* lbmgr: Adjusts how environment variable values are passed to match the new HAProxy service launch model. This change fixes `AUTOCERT` and `SECRET` environment variable handling for the HAProxy task container.
* api-swagger-spec: Bumps the API version to match the Edge-LB version.
* Introduces proper versioning for the `edgelb-pool` package to match the version of the package with the version of the `edgelb` package itself instead of `stub-universe`.
* Changes the output of the `dcos edgelb show --json` command be the actual pool configuration instead of wrapping the output in a configuration container. This change enables you to feed the output of the `show` command directly to the `update` command.
* Cleans up of the goswagger code generation code and build chain, bump of goswagger tool used for generation from v0.11 to v0.16.
* Bumps `golang` from 1.8.3 to 1.10.3.
* Fixes anonymous access control list (ACL) logic for predefined conditions.
* Bumps `haproxy` from 1.8.12 to 1.8.13. [changelog](http://git.haproxy.org/?p=haproxy-1.8.git;a=blob;f=CHANGELOG;h=aed48fc5fb951aff7dd458c4bc9bfcfe1d5dd99a;hb=HEAD).
* Commits `protobuf` code changes that stem from [tool update].(https://github.com/golang/protobuf/tree/master/protoc-gen-go).

WARNING: With the introduction of proper versioning of the `edgelb-pool` package, you must remove any `packageVersion` fields from the pool configuration prior to upgrading.

#### Issues fixed in this release
* COPS-3566, DCOS-39655 - Enables Edge-LB to support the HAProxy `use_backend if` filter.
* COPS-3682, DCOS-40510 - Updates the Edge-LB pool `show --json` command to produce JSON that can be used in a subsequent pool operations.
* COPS-3733, DCOS-40866 - Enables Edge-LB to support automatically-generated certificates using the `AUTOCERT` feature.
* COPS-3736 - Enables Edge-LB to store SSL certificates as secrets.
* COPS-3767, DCOS-41274 - Changes the maximum GRPC message size to prevent high churn of sidecar tasks in the cluster.
* COPS-3768, DCOS-41288/DCOS-41544 - Increases the maximum size of the GRPC message supported by the Edge-LB API server.
* COPS-3769, DCOS-41287 - Improves how the dcos-template handles missing values for Mesos tasks. Previously, the dcos-template would trigger a segmentation fault (SIGSEGV) if values such as a port name, port number, or label were missing. With this release, these values are retrieved using a function that can properly handle fields without value settings.
* COPS-3770, DCOS-41322 - Addresses an issue with applications exposed through Edge-LB encountering 503 errors.

# Edge-LB versions 1.1 and earlier
This section summarizes changes integrated into Edge-LB from Edge-LB 1.0.1 (March 2018) to Edge-LB 1.1.0 (August 2018), with the most recent changes listed first.

### Edge-LB version 1.1.0
Released on August 9, 2018.

* Updates the version of HAProxy used by the pool servers to 1.8.12 from 1.7.6. For details about the changes for any release of HAProxy, see the [HAProxy CHANGELOG](https://www.haproxy.org/) for that release.
* Pool server reloads are no longer blocked by persistent connections.
* Improves stability, reliability, and debugging in the pool server code.
* Reduces the size of the pool container from approximately 250MB to 100MB.
* Improved transitions for Master/Worker mode for HAProxy running on the pool server. If custom configuration templates are used, then they must be updated as follows:
    - The template must not specify the `daemon` option.
    - The template must specify the `expose-fd` listeners parameter in the `stats` socket option.
* Edge-LB now uses the default CLI packages from the DC/OS SDK `edgelb-pool` CLI subcommand.
* Provides a `mesosAuthNZ` package installation option. If this option is set to false, Edge-LB can run on DC/OS 1.10 clusters in `disabled` security mode.

### Edge-LB version 1.0.3
Released on June 6, 2018.

* Updates the DC/OS SDK dependency to require version 0.42.1.
* Fixes a bug that was causing configuration reloads to cause short downtimes of the services behind the load balancer.

###Edge-LB version 1.0.2
Released on March 20, 2018.

* Fixes a bug that caused all V2 API `backend.service` selector fields ending in “Pattern” not to function properly.

### Edge-LB version 1.0.1
Released on March 12, 2018.

* Updates the SDK dependency to require version 0.40.5. This dependency change addresses a bug that could cause a pool scheduler to erroneously destroy one or more Marathon persistent volumes, potentially leading to data loss.

### Edge-LB version 1.0
This section summarizes changes integrated into Edge-LB from Edge-LB 0.1.5 (August 2017) to Edge-LB 1.0.0 (March 2018), with the most recent changes listed first.

### Edge-LB version 1.0.0
Released on March 7, 2018.

* Introduces the Edge-LB REST API version 2 (V2) with a new and more intuitive model for selecting service/app backends.
* Provides a new CLI command structure with the ability to create, modify, and delete individual pools.
* Supports Dockerized builds and other CI improvements.
* Adds strict security mode support for DC/OS Enterprise version 1.11, and newer.
* Includes a security-related fix in logging.
* Supports `curl` using the `-k` option within the same container.
* Updates health checks to MESOS_HTTP.
* Modifies the load balancer manager to connect to the Edge-LB API server through https adminrouter using a service account.
* The pool scheduler uses Mesos V1 API and requires additional service account permissions.
* Improves security for communication between Edge-LB commands and the Edge-LB API server.
* Adds logging to `mesos-listener` and to requests created by the Edge-LB API server.
* Adds the `loglevel` option to the Edge-LB package `install` command to make the API server `logLevel` configurable.

### Edge-LB version 0.1.9
Released on October 6, 2017.

* Fixes a path-routing bug which had resulted in adding a “/” to paths in certain configurations.
* Fixes the `dcos edgelb` command-line interface for clusters with dashboard URLs using `http://` scheme.

### Edge-LB version 0.1.8
Released on September 13, 2017.

* Fixes a scheduler bug for unhandled rescind offers that had resulted in services display an Unhealthy status in the DC/OS GUI.
* Decreases reload wait from 10 seconds to 5 seconds.

### Edge-LB version 0.1.7
Released on September 8, 2017.

* Updates the minimum DC/OS version to 1.10 in the universe package.
* Fixes static virtual IP address parsing in the Edge-LB template.
* Fixes a bug that resulted in stale Edge-LB API server template artifacts.

### Edge-LB version 0.1.6
Released on September 5, 2017.

* Supports the asterisk (*) wildcard for specifying a role in the Edge-LB configuration.

### Edge-LB version 0.1.5
Released on August 30, 2017.

* Fixes HTTP health checks.
* Upgrades HAProxy to 1.7.6, which eliminates a bug found in HAProxy 1.7.3 that caused timeouts to occur with each reload.
* Makes virtual networks configurable.
* Fixes bug with multiple secrets.
* Adds the  `dcos edgelb config --reference` command-line option.

repository: mesosphere/dcos-docs-site

gha_language: SCSS

repo_name: mesosphere/dcos-docs-site


text:
# kustomize 1.0.1

Initial release after move from
[github.com/kubernetes/kubectl]
to [github.com/kubernetes-sigs/kustomize].

History

 * May 2018: v1.0 after move to [github.com/kubernetes-sigs/kubectl]
             from [github.com/kubernetes/kubectl].
             Has kustomization file, bases, overlays, basic transforms.
 * Apr 2018: s/kinflate/kustomize/, s/manifest/kustomization/
 * Oct 2017: s/kexpand/kinflate/
 * Sep 2017: kexpand [starts](https://github.com/kubernetes/kubectl/pull/65)
             in [github.com/kubernetes/kubectl]
 * Aug 2017: [DAM] authored by Brian Grant

[DAM]: https://docs.google.com/document/d/1cLPGweVEYrVqQvBLJg6sxV-TrE5Rm2MNOBA_cxZP2WU

repository: antoniasymeonidou/kustomize

repo_name: antoniasymeonidou/kustomize


text:
# UCCA Parser

An implementation of "[HLT@SUDA at SemEval 2019 Task 1: UCCA Graph Parsing as Constituent Tree Parsing](https://arxiv.org/abs/1903.04153)".

This version of the implementation uses lexical features in the corpus, including POS tags, dependency labels and entity labels, just as described in the paper.

For other models or versions, please see different branches.

## Requirements

```txt
python >= 3.6.0
pytorch == 1.0.0
ucca == 1.0.127
```

Note that the code has not been tested on the newest version of ucca module.

## Datasets

The datasets are all provided by SemEval-2019 Task 1: Cross-lingual Semantic Parsing with UCCA. The official website is https://competitions.codalab.org/competitions/19160.

Pre-trained embeddings: [http://fasttext.cc](http://fasttext.cc/)

## Performance
Here are the results I re-run on June 13, 2019, which are almost the same with the results in the paper.

| description              | dev primary | dev remote | dev average | test wiki primary | test wiki remote | test wiki average | test 20K    primary | test 20K remote | test 20K average |
| ------------------------ | ----------- | ---------- | ----------- | ----------------- | ---------------- | ----------------- | ------------------- | --------------- | ---------------- |
| English-Topdown-Lexical | 79.7        | 52.2       | 79.2        | 77.9              | 48.0             | 77.4              | 74.0                | 23.4            | 73.0             |
| German-Topdown-Lexical  | 82.9        | 57.1       | 82.4        | /                 | /                | /                 | 83.5                | 61.1            | 83.0             |

## Usage

You can start the training, evaluation and prediction process by using subcommands registered in `parser.cmds` or just use the shell scripts included in.

```sh
$ python run.py -h
usage: run.py [-h] {train,predict,evaluate} ...

UCCA Parser.

optional arguments:
  -h, --help            show this help message and exit

Commands:
  {train,predict,evaluate}
    train               Train a model.
    predict             Use a trained model to make predictions.
    evaluate            Evaluate the specified model and dataset.
```

Optional arguments of the subparsers are as follows:

Note that the path to save the model is a directory. After training, there are three files in the directory which are named "config.json"、"vocab.pt" and "parser.pt".

```sh
$ python run.py train -h
usage: run.py train [-h] --train_path TRAIN_PATH --dev_path DEV_PATH
                    [--emb_path EMB_PATH] --save_path SAVE_PATH --config_path
                    CONFIG_PATH [--test_wiki_path TEST_WIKI_PATH]
                    [--test_20k_path TEST_20K_PATH] [--gpu GPU] [--seed SEED]
                    [--threads THREADS]

optional arguments:
  -h, --help            show this help message and exit
  --train_path TRAIN_PATH
                        train data dir
  --dev_path DEV_PATH   dev data dir
  --emb_path EMB_PATH   pretrained embedding path
  --save_path SAVE_PATH
                        dic to save all file
  --config_path CONFIG_PATH
                        dic to save all file
  --test_wiki_path TEST_WIKI_PATH
                        wiki test data dir
  --test_20k_path TEST_20K_PATH
                        20k data dir
  --gpu GPU             gpu id
  --seed SEED           random seed
  --threads THREADS     thread num

$ python run.py evaluate -h
usage: run.py evaluate [-h] --gold_path GOLD_PATH --save_path SAVE_PATH
                       [--batch_size BATCH_SIZE] [--gpu GPU] [--seed SEED]
                       [--threads THREADS]

optional arguments:
  -h, --help            show this help message and exit
  --gold_path GOLD_PATH
                        gold test data dir
  --save_path SAVE_PATH
                        path to save the model
  --batch_size BATCH_SIZE
                        batch size
  --gpu GPU             gpu id
  --seed SEED           random seed
  --threads THREADS     thread num

$ python run.py predict -h
usage: run.py predict [-h] --test_path TEST_PATH --save_path SAVE_PATH
                      --pred_path PRED_PATH [--batch_size BATCH_SIZE]
                      [--gpu GPU] [--seed SEED] [--threads THREADS]

optional arguments:
  -h, --help            show this help message and exit
  --test_path TEST_PATH
                        test data dir
  --save_path SAVE_PATH
                        path to save the model
  --pred_path PRED_PATH
                        save predict passages
  --batch_size BATCH_SIZE
                        batch size
  --gpu GPU             gpu id
  --seed SEED           random seed
  --threads THREADS     thread num

```

## Convertion

Convertion codes are included in `parser.convert`.  The function `UCCA2tree` is used to convert a ucca passage to a tree. The function `to_UCCA` is used to convert a tree to a UCCA passage. Remote edges recovery codes are included in `parser.submodel.remote_parser.py` independently.

--

Cross-lingual parsing (I'll check on my paper #Overleaf)
- Where did I get the tokenization file
-Tokenization and merging (write where the script is)
- Fast_align on tokenized_merged data (where did I get the script ?)

repository: LucasMoncuit/ucca-parser

repo_name: LucasMoncuit/ucca-parser


text:
# Realtime WebSocket using Voice SDK

The WebSocket based real-time API by Symbl provides the direct, fastest and most
accurate of all other interfaces to push the audio stream in real-time, and get
the results back as soon as they're available.

In this example we connect directly using WebSocket API and push audio and get
results in real-time. Including Live Transcript and Insights.

## Getting started

This example runs on node server, so we will use `symbl-node` package.

Open `.env` file and add your APP_ID, APP_SECRET, SUMMARY_EMAIL. You can get
APP_ID and APP_SECRET from
[https://platform.symbl.ai](https://platform.symbl.ai)

```javascript
require('dotenv').config()

const {sdk} = require('symbl-node')
```

For demo purposes, we're using mic to simply get audio from microphone and pass
it on to websocket connection

We use `mic` module so make sure you check that all requirements for the package
are met. For instance we need `sox` package or `ALSA` tools to be installed.

[`mic` installation instructions](https://www.npmjs.com/package/mic#installation)

on Mac it can be as simple as running `brew install sox`

```javascript
const mic = require('mic')

const sampleRateHertz = 16000

const micInstance = mic({
  rate: sampleRateHertz,
  channels: '1',
  debug: false,
  exitOnSilence: 6,
})
```

### Initialize SDK

```javascript
;(async () => {
  try {
    await sdk.init({
      appId: process.env.APP_ID,
      appSecret: process.env.APP_SECRET,
      basePath: 'https://api.symbl.ai',
    })
  } catch (e) {}
})()
```

### Add tracker to request body

Trackers each contain a `name` field and a `vocabulary` field which is an array of strings to be tracked.

```javascript
sdk.startRealtimeRequest({
    id: realtimeSessionId,
    insightTypes: ['action_item'],
    trackers: [
        {
            name: 'Denial',
            vocabulary: [
                'No',
                'never agreed to',
                'not interested',
            ],
        },
    ],
    config: {
        ...
    }
});
```

We will also need a unique id to associate to our symbl request. We will create
this Id using `uuid` package

`const id = uuid();`

Now we can start the connection using `sdk.startRealtimeRequest`. We need to
provide several important options to our realtime request.

- `insightTypes` - we need to provide which insights will be detected. Supported
  ones are `action_item` and `question`.
- `trackers` - Array of tracker objects which has two fields
  - `name` - Tracker name.
  - `vocabulary` - Array of strings to be tracked and detected in the conversation. Each time a phrase in the trackers `vocabulary` array is detected a `tracker_response` will be output in the console.
- `config` - object with meeting title, confidence threshold and the sampleRate.
- `speaker` - object to define who is the speaker. To distinguish between
  different speakers we also need to provide `userId` with valid email, so after
  meeting will end, we will receive summary email.
- `handlers` - these handlers are used to detect speech, messages and insights.
  - `onSpeechDetected` - This will return live transcription of the call
  - `onMessageResponse` - When processed messages are available, this callback
    will be called
  - `onInsightResponse` - When Symbl detects an insight, this callback will be
    called.
  - `onTrackerResponse` - When Symbl detects a tracker, this callback will be called and the detected tracker will be logged.

So our complete code will look like this:

```javascript
const connection = await sdk.startRealtimeRequest({
  id,
  insightTypes: ['action_item', 'question'],
  trackers: [
      {
          name: 'Denial',
          vocabulary: [
              'No',
              'never agreed to',
              'not interested',
          ],
      },
  ],
  config: {
    meetingTitle: 'My Test Meeting',
    confidenceThreshold: 0.7,
    timezoneOffset: 480, // Offset in minutes from UTC
    languageCode: 'en-US',
    sampleRateHertz,
  },
  speaker: {
    // Optional, if not specified, will simply not send an email in the end.
    userId<EMAIL_ADDRESS>// Update with valid email
    name: 'My name',
  },
  handlers: {
    onSpeechDetected: (data) => {
      console.log(JSON.stringify(data))
      // For live transcription
      if (data) {
        const {punctuated} = data
        console.log('Live: ', punctuated && punctuated.transcript)
      }
    },
    onMessageResponse: (data) => {
      // When a processed message is available
      console.log('onMessageResponse', JSON.stringify(data, null, 2))
    },
    onInsightResponse: (data) => {
      // When an insight is detected
      console.log('onInsightResponse', JSON.stringify(data, null, 2))
    },
  },
})
```

repository: adsddas/getting-started-samples

repo_name: adsddas/getting-started-samples


text:
# Overview
In this project we implemented a 2 dimensional particle filter in C++.
Our particle filter was given a map and some initial localization information (analogous to what a GPS would provide).
At each time step your filter will also got observation and control data.

## Running the Code
To run this project, first install the Term 2 Simulator which can be downloaded [here](https://github.com/udacity/self-driving-car-sim/releases)

This repository includes two files that can be used to set up and install uWebSocketIO for either Linux or Mac systems. For windows we could use either Docker, VMware, or even Windows 10 Bash on Ubuntu to install uWebSocketIO.

Once the install for uWebSocketIO is complete, the main program can be built and ran by doing the following from the project top directory.

1. mkdir build
2. cd build
3. cmake ..
4. make
5. ./particle_filter

## Objective
Our job was to build out the methods in `particle_filter.cpp` until the simulator output says:

```
Success! Your particle filter passed!
```

# My output:
![Success Screenshot](screenshot_success.png)


text:
---
layout: default
---

# 1997-04-15 - Introducing newbies to encryption (was: Re: anonymous credit)

## Header Data

From: Eric Nystrom<EMAIL_ADDRESS>To: Toto<EMAIL_ADDRESS>Message Hash: b13d7b2e28d9f1e0ad8098fac80074f74fc410022ea305dd8360a616271659da

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1997-04-15 02:51:30 UTC

Raw Date: Mon, 14 Apr 1997 19:51:30 -0700 (PDT)

## Raw message

```
{% raw  %}From: Eric Nystrom<EMAIL_ADDRESS>Date: Mon, 14 Apr 1997 19:51:30 -0700 (PDT)
To: Toto<EMAIL_ADDRESS>Subject: Introducing newbies to encryption (was: Re: anonymous credit)
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

>   There isn't a week that goes by without my receiving an email from
> someone who thanks me for the benefit they have gained by my introducing
> them to encryption or anonymous remailers, yet I doubt that many of them

Toto hints at some issues here that I've been wondering about for a while
now.  What are some effective strategies for securely introducing
"newbies" to the world of cryptography and anon remailers?  I'm
currently attending college, which means that my peers all use email very
regularly -- a ripe environment for use of cryptography in email, I should
think.  However, nearly everyone's email accounts are on a central Unix
machine, which brings up many issues about the (lack of) security of
private keys on multiuser machines.

My question is this -- is it better for the crypto community in the long
run to have more people using encryption, but perhaps insecurely, or
to have fewer users whose communications are more cryptographically secure?

-Eric

--
Thus the time may have come to abandon the cool, measured language of
technical reports -- all that talk of "perturbations" and "surprises" and
"unanticipated events" -- and simply blurt out: "Holy shit!  Ten thousand
years!  That's incredible!"
			-- Kai Erikson, _A_New_Species_of_Trouble_, 1994.

{% endraw %}
```

## Thread

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

+ Return to "[Eric Murray <ericm@lne.com>](/authors/eric_murray_ericm_at_lne_com_)"
+ Return to "[Eric Nystrom <enystrom@aurora.nscee.edu>](/authors/eric_nystrom_enystrom_at_aurora_nscee_edu_)"
+ Return to<EMAIL_ADDRESS>(William S. Frantz)](/authors/frantz_at_netcom_com_william_s_frantz_)"
+ Return to<EMAIL_ADDRESS>(Igor Chudov @ home)](/authors/ichudov_at_algebra_com_igor_chudov__at__home_)"
+ Return to "[Toto <toto@sk.sympatico.ca>](/authors/toto_toto_at_sk_sympatico_ca_)"

+ _Unknown thread root_
  + 1997-04-14 (Sun, 13 Apr 1997 23:19:45 -0700 (PDT)) - [Re: anonymous credit](/archive/1997/04/216df04c565cf3b8ab990eca1b32fe098d66f7eb747be84478b0df139c97f53f) - _Toto<EMAIL_ADDRESS>    + 1997-04-15 (Mon, 14 Apr 1997 19:51:30 -0700 (PDT)) - Introducing newbies to encryption (was: Re: anonymous credit) - _Eric Nystrom<EMAIL_ADDRESS>      + 1997-04-15 (Mon, 14 Apr 1997 20:55:43 -0700 (PDT)) - [Re: Introducing newbies to encryption (was: Re: anonymous credit)](/archive/1997/04/43af72dfa3e1b681d02210167cececbcec7d581b2b7816900794e6321248d092) -<EMAIL_ADDRESS>(Igor Chudov @ home)_
        + 1997-04-15 (Mon, 14 Apr 1997 23:49:37 -0700 (PDT)) - [Re: Introducing newbies to encryption (was: Re: anonymous credit)](/archive/1997/04/0907b86e8a445368f696e63a0151c2279aff885b90296354f22b9033cfd858ca) - _Eric Nystrom<EMAIL_ADDRESS>          + 1997-04-15 (Tue, 15 Apr 1997 00:21:02 -0700 (PDT)) - [Re: Introducing newbies to encryption (was: Re: anonymous credit)](/archive/1997/04/444a2a96189817600f9ad2e7daca9a8bcbba3a64ae834df82d9166e7f1b481d3) -<EMAIL_ADDRESS>(Igor Chudov @ home)_
            + 1997-04-15 (Tue, 15 Apr 1997 01:11:12 -0700 (PDT)) - [Re: Introducing newbies to encryption (was: Re: anonymous credit)](/archive/1997/04/6f05d97b07af96a5a595b0d399a6948bca4137d77c4011323cea57272fc754b2) - _Eric Nystrom<EMAIL_ADDRESS>              + 1997-04-16 (Tue, 15 Apr 1997 19:45:04 -0700 (PDT)) - [Re: Introducing newbies to encryption (was: Re: anonymous credit)](/archive/1997/04/4f413b9134bdf551c02344d70cc56b23d7f886c6d9fe881aa74c328bea59f210) -<EMAIL_ADDRESS>(Igor Chudov @ home)_
                + 1997-04-16 (Wed, 16 Apr 1997 16:35:01 -0700 (PDT)) - [Re: Introducing newbies to encryption (was: Re: anonymous credit)](/archive/1997/04/6aac3e6f67ba2ecb303217f3415d1fd143c4f6d76b238e65ad55515283c6f9f5) - _Eric Nystrom<EMAIL_ADDRESS>          + 1997-04-16 (Tue, 15 Apr 1997 19:45:14 -0700 (PDT)) - [Re: Introducing newbies to encryption (was: Re: anonymous credit)](/archive/1997/04/b5f9dd47e469dfd6aaebf9ec87ee80722d3b113883b06fc63f50c0424eab8992) -<EMAIL_ADDRESS>(William S. Frantz)_
            + 1997-04-16 (Tue, 15 Apr 1997 20:06:42 -0700 (PDT)) - [Re: Introducing newbies to encryption (was: Re: anonymous credit)](/archive/1997/04/b71758835ac12b908ef08e722ad445fe0520a013875bc0b3716d120445ec25fa) -<EMAIL_ADDRESS>(Igor Chudov @ home)_
      + 1997-04-15 (Mon, 14 Apr 1997 20:59:43 -0700 (PDT)) - [Re: Introducing newbies to encryption (was: Re: anonymous credit)](/archive/1997/04/16248e4e47799b7d009ac17344b6aa0e3061bdc8b1aa4da6af708907b33ed21a) - _Eric Murray<EMAIL_ADDRESS>      + 1997-04-15 (Mon, 14 Apr 1997 21:45:44 -0700 (PDT)) - [Re: Introducing newbies to encryption (was: Re: anonymous credit)](/archive/1997/04/49b76ceaa286f8bcc13c0d14fbf7c8d043da3e9663dcd75ec57a10c1933a67d1) - _Toto<EMAIL_ADDRESS>        + 1997-04-15 (Tue, 15 Apr 1997 00:14:03 -0700 (PDT)) - [Re: Introducing newbies to encryption (was: Re: anonymous credit)](/archive/1997/04/8350732b61b0dca484dc91d41b5fabfb2050ef56e8fbd1f4973a1190e9c7747c) - _Eric Nystrom<EMAIL_ADDRESS>


text:
# Delani Studio

[Check it out](https://xelousy.github.io/delanistudio//)
## Description.
Delani Studio is a site built to practice concepts learnt including JQuery, bootstrap and javascript.

## Author
Alex Waturi

## Screenshot.
<img ![shot](https://user-images.githubusercontent.com/86744004/127507796-7787541f-6e75-418d-9dbf-5d06d24e2027.png)
>

## Setup.
To get a local copy of the site:

`Extract` the cloned file.

`cd` to delanistudio folder.

*Launch* `index.html` file.

## Technologies used.
* HTML5
* CSS3
* Bootstrap
* Javascript
* JQuery
## BDD
| Inputs |  Description |
| :---         |          ---: |
| Name   | The users name. `eg Alex Waturi`|
| Email     | The users email. ``eg<EMAIL_ADDRESS> |
| Message    | The message from the user.   |

## License
>MIT LICENSE © 2021 Alex

repository: xelousy/delanistudio

repo_name: xelousy/delanistudio


text:
# Summer time Events
Pack 306 will meet once a month during the summer for an event. Below are the currently scheduled activities. As we get closer to each we will let everyone know if there are any changes due to weather. For more information on any topic, send emails to<EMAIL_ADDRESS>
## June

June 29th we will be hiking at [Soldiers Delight](http://dnr.maryland.gov/publiclands/pages/central/soldiersdelight.aspx). We will meet at 10:00 AM in the parking lot by the visitor center.

* [Trail Map](https://dnr.maryland.gov/publiclands/Documents/SoldiersDelight_map.pdf)

## July

July 13th join us for a hike down the Trolly Trail starting at the [Breadery](https://www.breaderyonline.com) and heading in the direction of Ellicott City.

## August

Tentatively we are on the waiting list to get into [Goddard Space Flight Center](https://www.nasa.gov/goddard) (GSFC) on the 13th for a tour. If this does not work out then the 1st Sunday we can join the model rocket launch event at the [GSFC Visitor Center](https://www.nasa.gov/centers/goddard/visitor/home/index.html).

## September

New Scout Season starts

----

Catonsville Pack 306 - 2019-05-07 - [Cub Master](mailto:cubmaster@pack306.org)

filename: Summer time Events.md

gha_language: Ruby


text:
# Legacy Mongery Platform

Used to be Segler System for e-commerce.

## Getting Started

### Clone
```bash
git clone https://github.com/mongery/legacy-platform.git
```

### License
MIT


text:
# Missiley
Udacity Fullstack Web Developer Project 8: A Country-Missile Catalog on the cloud

This project is built with Python backend with:
- Flask as the web framework to expose APIs
- Spectre.css as the CSS framework for the look and feel
- OAuth implementation using GPlus and Facebook
- CRUD operations into an Postgres Database
- SQL Alchemy as an ORM

## Public URL
[http://<IP_ADDRESS>/](http://<IP_ADDRESS>/)

## IP Address:
<IP_ADDRESS>

## SSH Port:
2200

## SSH Key location:
`/home/grader/.ssh/authorized_keys`

## Configuration:
- Base OS: Ubuntu with 512MB RAM, 1 vCPU, 20GB SSD
- Updated all package `sudo apt-get update` `sudo apt-get upgrade`
- Installed git `sudo apt-get install git-all`
- Installed Apache `sudo apt-get install apache2`
- Installed mod_wsgi `sudo apt-get install python-setuptools libapache2-mod-wsgi`
- Installed PostgreSQL `sudo apt-get install postgresql`
- Navigated to `/var/www/html`
- Cloned code repo from git hub `git clone https://github.com/akshaym91/p9-missiley.git`
- Created a new user grader `sudo adduser grader`
- Added `grader` to sudoers
- `touch /etc/sudoers.d/grader`
- `vim /etc/sudoers.d/grader` and append:
```
grader ALL=(ALL:ALL) ALL
```
- Generated keys on local machine using`ssh-keygen`
- Copied public key to the dev environment under `.ssh/authorized_keys`
- Changed permissions for .ssh
- Reloaded service `sudo service ssh restart`
- Tested logging in as `grader` by `ssh -i [privateKeyFilePath]<EMAIL_ADDRESS>- Change default ssh port at `/etc/ssh/sshd_config`
- Changed firewall settings on both Lightsail account and UFW
```
sudo ufw allow 2200/tcp
sudo ufw allow 80/tcp
sudo ufw allow 123/udp
sudo ufw enable
```
- Login as `postgres` by `sudo su - postgres` and got into `psql` shell
- Set up database
```
CREATE DATABASE missiley;
CREATE USER missiley;
ALTER ROLE missiley WITH PASSWORD '<password>';
GRANT ALL PRIVILEGES ON DATABASE missiley TO missiley;
\q
exit
```
- In the code base made appropriate changes to use Postgres instead of Sqlite
- `engine = create_engine('postgresql://missiley:password@localhost/missiley')`
- Set up the webserver to serve the files from the app by using resources found [here](http://flask.pocoo.org/docs/0.12/deploying/mod_wsgi/)
- Added the domain to the developer console in both google oauth and facebook oauth.
- Restarted webserver

## Third party resources:

1. [Flask+SQLAlchemy](http://stackoverflow.com/questions/37950713/deploying-app-using-flask-with-apache-and-sqlalchemy)
2. [IO Error](http://stackoverflow.com/questions/12201928/python-open-method-ioerror-errno-2-no-such-file-or-directory)
3. [Running wsgi application on Apache](http://flask.pocoo.org/docs/0.12/deploying/mod_wsgi/)
4. [Difference between SQLLite and Postgres](https://www.digitalocean.com/community/tutorials/sqlite-vs-mysql-vs-postgresql-a-comparison-of-relational-database-management-systems)
5. [Flask application on ubuntu](https://www.digitalocean.com/community/tutorials/how-to-deploy-a-flask-application-on-an-ubuntu-vps)

## Author
Akshay Menon

## License
MIT

## Copyright
Copyright © 2016 Akshay Menon