text:
# Advent of Code 2017

Solving programming puzzles in the Advent of Code online event that took place starting 25 days before Christmas Day in 2017.

Learn more about Advent of Code [here](http://adventofcode.com/2017/about). Problems are available [here](http://adventofcode.com/2017).

All scripts are written in Python 3.6, using only built-in functions, constants, types, and exceptions. Where applicable, the input data file is placed in the same directory as the Python script.

|Days|
|---|
|[Day 1 - Inverse Captcha](Day%201%20-%20Inverse%20Captcha)
|[Day 2 - Corruption Checksum](Day%202%20-%20Corruption%20Checksum)
|[Day 3 - Spiral Memory](Day%203%20-%20Spiral%20Memory)
|[Day 4 - High-Entropy Passphrases](Day%204%20-%20High-Entropy%20Passphrases)
|[Day 5 - A Maze of Twisty Trampolines, All Alike](Day%205%20-%20A%20Maze%20of%20Twisty%20Trampolines%20All%20Alike)
|[Day 6 - Memory Reallocation](Day%206%20-%20Memory%20Reallocation)
|[Day 7 - Recursive Circus](Day%207%20-%20Recursive%20Circus)
|[Day 8 - I Heard You Like Registers](Day%208%20-%20I%20Heard%20You%20Like%20Registers)
|[Day 9 - Stream Processing](Day%209%20-%20Stream%20Processing)
|[Day 10 - Knot Hash](Day%2010%20-%20Knot%20Hash)
|[Day 11 - Hex Ed](Day%2011%20-%20Hex%20Ed)
|[Day 12 - Digital Plumber](Day%2012%20-%20Digital%20Plumber)
|[Day 13 - Packet Scanners](Day%2013%20-%20Packet%20Scanners)
|[Day 14 - Disk Defragmentation](Day%2014%20-%20Disk%20Defragmentation)
|[Day 15 - Dueling Generators](Day%2015%20-%20Dueling%20Generators)
|[Day 16 - Permutation Promenade](Day%2016%20-%20Permutation%20Promenade)
|[Day 17 - Spinlock](Day%2017%20-%20Spinlock)
|[Day 18 - Duet](Day%2018%20-%20Duet)
|[Day 19 - A Series of Tubes](Day%2019%20-%20A%20Series%20of%20Tubes)
|[Day 20 - Particle Swarm](Day%2020%20-%20Particle%20Swarm)
|[Day 21 - Fractal Art](Day%2021%20-%20Fractal%20Art)
|[Day 22 - Sporifica Virus](Day%2022%20-%20Sporifica%20Virus)
|[Day 23 - Coprocessor Conflagration](Day%2023%20-%20Coprocessor%20Conflagration)
|[Day 24 - Electromagnetic Moat](Day%2024%20-%20Electromagnetic%20Moat)
|[Day 25 - The Halting Problem](Day%2025%20-%20The%20Halting%20Problem)


text:
^title Records

A record is similar to a [tuple](tuples.html) but where the fields are
identified by name instead of number. Another way to look at them is as
anonymous structures. The syntax is:

    :::magpie
    x: 1, y: 2
    // Creates a record with fields "x" and "y"
    // Whose values are 1 and 2, respectively.

While records look like dictionaries or maps in some languages, they have one
important difference: they are strongly-typed. The set of fields and their types
is part of the *type* of a record. A record `x: 1, y: 1` has a different static
type than `x: 1, y: 1, z: 1` or even `x: 1, y: "a string"`. (If you're familiar
with any of the ML languages, this is familiar territory.)

## Accessing Fields

Fields in a record can be accessed like any other field on an object, by name:

    :::magpie
    var point = x: 1, y: 2
    print(point x) // Prints "1".
    print(point y) // Prints "2".

Records are immutable, so fields cannot be assigned to.

license: MIT

repository: stjordanis/magpie-optionally-typed

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: stjordanis/magpie-optionally-typed


text:
# Metrics SDK

TODO: TOC

## Purpose

This document has two parts.  In the first part, the requirements of
the default OpenTelemetry Metric SDK are listed.  These are rules for
language implementors to follow in any approach to implementing the
OpenTelemetry API.

In the second part, the architectural details of a model SDK
implementation are described, using the OpenTelemetry-Go Metric SDK as
an example.  This is meant to show how the requirements can be
implemented, as guidance for implementors, not to mandate an exact
reproduction of the model architecture across languages.
OpenTelemetry SDKs are of course free to use any idiomatic approach.

## Expectations

This document assumes you are familiar with the OpenTelemetry [Metrics
API specification](api.md).

The SDK implementors are expected to follow the best practices for the
language and runtime environment when implementing the OpenTelemetry
API.  Implementors SHOULD follow the general prescriptions on safety
and performance given in [OpenTelemetry library
guidelines](../library-guidelines.md).

## SDK Terminology

The Metrics SDK provides an implementation of the Metrics API, which
has terms that it uses to refer to the SDK:

- **Meter**: An interface that supplies the OpenTelemetry Metric API, bound together with Resources and the Instrumentation Library
- **MeterProvider**: An interface for obtaining **Meter** instances given the Instrumentation Library.

These terms are useful to describe the boundary between the API and
the SDK, but they are API-level constructs.  We can use API-level
terms to describe the boundary between the SDK and the API, but from
the API's perspective the SDK is opaque and without structure.

This document specifies the internal structure of the default
OpenTelemetry SDK in terms of its major components, with terminology
chosen to explain each component's role in exporting metric data from the
input (API-level events) to the output (a metric exposition format).
We use the term **Export Pipeline** as a functional description of the
SDK at this level.

There are three major components of the export pipeline that data
flows through, in order:

1. **Accumulator**: Receives metric events from the API through Instruments, computes one Accumulation per active Instrument and Label Set pair
2. **Processor**: Receives Accumulations from the Accumulator, transforms into ExportRecordSet
3. **Exporter**: Receives ExportRecordSet, transforms into some protocol and sends it somewhere.

The **Controller** component coordinates the Accumulator, Processor,
and Exporter in an export pipeline.

These terms are defined in the Metrics API specification:

- **Metric Instrument**: the API object used by a developer for instrumentation
- **Synchronous Instrument**: a metric instrument called by the user with application context
- **Asynchronous Instrument**: a metric instrument invoked through a callback from the SDK
- **Metric Descriptor**: describes a metric instrument
- **Metric Event**: a single recorded or observed (Instrument, Label Set, Measurement)
- **Collection Interval**: the period between calls to Accumulator.Collect()
- **Label**: a key-value describing a property of the metric event
- **Label Set**: a set of key-values with unique keys
- **Measurement**: an integer or floating point number from a synchronous instrument
- **Observation**: an integer or floating point number from an asynchronous instrument.

Defined in the [Resource SDK](../resource/sdk.md) specification:

- **Resource**: a set of key-values with unique keys describing the process
- [**Instrumentation Library**](../glossary.md#instrumentation-library): the name and version associated with a package of instrumentation.

These are the significant data types used in the model architecture:

- **Aggregator**: aggregates one or more measurements in a useful way
- **Aggregator Snapshot**: copy of an synchronous instrument aggregator taken during collection
- **AggregatorSelector**: chooses which Aggregator to assign to a metric instrument
- **Accumulation**: consists of Instrument, Label Set, Resource, and Aggregator snapshot, output by Accumulator
- **Aggregation**: the result of aggregating one or more events by a specific aggregator, output by Processor
- **AggregationKind**: describes the kind of read API the Aggregation supports (e.g., Sum)
- **ExportKind**: one of Delta, Cumulative, or Pass-Through
- **ExportKindSelector**: chooses which ExportKind to use for a metric instrument.
- **ExportRecord**: consists of Instrument, Label Set, Resource, Timestamp(s), and Aggregation
- **ExportRecordSet**: a set of export records.

The term **SDK instrument** refers to the underlying implementation of
an instrument.

## Dataflow Diagram

From an external perspective, the Metrics SDK implements the `Meter`
and `MeterProvider` interfaces described in the [Metrics API](api.md).
From an internal perspective, the Metrics SDK encapsulates an export
pipeline for metric data consisting of four major components.

![Metrics SDK Design Diagram](img/metrics-sdk.png)

The Accumulator component is where metric events are concurrently
passed to an Aggregator, and it is this component that is most
responsible for SDK performance.  The Accumulator is responsible for
organizing bound and unbound instruments, updating and synchronized
copying of Aggregator state, invoking Observer instruments, and the
collection cycle.

The Processor component is intended as the most customizable component
in the export pipeline.  The Processor is responsible for selecting
Aggregators to use for specific instruments, via an independent
`AggregationSelector` interface, for reducing dimensionality, and for
conversion between DELTA and CUMULATIVE data point representation.
The Processor interface supports arbitrary protocol-independent data
transformation, and Processors can be chained together to form more
complex export pipelines.

The Exporter component converts processed data into a specific
protocol and exports it somewhere.  Following the [library
guidelines](../library-guidelines.md), exporters are expected to
contain minimal functionality and customization is preferably
expressed through Processors.

The Controller component coordinates the sequence of actions to
collect, process, and export metric data over a collection interval,
ensuring that access to the export pipeline is properly synchronized.

## Requirements

Requirements are listed below for the major components of the
OpenTelemetry SDK using the terminology outlined above.

The data flow diagram above is meant as an abstraction, for
understanding how the standard component names used in this document
map into a data path.  The diagram is not meant to prescribe an
overall architecture for the SDK, just to name the stages of an export
pipeline and place them in context.

SDKs are required to use the standard names for these components, as
this helps build consistency across OpenTelemetry.  Every SDK SHOULD
include these components and the interfaces detailed below, although
the actual organization of each SDK may differ depending on the
available libraries and performance characteristics of the source
language.  For example, an SDK could be implemented using one
Accumulator per instrument or it could be implemented using one
Accumulator per collection period (assuming support for multiple
collection periods): these are considered implementation details.

### SDK

The SDK encapsulates an OpenTelemetry Metric export pipeline,
implementing the [`Meter` interface](api.md#meter-interface), and
managing the SDK instrument, the Resource, and Instrumentation Library
metadata.

#### MeterProvider

##### Shutdown

This method provides a way for provider to do any cleanup required.

`Shutdown` MUST be called only once for each `MeterProvider` instance. After
the call to `Shutdown`, subsequent attempts to get a `Meter` are not allowed. SDKs
SHOULD return a valid no-op Meter for these calls, if possible.

`Shutdown` SHOULD provide a way to let the caller know whether it succeeded,
failed or timed out.

`Shutdown` SHOULD complete or abort within some timeout. `Shutdown` can be
implemented as a blocking API or an asynchronous API which notifies the caller
via a callback or an event. Language library authors can decide if they want to
make the shutdown timeout configurable.

#### SDK: Instrument Registration

The OpenTelemetry SDK is responsible for ensuring that an individual
Meter implementation cannot report multiple instruments with the same
name and different definitions.  To accomplish this, SDKs MUST reject
duplicate registration of an instrument when another instrument has
already been registered with same metric name to the same named Meter.
The requirement applies even for attempts to register an identical
instrument definition.  We assume that a single instrumentation
library can arrange to use a single instrument definition rather than
rely on the SDK to support duplicate registration.

Separate Meters, characterized by different instrumentation library
names, are permitted to register instruments by the same name as used
in different instrumentation libraries, in which case the SDK MUST
consider these as separate instruments.

The SDK is responsible for implementing any syntactic requirements for
metric names included in the API specification.  TODO: link to this
after [OTEP
108](https://github.com/open-telemetry/oteps/blob/master/text/metrics/0108-naming-guidelines.md)
is written into the API specification.

#### SDK: RecordBatch() function

TODO: _Add functional requirements for RecordBatch()_.

#### SDK: Collect() function

The SDK is responsible for implementing a `Collect()` function that
calls through to one or more Accumulators.  This specification
deliberately avoids requiring a specific relationship between the SDK
and Accumulator; it is considered an implementation detail whether a
the SDK maintains one Accumulator, one Accumulator per instrument, or
some configuration in between.

The SDK `Collect()` function MUST call through to the Processor with
Accumulations from the active synchronous instruments as well as all
the registered asynchronous instruments.

The SDK MUST permit synchronous metric instruments to be used during
evaluation of asynchronous instrument callbacks.  The use of
synchronous instruments from asynchronous instrument callbacks is
considered a side-effect, in this case.  SDKs SHOULD process
synchronous instruments after asynchronous instruments, so that
side-effect synchronous measurements are processed as part of the same
collection interval that contains the corresponding asynchronous
observations.

### Accumulator

The diagram below shows the relationship between the API and the
Accumulator, with detail shown for synchronous instruments.

![Metrics SDK Accumulator Detail Diagram](img/accumulator-detail.png)

For a synchronous instrument, the Accumulator will:

1. Map each active Label Set to a record, consisting of two instances of the same type Aggregator
2. Enter new records into the mapping, calling the AggregationSelector if needed
3. Update the current Aggregator instance, responding to concurrent API events
4. Call Aggregator.SynchronizedMove on the current Aggregator instance to: (a) copy its value into the snapshot Aggregator instance and (b) reset the current Aggregator to the zero state
5. Call Processor.Process for every resulting Accumulation (i.e., Instrument, Label Set, Resource, and Aggregator snapshot)

The Accumulator MUST provide the option to associate a
[`Resource`](../resource/sdk.md) with the Accumulations that it
produces.

Synchronous metric instruments are expected to be used concurrently.
Unless concurrency is not a feature of the source language, the SDK
Accumulator component SHOULD be designed with concurrent performance
in mind.

The Accumulator MAY use exclusive locking to maintain a map of
synchronous instrument updates.  The Accumulator SHOULD NOT hold an
exclusive lock while calling an Aggregator (see below), since some
Aggregators may have higher concurrency expectations.

#### Accumulator: Collect() function

The Accumulator MUST implement a Collect method that builds and
processes current Accumulation values for active instruments, meaning
those that were updated since the prior collection.  The Collect
method MUST call the Processor to process Accumulations corresponding
to all metric events that happened before the call.

Accumulations MUST be computed during Collect using a _synchronized
move_ operation on the Aggregator.  This operation, using some kind of synchronization, copies
the current Aggregator and resets it to the zero state, so that each
Aggregator immediately begins accumulating events for the next
collection period while the current one is processed.  An Accumulation
is defined as the synchronously-copied Aggregator combined with the
Label Set, Resource, and metric Descriptor.

TODO: _Are there more Accumulator functional requirements?_

### Processor

TODO _Processor functional requirements_

### Controller

TODO _Controller functional requirements_

### Aggregator

TODO _Aggregator functional requirements_

The Sum Aggregator SHOULD use atomic operations, if possible and where
there is concurrency.

## Model Implementation

The model implementation is based on the [OpenTelemetry-Go
SDK](https://github.com/open-telemetry/opentelemetry-go).  This
section is meant as guidance for implementors, SDK implementors are of
course recommended to use an idiomatic approach in their source
language.

### Accumulator: Meter Implementation

To construct a new Accumulator, provide the Processor and options.

```go
// NewAccumulator constructs a new Accumulator for the given
// Processor and options.
func NewAccumulator(processor export.Processor, opts ...Option) *Accumulator

// WithResource sets the Resource configuration option of a Config.
func WithResource(res *resource.Resource) Option
```

The Accumulator is called by the Controller (see below) to coordinate
collection using a `Collect()` method.

```go
// Collect traverses the list of active instruments and exports
// data.  Collect() may not be called concurrently.
//
// During the collection pass, the Processor will receive
// one Process(Accumulation) call per current aggregation.
//
// Returns the number of accumulations that were exported.
func (m *Accumulator) Collect(ctx context.Context) int
```

#### Implement the SDK-level API matching the user-level Metric API

This interface sits at the boundary of the SDK and the API, with three
core methods:

```go
// MeterImpl is the interface an SDK must implement to supply a Meter
// implementation.
type MeterImpl interface {
        // RecordBatch atomically records a batch of measurements.
        RecordBatch(context.Context, []label.KeyValue, ...Measurement)

        // NewSyncInstrument returns a newly constructed
        // synchronous instrument implementation or an error, should
        // one occur.
        NewSyncInstrument(descriptor Descriptor) (SyncImpl, error)

        // NewAsyncInstrument returns a newly constructed
        // asynchronous instrument implementation or an error, should
        // one occur.
        NewAsyncInstrument(
                descriptor Descriptor,
                runner AsyncRunner,
        ) (AsyncImpl, error)
}
```

These methods cover all the necessary entry points for implementing
the OpenTelemetry Metric API.

[`RecordBatch`](api.md#recordbatch-calling-convention) is a user-level API
implemented directly by the Accumulator.

The two instrument constructors build [_synchronous_
and _asynchronous_](api.md#synchronous-and-asynchronous-instruments-compared)
SDK instruments.

The user is generally interested in the [Metric API `Meter`
interface](api.md#meter-interface), obtained through a [Metric API
`MeterProvider` interface](api.md#meter-provider).  The `Meter` interface can be
constructed by wrapping the SDK `Meter` implementation:

```go
// WrapMeterImpl constructs a named `Meter` implementation from a
// `MeterImpl` implementation.  The `instrumentationName` is the
// name of the instrumentation library.
func WrapMeterImpl(impl MeterImpl, instrumentationName string, opts ...MeterOption) Meter
```

Optional to this method:

- the instrumentation library version of the named Meter in use.

To help with instrumentat registration:

```go
// NewUniqueInstrumentMeterImpl returns a wrapped metric.MeterImpl with
// the addition of uniqueness checking.
func NewUniqueInstrumentMeterImpl(impl metric.MeterImpl) metric.MeterImpl {
```

#### Provide access to the instrument descriptor

The API `Descriptor` method defines the instrument in terms of
API-level constructs including name, instrument kind, description, and
units of measure.  The SDK instrument MUST provide access to the
`Descriptor` that was passed to its constructor.

```go
// InstrumentImpl is a common interface for synchronous and
// asynchronous instruments.
type InstrumentImpl interface {
        // Descriptor returns a copy of the instrument's Descriptor.
        Descriptor() Descriptor
}
```

##### Synchronous SDK instrument

The [synchronous SDK instrument](api.md#synchronous-instrument-details)
supports both direct and bound calling conventions.

```go
// SyncImpl is the implementation-level interface to a generic
// synchronous instrument (e.g., ValueRecorder and Counter instruments).
type SyncImpl interface {
        // InstrumentImpl provides Descriptor().
        InstrumentImpl

        // Bind creates an implementation-level bound instrument,
        // binding a label set with this instrument implementation.
        Bind(labels []label.KeyValue) BoundSyncImpl

        // RecordOne captures a single synchronous metric event.
        RecordOne(ctx context.Context, number Number, labels []label.KeyValue)
}

// BoundSyncImpl is the implementation-level interface to a
// generic bound synchronous instrument
type BoundSyncImpl interface {

        // RecordOne captures a single synchronous metric event.
        RecordOne(ctx context.Context, number Number)

        // Unbind frees the resources associated with this bound instrument.
        Unbind()
}
```

##### Asynchronous SDK instrument

The [asynchronous SDK instrument](api.md#asynchronous-instrument-details)
supports both single-observer and batch-observer calling conventions.
The interface used for running Observer callbacks is passed at the
constructor, so there are no other API-level access methods for
asynchronous instruments.

```go
// AsyncImpl is an implementation-level interface to an
// asynchronous instrument (e.g., Observer instruments).
type AsyncImpl interface {
        // InstrumentImpl provides Descriptor().
        InstrumentImpl
}
```

The asynchronous "runner" interface (`AsyncRunner`) passed in the
asynchronous SDK instrument constructor supports both
[single](api.md#single-instrument-observer) and
[batch](api.md#batch-observer) calling conventions.  These are
considered language-specific details.

### Export pipeline detail

TODO: define AggregatorSelector, Aggregator, Accumulation, ExportKind,
ExportKindSelector, Aggregation, AggregationKind ExportRecord,
ExportRecordSet

### Processor Detail

TODO: define the Processor interface

#### Basic Processor

TODO: define how ExportKind conversion works (delta->cumulative
required, cumulative->delta optional), Memory option (to not forget
prior collection state).

#### Reducing Processor

TODO: Label filter, LabelFilterSelector

### Controller Detail

TODO: Push, Pull

### Aggregator Implementations

TODO: Sum, LastValue, Histogram, MinMaxSumCount, Exact, and Sketch.

### Pending issues

#### ValueRecorder instrument default aggregation

TODO: The default SDK behavior for `ValueRecorder` instruments is
still in question.  Options are: LastValue, Histogram, MinMaxSumCount,
and Sketch.

[Spec issue 636](https://github.com/open-telemetry/opentelemetry-specification/issues/636)
[OTEP 117](https://github.com/open-telemetry/oteps/pull/117)
[OTEP 118](https://github.com/open-telemetry/oteps/pull/118)

#### Standard sketch histogram aggregation

TODO: T.B.D.: DDSketch considered a good choice for ValueRecorder
instrument default aggregation.

repository: open-telemetry/docs-cn

branch_name: refs/heads/main

repo_name: open-telemetry/docs-cn


text:
---
layout: post
title: Spring onion pancake
hawker: Yong he eating house
categories:
- geylang
- kopitiam
- taiwanese
image: assets/images/geylang-spring-onion-pancake-1.jpg
featured: false
hidden: false
rating: 2
author: steve
date: 2022-01-24 14:47 +0800
---
Yong He Eating House is a semi-famous 24 hour coffee shop that sell taiwanese fair, or so I was told by a friend. I was killing time in Geylang, so I popped in for a quick snack. The spring onion pancake took my attention.  Crisp flaky pastry, butter and oil, contrasted with the spring onion sweet sharpness.

Regretfully, this was nothing like what I had experienced in Australia. The pancake itself was doughy, undercooked and almost limp. There was barely a spring onion to be found inside. Perhaps this is how the taiwanese eat it? I can't imagine it to be so though. The edges of the pancake were crispy at least.

![Soya milk](/assets/images/geylang-spring-onion-pancake-2.jpg "Soya milk")

The soya milk was served in this weird plastic tumbler. I miss the days of glass. Drinks just taste better out of a glass. This particular soya milk was ok — but I've had better. The sugar levels were not too crazy, which I prefer, but ordering it cold it was poured out of the fridge and came with no ice.

Perhaps this place is famous for just being open.

**Price:** $1.80 (+ $1.70 for the soya milk)

**Coffee shop:** Yong He Eating House
**Address:** 458 Geylang Road, Lor 24A Geylang, 389417
**Hours:** 24 Hours

***

![Yong He Eating House](/assets/images/geylang-spring-onion-pancake-3.jpg "Yong he eating house")

<iframe src="https://www.google.com/maps/embed?pb=!1m18!1m12!1m3!1d3988.770259884534!2d103.88187121439375!3d1.313299399042147!2m3!1f0!2f0!3f0!3m2!1i1024!2i768!4f13.1!3m3!1m2!1s0x1004044402f97bbb%3A0xf4cfff28d465a564!2sYong%20He%20Eating%20House%20(Singapore)!5e0!3m2!1sen!2ssg!4v1643006752290!5m2!1sen!2ssg" width="600" height="350" style="border:0;" allowfullscreen="" loading="lazy"></iframe>

repository: shawes/ang-moh-in-the-east

gha_language: JavaScript

gha_license_id: MIT

repo_name: shawes/ang-moh-in-the-east


text:
# clone-org

[![NPM version](https://badge.fury.io/js/clone-org.png)](http://badge.fury.io/js/clone-org)

## Install Instructions
```Bash
npm install -g clone-org
```

## Use Instructions
```Bash
cloneorg <ORGANIZATION_NAME>
```

repository: gastonprieto/cloneorg

repo_name: gastonprieto/cloneorg


text:
# intra process ping latency test

This package records intra process communication latency and publishes its topic statistics.

## rqt_graph
![node_graph](./imgs/rosgraph.png)

## Setup
```
$ mkdir -p ~/ros2_ws/src
$ cd ~/ros2_ws
$ git clone https://github.com/hsgwa/intra_process_ping_latency_test.git src/intra_process_ping_latency_test
$ colcon build --packages-select intra_process_ping_latency_test
```

## Run
1. Run ping_test.

```
$ . ~/ros2_ws/install/local_setup.bash
$ ros2 run intra_process_ping_latency_test ping_test
  # topic statistics is published to /topic_statistics topic
```

2. Echo `/topic_statistics` topic.
```
$ ros2 topic echo /topic_statistics
```


text:
# B2SAFE GridFTP Hands On

This hands on session will make you familiar with the high performant GridFTP transfer mechanism. You will learn how to install the globus-url-copy command line utility, used to tranfer data to a GridFTP server and how to develop a script for automated ingestion of data into B2SAFE using GridFTP.

Total time for this hands on is estimated at 60 minutes.
## 1: GridFTP client setup and configuration

Goal: install and configure the globus-url-copy command

Time: 10 minutes

### 1.1: Globus client tools installation (local installation)

Install the `globus-data-management-client` from the globus package repo on your system. This will provide the Client Tools for data management, including the GridFTP client programs and globus-url-copy

Full installation instructions are available here: `http://toolkit.globus.org/toolkit/docs/6.0/admin/install/`.

#### RPM based
Download and install the package repo for your system:

```
wget http://toolkit.globus.org/ftppub/gt6/installers/repo/globus-toolkit-repo-latest.noarch.rpm && \
rpm -hUv globus-toolkit-repo-latest.noarch.rpm && \
yum install globus-data-management-client
```

#### DEB based
Download and install the package repo for your system:

```
wget http://toolkit.globus.org/ftppub/gt6/installers/repo/globus-toolkit-repo_latest_all.deb && \
dpkg -i globus-toolkit-repo_latest_all.deb && \
apt-get update && apt-get install -y globus-data-management-client
```

### 1.1.2: User certificate, proxy and host configuration

Continue with this section if you want to install the globus-client-tools on your local machine. This allows you to ingest data into the B2SAFE test environment directly from your machine.

* Obtain your user certificate and private key from the remote server and place it in `~/.globus/`:

```
mkdir ~/.globus && \
scp <user>@<IP_ADDRESS>:~/user* ~/.globus/
```
Where `user` is your groups user (irods1, irods2, ...) of the client vm.

* Install the certificate for the CA that signed the user certificate (only needed for untrusted CA's):

```
mkdir /etc/grid-security/certificates && \
scp <user>@<IP_ADDRESS>:~/ca/* /etc/grid-security/certificates/
```

* Initialize the proxy

The first time you can run the following command to get detailed information about your certificate:

```
grid-proxy-init -verify -debug
```

Normally you don't need to initialize the proxy with the `-verify` and `-debug` options. Thus the following suffices to initialize a new proxy certificate:

```
grid-proxy-init
```

Finally you have to supply the password for the user certificate and then the proxy certificate is generated. The final output will tell you when the proxy certificate will expire. By default the proxy certificate has a validity of 12 hours.

### 1.1.3 Host file configuration

In order to access the irods machine via its hostnames `irods4.alice` we have to add the following entry to the `/etc/hosts` file:

```
echo "<IP_ADDRESS> irods4.alice" >> /etc/hosts
```
Note: you might need to use `sudo` to obtain write permission.

### 1.1.4 Dataset

On the client VM a simple file structure has been prepared for this tutorial. You can use your own files, but in order to follow the tutorial it might be easier to copy these files to your local machine:

```
scp -r <user>@<IP_ADDRESS>:~/gridftp* .
```

Continue with section 1.3.

### 1.2: User certificate and proxy configuration (client vm)

Continue with this section if you do not want to or cannot install the globus-client-tools on your local machine. This allows you to ingest data into the B2SAFE test environment from the client VM. If you want to ingest local data you will have to copy (scp) it to the client VM first. Credentials of the client VM are distributed during the workshop.

* Install your user certificate and private key in `~/.globus/`:

```
mkdir ~/.globus && \
cp *.pem ~/.globus/
```

* Initialize the proxy

The first time you can run the following command to get detailed information about your certificate:

```
grid-proxy-init -verify -debug
```

Normally you don't need to initialize the proxy with the `-verify` and `-debug` options. Thus the following suffices to initialize a new proxy certificate:

```
grid-proxy-init
```

Finally you have to supply the password for the user certificate and then the proxy certificate is generated. The final output will tell you when the proxy certificate will expire. By default the proxy certificate has a validity of 12 hours.

Continue with section 1.3.

### 1.3 Useful proxy and certificate commands

#### grid-proxy-info

You can use the `grid-proxy-info` command to get information about the current proxy:

```
$ grid-proxy-info
subject  : /O=Grid/OU=GlobusTest/OU=simpleCA-irods4.alice/OU=local/CN=GridFTP-001/CN=1963993271
issuer   : /O=Grid/OU=GlobusTest/OU=simpleCA-irods4.alice/OU=local/CN=GridFTP-001
identity : /O=Grid/OU=GlobusTest/OU=simpleCA-irods4.alice/OU=local/CN=GridFTP-001
type     : RFC 3820 compliant impersonation proxy
strength : 1024 bits
path     : /tmp/x509up_u1001
timeleft : 8:22:56
```

#### grid-proxy-destroy
You can use the `grid-proxy-destroy` command to delete the current proxy certificate.

#### grid-cert-info
You can use the `grid-cert-info` command to display information about the current active user certificate (installed in `~/.globus/usercert.pem`).

#### grid-cert-diagnostics
You can use the `grid-cert-diagnostics` command to run some diagnostics on the certificate setup on your system and the trust chain.

### 1.4 Additional information

The `grid-proxy-init -verify -debug` command will show some information about your user certificate and CA that signed the user certificate.

This is the user certificate and key file you just copied from the remote machine:

```
User Cert File: /root/.globus/usercert.pem
User Key File: /root/.globus/userkey.pem
```

The CA certificate and signing policy used to sign the user certificate is loaded from this directory:

```
Trusted CA Cert Dir: /etc/grid-security/certificates
```

Your proxy certificate is placed in this file:

```
Output File: /tmp/x509up_u0
```

The identity you will be using, based on the user certificate:

```
Your identity: /O=Grid/OU=GlobusTest/OU=simpleCA-irods4.alice/OU=local/CN=GridFTP-001
```

### 1.5 Issues

#### Issue 1
```
Error: Couldn't verify the authenticity of the user's credential to generate a proxy from.
       grid_proxy_init.c:956: globus_credential: Error verifying credential: Failed to verify credential
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Error with signing policy
globus_gsi_callback_module: Error with signing policy
globus_sysconfig: Error getting signing policy file
globus_sysconfig: File does not exist: /etc/grid-security/certificates/dd5d9bb8.signing_policy is not a valid file
```

This error means the CA signing policy file for the user certificate is not in the expected location. Fetch the CA signing policy file from the remote `alice` server an place it in `/etc/grid-security/certificates`.

#### Issue 2

```
Error: Couldn't verify the authenticity of the user's credential to generate a proxy from.
       grid_proxy_init.c:956: globus_credential: Error verifying credential: Failed to verify credential
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Can't get the local trusted CA certificate: Cannot find trusted CA certificate with hash dd5d9bb8 in /etc/grid-security/certificates
```

This error means the CA certificate is not in the expected location. Fetch the CA certificate from the remote server and place it in `/etc/grid-security/certificates`.

## 2: Communicate with GridFTP server

Goal: Getting familiar with the globus-url-copy command and performing some basic GridFTP actions.

Time: 10 minutes

### 2.1: Globus-url-copy

There are many options available for the `globus-url-copy` command. This section will show the parts explaining how to use the command and some of the most relevant options for this session.

Usage of the `globus-url-copy` command:

```
# globus-url-copy -help

globus-url-copy [options] <sourceURL> <destURL>
globus-url-copy [options] -f <filename>

<sourceURL> may contain wildcard characters * ? and [ ] character ranges
in the filename only.
Any url specifying a directory must end with a forward slash '/'

If <sourceURL> is a directory, all files within that directory will
be copied.
<destURL> must be a directory if multiple files are being copied.
...
```

Some useful arguments:

```
  -help | -usage
       Print help
  -version
       Print the version of this program
  -versions
       Print the versions of all modules that this program uses
  -q | -quiet
       Suppress all output for successful operation
  -v | -verbose
       Display urls being transferred
  -vb | -verbose-perf
       During the transfer, display the number of bytes transferred
       and the transfer rate per second.  Show urls being transferred
  -dbg | -debugftp
       Debug ftp connections.  Prints control channel communication
       to stderr
```

```
  -list <url to list>
```

```
  -concurrency | -cc
      Number of concurrent ftp connections to use for multiple transfers.
```

```
  -sync
       Only transfer files where the destination does not exist or differs
       from the source.  -sync-level controls how to determine if files
       differ.
  -sync-level <number>
       Choose criteria for determining if files differ when performing a
       sync transfer.  Level 0 will only transfer if the destination does
       not exist.  Level 1 will transfer if the size of the destination
       does not match the size of the source.  Level 2 will transfer if
       the timestamp of the destination is older than the timestamp of the
       source, or the sizes do not match.  Level 3 will perform a checksum of
       the source and destination and transfer if the checksums do not match,
       or the sizes do not match.  The default sync level is 2.
```

In the following command examples `irods<x>` is the irods username of your group. `<x>` should be replaced with your group number.

### 2.1: Listing

Listing an iRODS collection in the remote server by using the `-list` argument.

Example:

```
globus-url-copy -ipv6 -list gsiftp://irods4.alice/aliceZone/home/irods<x>/
```

Note: don't forget the trailing slash (/).

Since this GridFTP server is integrated with iRODS, the url to list consists of `/<zone_name>/<collection>/<collection>/...`. Where the `collection` part is the logical path inside the iRODS zone.

If you want more output on what is happening use the `-dbg -v` arguments.

```
globus-url-copy -ipv6 -dbg -v -list gsiftp://irods4.alice/aliceZone/home/irods<x>/
```

This will output alot of information on the data sent to and received from the server.

### 2.2: Uploading and Downloading files

#### Single files

Transfer a single file to the remote iRODS server:

```
globus-url-copy -ipv6 -vb single_file.txt gsiftp://irods4.alice/aliceZone/home/irods<x>/
```

#### Directories

Tranfer a directory to the remote iRODS server:

```
globus-url-copy -ipv6 -vb dataset1/ gsiftp://irods4.alice/aliceZone/home/irods<x>/dataset1/
```

This command will fail with the following message because the destination directory doesn't exist:

```
500 500-Command failed. : iRODS DSI. Error: rcDataObjCreate failed. SYS_INTERNAL_NULL_INPUT_ERR: , status: -24000.
```

Questions:

* Improve the command in such a way that the destination directory is properly created.
* Improve the command in such a way that all subdirectories are included as well.

## 3 Data synchronization

Goal: use the `globus-url-copy` command to implement a data transfer workflow using the B2SAFE service as remote storage.

Time: 30 minutes

### 3.1 Client data transfer script

The goal is to develop a script that will synchronize a directory tree from the client to the server and when run multiple times it should take into account changed and deleted files.

* Create the data synchronization script
* Synchronize your `gridftp<xyz>` directory to `/aliceZone/home/alice/irods<x>/data/`
* Verify the data is properly updated
* Synchronize again and verify no files are transfered
* Change a file
* Synchronize again and verify the file is properly updated

### 3.2 Improved data transfer workflow

The iRODS and B2SAGE hands on session should be completed before this step.

The goal is to improve the data transfer workflow as follows:

* Configure the data transfer workflow in such a way that checksums are generated for the ingested data.
* Configure the data transfer workflow in such a way that PIDs are generated and assigned to ingested data.

#### 3.2.1 Using the icommands

You can use the `ichksum` command to generate checksums for data objects in iRODS. Alternativly you can utilize the `irule` command and invoke a rule which uses the `<todo>` microservice.

In order the mint pids you can use the `irule` command to call the B2SAFE microservices used to manage PIDs.

Usefull rules can be found in `/etc/irods/eudat3.re`.

A selection (not a complete list) of PID management rules provided via B2SAFE:

* EUDATCreatePID(*parent_pid, *path, *ror, *iCATCache, *newPID)
* EUDATPidsForColl(*collPath)
* EUDATeCHECKSUMupdate(*PID, *path)

#### 3.2.2 Using the iRODS server rule engine

A better, and more advanced, approach is to use the iRODS rule engine to compute checksums and mint PIDs automatically. This has probably not been covered in the tutorials so far, so only proceed if you are ok with some trial and error.

You can find the iRODS server rule engine configuration here: `/etc/irods/core.re`.

Some usefull hooks in this context are:

* `acPostProcForPut` - Rule for post processing the put operation.
* `acPostProcForCopy` - Rule for post processing the copy operation.
* `acPostProcForFilePathReg` - Rule for post processing the registration
* `acPostProcForCreate` - Rule for post processing of data object create.
* `acPostProcForOpen` - Rule for post processing of data object open.
* `acPostProcForPhymv` - Rule for post processing of data object phymv.
* `acPostProcForRepl` - Rule for post processing of data object repl.

Make sure to limit the changes to the irods home directory for your user:

```
ON($objPath like "/aliceZone/home/irods<x>/*") {
	# do something useful
}
```

More information on the iRODS microservices: https://docs.irods.org/master/doxygen/

#### 3.2.3 Things to think about

* Upon ingestion of data in B2SAFE checksums are now computed, how could you obtain the checksums for data you ingest with the data transfer script?
* Upon ingestion of data in B2SAFE PIDs are now assigned, how could you obtain the PIDs for data you ingest with the data transfer script?

### 3.3 Server policies

If you completed the data transfer workflow improvements by using the iRODS rule engine you can continue with this section.

The iRODS and B2STAGE hands on sessions should be completed before this step.

The goal if to configure the alice iRODS server in such a way that ingested data is replicated to the bob iRODS server as well using the B2SAFE service.

## Appendix A: Environment

Client VM:

for each iRODS user the following layout is present:

```
/home/irods<x># tree
.
├── ca
│   ├── dd5d9bb8.0
│   └── dd5d9bb8.signing_policy
├── gridftp001
│   ├── dataset1
│   │   └── single_file.txt
│   └── dataset2
│       ├── 1.txt
│       ├── 2.txt
│       └── objects
│           └── 3.txt
├── usercert.pem
└── userkey.pem

5 directories, 8 files
```

Each certificate is named `usercert.pem` with a passphrase of the form `gridftp<xyz>`, where `<xyz>` is the respective group number.

"remote" AliceZone:

```
/aliceZone/home/alice:
  C- /aliceZone/home/alice/gridftp001
  C- /aliceZone/home/alice/gridftp002
  C- /aliceZone/home/alice/gridftp003
  C- /aliceZone/home/alice/gridftp004
  C- /aliceZone/home/alice/gridftp005
  C- /aliceZone/home/alice/gridftp006
  C- /aliceZone/home/alice/gridftp007
  C- /aliceZone/home/alice/gridftp008
  C- /aliceZone/home/alice/gridftp009
  C- /aliceZone/home/alice/gridftp010
```


text:
# GCP

Refer to [Magic Castle Documentation](https://github.com/ComputeCanada/magic_castle/tree/main/docs) for a complete step-by-step guide.

TL;DR:
1. Install the [Google Cloud SDK](https://cloud.google.com/sdk/docs/downloads-interactive)
2. Login to your Google account : `gcloud auth application-default login`
3. Download the [latest release of Magic Castle for Google Cloud](https://github.com/ComputeCanada/magic_castle/releases/latest).
4. Unpack the release.
5. Adapt the [parameters](https://github.com/ComputeCanada/magic_castle/tree/main/docs#4-configuration) in `main.tf` file.
6. In a terminal, change your current directory to the directory containing `main.tf`.
7. Initiate the Terraform state : `terraform init`.
8. Verify the Terraform plan : `terraform plan`.
9. Apply the Terraform plan : `terraform apply`.

To tear down the cluster, call: `terraform destroy`.

gha_language: HCL


text:
---
title: 1.18.6
sidebar_label: 1.18.6
---

## General

### Enhancements

- Core & Internals: Improve error message for PFN mismatch [#483](https://github.com/rucio/rucio/issues/483)

### Bugs

- Dataset deletion: Undertaker crash when a DID is attach/detached many times [#1772](https://github.com/rucio/rucio/issues/1772)
- Documentation: Typo in Client API reference [#935](https://github.com/rucio/rucio/issues/935)
- Rebalancing: bb8 is failing with division by 0 [#1792](https://github.com/rucio/rucio/issues/1792)

## Clients

### Enhancements

- Clients: Possibility to download DIDs by giving metadata filter [#782](https://github.com/rucio/rucio/issues/782)

## WebUI

### Enhancements

- WebUI: fix webui authentication to work with new token generation [#1811](https://github.com/rucio/rucio/issues/1811)
- WebUI: fix dashboard link in webui [#1814](https://github.com/rucio/rucio/issues/1814)


text:
# burger logger
![MIT  ](https://img.shields.io/badge/MIT-License-orange)

## Description
This project required creating a burger logger with MySQL, Node, Express, Handlebars and a homemade ORM. I followed the MVC design pattern using Node and MySQL to query and route data in the app. Handlebars was used to generate the HTML. The project was then loaded to heroku for use with the JawsDB MySQL add-on as the database.

## Table of Contents

  * [Installation](#Installation)
  * [Usage](#Usage)
  * [Questions](#Questions)
  * [License](#License)

  ## Installation
  Copy files from github repo to desired directory
  run 'npm install' in the directory

  ## Usage
  npm start

  An sample run of the application can be seen here:
  [Sample Burger app Screenshot](burger.png)

  Use the app here: [Burger App](https://evening-fjord-41403.herokuapp.com/)

  ## Tests
  There are no currently defined test units.

  ## Questions
  GitHub profile: https://github.com/wpb911

  Contact me at<EMAIL_ADDRESS>with any additional questions.

  ## License
  MIT License


text:
# Saga Pattern with AWS Step Functions in a SAM Project

## Summary

The Saga Pattern was published in [1987 by Hector Garcia-Molina and Kennet Salem from Princeton University](https://www.cs.princeton.edu/research/techreps/TR-070-87). It's a design pattern that helps establish data consistency in distributed applications like Microservices. It coordinates transactions between multiple Microservices to ensure that the data will remain consistent depending on the success or failure of the Business Process transaction.

This repository contains source code that shows how to Orchestrate Microservices using Saga Pattern with [AWS Step Functions](https://aws.amazon.com/step-functions). AWS Step Functions is a serverless function orchestrator that makes it easy to sequence AWS Lambda functions and multiple AWS services into business-critical applications.

## Tools

  [AWS CLI](https://aws.amazon.com/cli/)

  [AWS SAM](https://aws.amazon.com/serverless/sam/)

  [NodeJs](https://nodejs.org/)

  [Jq](https://stedolan.github.io/jq/)

## Trip Booking Saga pattern

Each request has a compensating request for rollback. The Saga goes like this:

```txt
  Begin saga
    Start book hotel request
    End book hotel request
    Start book flight request
    End book flight request
    Start book car rental request
    End book car rental request
  End saga
```

### Deployment & Test

#### Unit test

Before you start deploying, you can run unit tests and code coverage locally to test each function.

1. Install all dependencies from sub-folders

    Run this command below to npm dependencies for each function.  Run Unit Test & Code Coverage

    This project uses [Jest](https://jestjs.io/) for Unit Test implementation

    ```bash
    npm run test
    ```
    After running this command, you should get a result like an image below:
    ![Image of Successful Saga](docs/unit_test_result.png)

   And to explore the Code Coverage, open the file generated at **/coverage/lcov-report/index.html** in your browser, and you should see a screen like the one bellow

    ![Image of Successful Saga](docs/code_coverage_result.png)

#### Steps to deploy

Build lambda function, and prepare them for subsequent steps in the workflow

1. Build

    ```bash
    sam build
    ```

1. Deploy guided

    ```bash
    sam deploy --guided
    ```

#### Payload to test the State Machine

1. Success Test

    ![Image of Successful Saga](docs/StateMachineSuccess.png)

    Sample JSON for Success test.

    ```json
    {
      "tripId": "5c12d94a-ee6a-40d9-889b-1d49142248b7",
      "depart": "London",
      "departAt": "2021-07-10T06:00:00.000Z",
      "arrive": "Dublin",
      "arriveAt": "2021-07-12T08:00:00.000Z",
      "hotel": "holiday inn",
      "checkIn": "2021-07-10T12:00:00.000Z",
      "checkOut": "2021-07-12T14:00:00.000Z",
      "car": "Volvo",
      "carFrom": "2021-07-10T00:00:00.000Z",
      "carTo": "2021-07-12T00:00:00.000Z"
    }
    ```

    To test this Payload, execute the follow CURL commands to send POST request to the State Machine via API Gateway.

    __Note:__ Make sure you have replaced the XXXXXX from <https://XXXXXXX.execute-api.us-west-2.amazonaws.com/Prod/>  with the unique id generated during your SAM deployment

    ```bash
    DEMO_REGION=us-west-2 \
    API_GW_URL=https://XXXXXXX.execute-api.$DEMO_REGION.amazonaws.com/Prod/ \
    SUCCESS_JSON_PAYLOAD='{"tripId":"5c12d94a-ee6a-40d9-889b-1d49142248b7","depart":"London","departAt":"2021-07-10T06:00:00.000Z","arrive":"Dublin",   "arriveAt":"2021-07-12T08:00:00.000Z","hotel":"holiday inn","checkIn":"2021-07-10T12:00:00.000Z","checkOut":"2021-07-12T14:00:00.000Z","car":"Volvo",  "carFrom":"2021-07-10T00:00:00.000Z","carTo":"2021-07-12T00:00:00.000Z"}' \
    executionArnPayload=$(curl -X POST -H 'Content-Type: application/json' $API_GW_URL  -d "$SUCCESS_JSON_PAYLOAD" | jq '.executionArn' )

    ```

    The commands above sends a **POST** with JSON payload to **$API_GW_URL**, then it queries the API output to filter a proprietary **.executionArn** and it sets this proprietary value locally to a variable **executionArnPayload**.

    Now you can check the execution status

    ```bash
    curl -X POST -H 'Content-Type: application/json' $API_GW_URL/Status -d "{ \"executionArn\": $executionArnPayload }" | jq .
    ```

    The command above sends a POST with JSON payload that contains the executionArn from local variable **$executionArnPayload** and formats the output using jq. The output should contain the Status of the State Machine Execution, in this case it should show **"SUCCESS"**

1. Failure test.

    ![Image of Failed Saga](docs/StateMachineFail.png)

    Sample JSON for Failure test.

    ```json
    {
      "tripId": "1ecb46a4-ce47-4e13-b19e-64c2d057bed1",
      "depart": "London",
      "departAt": "2021-07-10T06:00:00.000Z",
      "arrive": "Dublin",
      "arriveAt": "2021-07-12T08:00:00.000Z",
      "hotel": "holiday inn",
      "checkIn": "2021-07-10T12:00:00.000Z",
      "checkOut": "2021-07-12T14:00:00.000Z",
      "car": "Volvo",
      "carFrom": "2021-07-10T00:00:00.000Z",
      "carTo": "2021-07-12T00:00:00.000Z",
      "failBookFlight": true
    }

    ```

    To test this Payload, execute the follow CURL commands to send a POST request to the State Machine via API Gateway.

    ```bash
    FAILURE_JSON_PAYLOAD='{"tripId":"1ecb46a4-ce47-4e13-b19e-64c2d057bed1","depart":"London","departAt":"2021-07-10T06:00:00.000Z","arrive":"Dublin",    "arriveAt":"2021-07-12T08:00:00.000Z","hotel":"holiday inn","checkIn":"2021-07-10T12:00:00.000Z","checkOut":"2021-07-12T14:00:00.000Z", "car":"Volvo", "carFrom":"2021-07-10T00:00:00.000Z","carTo":"2021-07-12T00:00:00.000Z","failBookFlight":true}' \
    executionArnPayload=$(curl -X POST -H 'Content-Type: application/json' $API_GW_URL -d "$FAILURE_JSON_PAYLOAD"  | jq '.executionArn' )
    ```

    The commands above do the same thing as the step 1, the difference is this one sends a JSON payload that will fail, because it has **"failBookFlight": true**

    ```bash
    curl -X POST -H 'Content-Type: application/json' $API_GW_URL/Status -d "{ \"executionArn\": $executionArnPayload }" | jq .
    ```

[Click here --> https://us-west-2.console.aws.amazon.com/states/home?region=us-west-2#/statemachines](https://us-west-2.console.aws.amazon.com/states/home?region=us-west-2#/statemachines) to explore the State Machine execution from AWS Console, where you can find more details about your Stepfunction execution. Note: make sure you select the same region where you're working on, mine is **us-west-2**.

#### Observability

  This project implements Observability using the combination of [AWS CloudWatch](https://aws.amazon.com/cloudwatch/) and [AWS X-Ray](https://aws.amazon.com/xray/) by enabling **Tracing** to all lambda functions in [Globals Section](https://github.com/aws/serverless-application-model/blob/master/docs/globals.rst) and in the StateMachine definition from the [template.yml](template.yml). With this setting SAM will deploy the resources needed to allows X-Ray to generate an unique trace ID for each request and track its interaction with downstream calls, for more detailed instrumentations each function has implementation to instrument AWS SDK clients to wrap the aws-sdk library with the captureAWS method as the bellow code snippet, [click here to learn more about Instrumenting Node.js code in AWS Lambda](https://docs.aws.amazon.com/lambda/latest/dg/nodejs-tracing.html).

  ```js
  const AWSXRay = require("aws-xray-sdk-core");
  const AWS = AWSXRay.captureAWS(require("aws-sdk"));
  const db = new AWS.DynamoDB.DocumentClient();
  ```

  As a result of this implementation, X-Ray will collect metadata for each request and record a trace with all downstream calls, and it provide dashboard like the images bellow, where it shows all services that your request interact with, a timeline that content a precise length of all calls and a list of CloudWatch logs produced by each functions invoked by this request, this gives you a deep insight about your application in runtime and can help debug, trace, troubleshoot or monitor your workload. Here’s the link <https://us-west-2.console.aws.amazon.com/cloudwatch/home?region=us-west-2#servicelens:traces> where you can find all your requests by Trace ID, open it and scroll down you should find a list that content all your Trace IDs, click in each one to access it dashboard.

  ![Image of X-Ray Trace IDs](docs/XrayTraceIds.png)
  ![Image of Trace Map](docs/XrayTraceMap.png)
  ![Image of X-Ray Timeline](docs/XrayTimeline.png)
  ![Image of Failed Saga](docs/XrayCloudWatchLogs.png)

## Cleanup

To clean up the resources deployed by SAM project you can use AWS CloudFormation passing your SAM project name correspondent with stack-name from CloudFormation

  ```bash
    aws cloudformation delete-stack --stack-name demo-saga-pattern-stepfunctions
  ```

## Security

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

## License

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


text:
---
title       : Transformation Programmes
key         : RI-TP
area        : risk
difficulty  : medium
skills      : Business Transformation, Project Management, Planning
---

- What do you see as the major transformational goals you would need to achieve for successful GDPR readiness?
- What do you see as your top three priorities in GDPR readiness?
- How do you typically visualise a timeline or project plan for a transformation programme that can be understood by all levels of the business?
- What milestones and success measures would you impose for the roll out of GDPR?
- How would you prepare the company for the culture shift to accompany these changes? i.e. training, thought leadership etc.

repository: stuhirst/pbx-group-security

repo_name: stuhirst/pbx-group-security


text:
---
title: Populate Connections and Views
layout: docs
---

When you get a workbook with the TSC library, the response from Tableau Server does not include information about the
views or connections that make up the workbook. Similarly, when you get a data source, the response does not include
information about the connections that make up the data source. This is a result of the design of the Tableau Server
REST API, which optimizes the size of responses by only returning what you ask for explicitly.

As a result, if you want to get views and connections, you need to run the `populate_views` and `populate_connections`
functions.

* TOC
{:toc}

## Populate views for workbooks

```py
workbook = server.workbooks.get_by_id('a1b2c3d4')
print(workbook.id)

server.workbooks.populate_views(workbook)
print([view.name for view in workbook.views])
```

## Populate connections for workbooks

```py
workbook = server.workbooks.get_by_id('a1b2c3d4')
print(workbook.id)

server.workbooks.populate_connections(workbook)
print([connection.datasource_name for connection in workbook.connections])
```

## Populate connections for data sources

```py
datasource = server.datasources.get_by_id('a1b2c3d4')
print(datasource.name)

server.datasources.populate_connections(datasource)
print([connection.datasource_name for connection in datasource.connections])
```

repository: aaronjameslang/server-client-python

repo_name: aaronjameslang/server-client-python


text:
#### 0.1.2 (2021-05-28)

##### Chores

*  Slim down nodeNPM example ([67fb64ad](https://github.com/crowdedjs/crowded/commit/67fb64ad68bb1ce65edde921b8c1d029cdcd8ac0))
*  Remove dist from repo ([348e3cc5](https://github.com/crowdedjs/crowded/commit/348e3cc5ee81caa4c189d06844105ec159459213))
*  Rename umd package ([5053b6bf](https://github.com/crowdedjs/crowded/commit/5053b6bf74487db1230e163d6926a55558d54e64))
*  Remove old old.csv file ([1fe36305](https://github.com/crowdedjs/crowded/commit/1fe36305fc19bda484bab07976ff354140600b1f))

##### New Features

*  Update browser example to use new package name. ([4937e6fc](https://github.com/crowdedjs/crowded/commit/4937e6fc1d59507e317a48fcd0f4c83f84a16d16))
*  Add babel to rollup ([37c782b1](https://github.com/crowdedjs/crowded/commit/37c782b17366e60285ffcd7b089acc6e1570099d))
*  Add browser minimal ([7b048894](https://github.com/crowdedjs/crowded/commit/7b04889441e36a5dec1d9477d60a8497eff30e65))
*  Add flat obj ([7bb26605](https://github.com/crowdedjs/crowded/commit/7bb266059782c62e47dab09e5cc44736e17a5b9a))
*  Add CDN-based example ([47d07bd6](https://github.com/crowdedjs/crowded/commit/47d07bd69b748671bbe63d433dc740df2a9c1bba))
*  Change to umd ([781b58f0](https://github.com/crowdedjs/crowded/commit/781b58f0c3f16c597dba8f29e8698df56837cf77))
*  Add npmignore file ([a77d80c3](https://github.com/crowdedjs/crowded/commit/a77d80c3a7f6485832911d1bbfe5c1e1fda4b730))

##### Bug Fixes

*  Remove malformated json ([3f3a61d5](https://github.com/crowdedjs/crowded/commit/3f3a61d58f0cec7f3b2757ee2b4cbbd823f97b51))
*  Rollup the dist folder ([5faea049](https://github.com/crowdedjs/crowded/commit/5faea0493b1e21f8920780760520048fa410b8fd))
*  Revert version number ([b8faafee](https://github.com/crowdedjs/crowded/commit/b8faafeef145eb0b870eb857d3158f739d6f62c1))
*  rollup dist not src ([9c7c52c5](https://github.com/crowdedjs/crowded/commit/9c7c52c5c6534b709848aa77811f57ce6b9ca81c))
*  Convert npm example to CommonJS ([94977978](https://github.com/crowdedjs/crowded/commit/949779786ebd3041d9325a1bb9f161c5bde5c5e7))
*  Point index to umd bundle ([27bc224c](https://github.com/crowdedjs/crowded/commit/27bc224cd5ae0da3b1799fcc746ee57dee12c36e))
*  Remove prerelease name in package.json ([19449ad5](https://github.com/crowdedjs/crowded/commit/19449ad5529719c39b00ab4d0bf880edbca7f10b))
*  Try another fix for auto changelogs ([cc1b7de0](https://github.com/crowdedjs/crowded/commit/cc1b7de0eef1527efef6c46f0b0590144ccbbf65))
*  Try to remove auto changelog problem ([3b3b223f](https://github.com/crowdedjs/crowded/commit/3b3b223f0421e390e1a0a81ad8bf5c07d3affc07))
*  Update with automatic changelog ([131001e3](https://github.com/crowdedjs/crowded/commit/131001e3505d562dcfaa0521a81baf77f74e3c7f))

##### Other Changes

* bricksphd/issue3 ([f97ffce1](https://github.com/crowdedjs/crowded/commit/f97ffce1f223d7e05c52f8ebc1519d5a48505f87))
*  Fix index.js reference ([e49b3d4f](https://github.com/crowdedjs/crowded/commit/e49b3d4f7ce65b1e77371a747d6b1674c235a1a0))
*  Add methods of accessing the project. ([eefec541](https://github.com/crowdedjs/crowded/commit/eefec5413bc7e2a03ff3ad9052a27e7a8fc5d324))

##### Refactors

*  Build on npm 7 ([e024de6e](https://github.com/crowdedjs/crowded/commit/e024de6ec878b5c4ef2e1698d989ad9aa06f99e4))
*  Move for npm 7 ([9d71fbc1](https://github.com/crowdedjs/crowded/commit/9d71fbc1519c5760333eb9216668170742ccc2f6))
*  Moving to npm 7 packages ([5b81c6d9](https://github.com/crowdedjs/crowded/commit/5b81c6d998e9c0449a984006129da8a241bb4ba9))
*  Simplify example ([66637e0e](https://github.com/crowdedjs/crowded/commit/66637e0ed343b172708b276caafe9efe86f78b70))
*  Simplify browser minimal ([0827472b](https://github.com/crowdedjs/crowded/commit/0827472b96e1f8d9067c70c723883802800ddd06))
*  Simplify minimal browser ([c9dd64fd](https://github.com/crowdedjs/crowded/commit/c9dd64fd7eb32491a8ffeffc1b03a09e18e28e84))
*  Move examples into subfolders. ([23086cc5](https://github.com/crowdedjs/crowded/commit/23086cc568de54b434243eaa653494781a9e6a12))
*  Remove file operations from NodeApp ([1cdbab94](https://github.com/crowdedjs/crowded/commit/1cdbab947cc9961de7b85af7daf23c63df196dd6))
*  Remove setId ([34373de5](https://github.com/crowdedjs/crowded/commit/34373de5419ad27cc8d2d51b3c9cf842420f2a8b))
*  Remove references to active ([81db4496](https://github.com/crowdedjs/crowded/commit/81db44966f80d12197c1874a4f96257cc740f9df))
*  Remove dependency on Agent.js ([5ece7fb8](https://github.com/crowdedjs/crowded/commit/5ece7fb85d495f450d389785987e6a2e95d2bb9a))
*  Remove static references ([08df75d2](https://github.com/crowdedjs/crowded/commit/08df75d2d3dab5b3278bdb4b8319a04612e043d4))
*  Remove CrowdSimApp from nodeNPM example ([dd548a41](https://github.com/crowdedjs/crowded/commit/dd548a414843a55b5a86b0bf58137909889a23aa))

#### 0.1.1 (2020-11-11)

#### 0.1.10 (2020-11-07)

##### New Features

*  Add babel to rollup ([37c782b1](https://github.com/crowdedjs/crowded/commit/37c782b17366e60285ffcd7b089acc6e1570099d))

##### Bug Fixes

*  Remove malformated json ([3f3a61d5](https://github.com/crowdedjs/crowded/commit/3f3a61d58f0cec7f3b2757ee2b4cbbd823f97b51))
*  Rollup the dist folder ([5faea049](https://github.com/crowdedjs/crowded/commit/5faea0493b1e21f8920780760520048fa410b8fd))
*  Revert version number ([b8faafee](https://github.com/crowdedjs/crowded/commit/b8faafeef145eb0b870eb857d3158f739d6f62c1))

#### 1.0.1 (2020-11-04)

##### New Features

*  Add browser minimal (7b048894)
*  Add flat obj (7bb26605)

##### Bug Fixes

*  rollup dist not src (9c7c52c5)

##### Refactors

*  Build on npm 7 (e024de6e)
*  Move for npm 7 (9d71fbc1)
*  Moving to npm 7 packages (5b81c6d9)
*  Simplify example (66637e0e)
*  Simplify browser minimal (0827472b)
*  Simplify minimal browser (c9dd64fd)
*  Move examples into subfolders. (23086cc5)
*  Remove file operations from NodeApp (1cdbab94)
*  Remove setId (34373de5)
*  Remove references to active (81db4496)
*  Remove dependency on Agent.js (5ece7fb8)
*  Remove static references (08df75d2)
*  Remove CrowdSimApp from nodeNPM example (dd548a41)

#### 0.1.9 (2020-10-19)

##### Chores

*  Slim down nodeNPM example ([67fb64ad](https://github.com/crowdedjs/crowded/commit/67fb64ad68bb1ce65edde921b8c1d029cdcd8ac0))
*  Remove dist from repo ([348e3cc5](https://github.com/crowdedjs/crowded/commit/348e3cc5ee81caa4c189d06844105ec159459213))

##### Bug Fixes

*  Convert npm example to CommonJS ([94977978](https://github.com/crowdedjs/crowded/commit/949779786ebd3041d9325a1bb9f161c5bde5c5e7))

##### Other Changes

*  Fix index.js reference ([e49b3d4f](https://github.com/crowdedjs/crowded/commit/e49b3d4f7ce65b1e77371a747d6b1674c235a1a0))
*  Add methods of accessing the project. ([eefec541](https://github.com/crowdedjs/crowded/commit/eefec5413bc7e2a03ff3ad9052a27e7a8fc5d324))

#### 0.1.8 (2020-10-19)

##### Chores

*  Rename umd package ([5053b6bf](https://github.com/ricksteam/recastdetourjs/commit/5053b6bf74487db1230e163d6926a55558d54e64))

#### 0.1.7 (2020-10-19)

##### New Features

*  Add CDN-based example ([47d07bd6](https://github.com/ricksteam/recastdetourjs/commit/47d07bd69b748671bbe63d433dc740df2a9c1bba))

#### 0.1.6 (2020-10-17)

##### Bug Fixes

*  Point index to umd bundle ([27bc224c](https://github.com/ricksteam/recastdetourjs/commit/27bc224cd5ae0da3b1799fcc746ee57dee12c36e))

#### 0.1.5 (2020-10-17)

##### New Features

*  Change to umd ([781b58f0](https://github.com/ricksteam/recastdetourjs/commit/781b58f0c3f16c597dba8f29e8698df56837cf77))
*  Add npmignore file ([a77d80c3](https://github.com/ricksteam/recastdetourjs/commit/a77d80c3a7f6485832911d1bbfe5c1e1fda4b730))

##### Bug Fixes

*  Remove prerelease name in package.json ([19449ad5](https://github.com/ricksteam/recastdetourjs/commit/19449ad5529719c39b00ab4d0bf880edbca7f10b))

#### 0.1.5 (2020-10-17)

##### New Features

*  Change to umd ([781b58f0](https://github.com/ricksteam/recastdetourjs/commit/781b58f0c3f16c597dba8f29e8698df56837cf77))
*  Add npmignore file ([a77d80c3](https://github.com/ricksteam/recastdetourjs/commit/a77d80c3a7f6485832911d1bbfe5c1e1fda4b730))
#### 0.1.4 (2020-10-17)

##### Chores

*  Remove old old.csv file ([1fe36305](https://github.com/ricksteam/recastdetourjs/commit/1fe36305fc19bda484bab07976ff354140600b1f))

##### Bug Fixes

*  Try another fix for auto changelogs ([cc1b7de0](https://github.com/ricksteam/recastdetourjs/commit/cc1b7de0eef1527efef6c46f0b0590144ccbbf65))
*  Try to remove auto changelog problem ([3b3b223f](https://github.com/ricksteam/recastdetourjs/commit/3b3b223f0421e390e1a0a81ad8bf5c07d3affc07))
*  Update with automatic changelog ([131001e3](https://github.com/ricksteam/recastdetourjs/commit/131001e3505d562dcfaa0521a81baf77f74e3c7f))

license: Zlib,MIT

repository: suryolho/recast-detour

detected_licenses: Zlib MIT

repo_name: suryolho/recast-detour


text:
# Privacy Policy | General

### Highlight the value proposition.

Customers are more willing to agree to the privacy policy if they understand what are the benefits that the product or service will provide.

TODO: complement.

### Consider using privacy as a differentiating factor.

In today's market, creating trust with consumers is critical for business development and recurring purchases. The new consumer is much more aware and concerned about data collection and storage.

Specific business sectors have deal with data breaches and lack of trust from consumers.

TODO: complement.


text:
Discontinued/Abandoned - Do not use.
==================================================================================================================

Purplapp [![Build Status][ci img]][ci link] [![Code Climate][cc img]][cc link] [![Test Coverage][tc img]][cc link]
==================================================================================================================

[ci img]: https://img.shields.io/travis/purplapp/purplapp/master.svg?style=flat
[cc img]: https://img.shields.io/codeclimate/github/purplapp/purplapp.svg?style=flat
[tc img]: https://img.shields.io/codeclimate/coverage/github/purplapp/purplapp.svg?style=flat

[ci link]: https://travis-ci.org/purplapp/purplapp
[cc link]: https://codeclimate.com/github/purplapp/purplapp

An [App.net](https://app.net/) statistics application.

## Status

Maintenance mode. If something is broken, open an issue here or let
[@ciarand][] know.

## Features

### Account Features

- Find details on your account and your PCA Clubs.

- Find the first mentions between two users.

- Compare your followers with that of another user.

### Broadcast Features

- See the most recent 5 updates in any Broadcast channel.

### Want to suggest a feature?

Visit the issue page of this repository and open a new issue
with the feature(s) you want to have added to Purplapp!

Alternatively, fork this repo and setup a local version of
Purplapp and add a feature! Make sure you add tests, and that
they pass before you file a pull request!

## Setup

### Getting the code

```bash
# clone the repo
git clone git@github.com:purplapp/purplapp.git && cd purplapp

# Install composer. If you've got it already, skip this step
curl -sS https://getcomposer.org/installer | php

# install php dependencies
php composer.phar install

# run various setup tasks
./bin/robo clean
./bin/robo assets
./bin/robo test
```

### Configuration

You'll need to get or create a client ID and client secret. You can get this
information from [your App.net app listings](https://account.app.net/developer/apps/).

If you want to get statistics from GitHub, you'll need to get or create
a GitHub personal access token. Information on scopes required is coming soon,
but the defaults are probably good for now. You can get this information from
[your applications tab](https://github.com/settings/tokens/new). You'll also
need to change all the mentions of purplapp [in this block of
code](https://github.com/purplapp/purplapp/blob/master/start/routes.php#L274-L326)
to your own organisation/user and repository name.

**App configuration is handled via a `.env` file in the root. Copy the
`.env.example` file and fill in your details there.**

If you're developing on Purplapp, make sure that in the `.env` file it's set
to `DEBUG=1`, not `DEBUG=0`; on a production server, make sure it's set to
`DEBUG=0` to avoid potential revealing of sensitive data (client secrets, etc.)
to the end user.

If you'd like push notifications via Pushover, fill out the appropriate settings
in `.env`.

### Server

Purplapp will run on most servers. It's currently deployed to an Apache
instance, but nginx or the built-in PHP server should work just as well. The
built-in PHP server is good for testing.

## Development

Many development tasks are handled by [Robo](http://robo.li/). You can run `./bin/robo`
to find out which tasks are available, or edit the RoboFile.php directly. Here's
a brief description of the most common tasks:

### serve

- `./bin/robo serve` starts a development server running on <<IP_ADDRESS>:8083>.

### clean

- `./bin/robo clean` cleans the filesystem cache.

### assets

- `./bin/robo assets` writes all the Twig-specified assets in every template to
  its appropriate location in the public directory

  NOTE: This uses the Google Closure Compiler web API, so internet access is
  required.

### test

- `./bin/robo test` runs the full test suite.

  NOTE: Tests are written in PHPUnit. Check the `tests` folder for some examples.

### coverage

- `./bin/robo coverage` runs the full test suite and generates an HTML coverage
  report in `./out/coverage/`.

  NOTE: Generating code coverage requires xdebug be installed. It's also really
  slow, so don't be surprised when it takes > 10x more time.

### tdd

- `./bin/robo tdd` runs the full test suite whenever any of the source files change.

### tags

- `./bin/robo tags` will generate the ctags file for the project

  NOTE: This requires the phptags binary be available in your $PATH.

## Authors

### Present

The Purplapp development team currently consists of:

- [@ciarand][] - Current maintainer, responsible for most recent rewrite and
  hosting purplapp.eu.

### Past

In the past, the Purplapp development team has consisted of:

- [@charlw][], who had the initial idea, wrote the original implementation, and
  continued to make improvements after the first major refactoring.
- [@humd][], who performed the first major refactoring of the codebase.

## Contributors

The project has additionally been helped out by the following people:

- [@jvimedia][], who previously ran the purplapp.eu web server and helped with
  some aspects of development.
- [@jessicadennis][], who provided usability improvements.

## License

Purplapp is licensed under the [MIT License](http://opensource.org/licenses/MIT).

[@charlw]: https://github.com/charlw
[pca]: http://appdotnetwiki.net/w/index.php?title=Post_Count_Achievements
[@ciarand]: https://github.com/ciarand
[@humd]: https://github.com/humd
[@jvimedia]: https://github.com/jvimedia
[@jessicadennis]: https://github.com/jessicadennis

repository: purplapp/purplapp

gha_language: PHP

repo_name: purplapp/purplapp


text:
# Laravel Scenarios

This little package helps you set your Laravel application into a given state/scenario.

Let's say that you want to finally fix that pesky edge case bug and for that you need to have
your application in a very specific state. Example:
* you need to have a user with role X
* your user needs to have bought two products
* the payment for the second product needs to have status Y
* Another condition
* Extra condition
* Last condition

With this package you can create a new Scenario, write the code needed to have the application in the state above,
and run the command to set the scenario.

Voilá! Now you have a nice file descriptive file that sets your application into the right state so you can easily
develop against and reset everytime you need it.

Not only that, but it also makes it easy for other people to quickly check which scenarios are available, and use them.

## Installation

You can install the package via composer:

```bash
composer require flipjms/laravel-scenarios
```

Go to you `composer.json` and add the following:

```json
"autoload": {
    "psr-4": {
      "Database\\Scenarios\\": "database/scenarios/"
    }
},
```

## Usage

**To create a new scenario:**
```bash
php artisan make:scenario NewScenarioName
```
Be descriptive with your names. Do not be afraid of long names.

The file will be created at `./database/scenarios/`

Set an alias and a nice description for it. Then on the `execute` method add the necessary code to place your
application into the desired state. Usually you do that by running factories, seeders, etc...

The `output` method allows you to output information to the console once the scenario has been set. This is useful to
display information that you might need, like a user login, or an url that you might need to visit.
All the [Laravel Output IO commands](https://laravel.com/docs/9.x/artisan#writing-output) are available apart from the
progress bar.
You can also use [Termwind](https://github.com/nunomaduro/termwind) for a prettier output.

**To set a scenario**
```bash
php artisan scenarios:set

or

php artisan scenarios:set scenario-alias
```

More often than not, you want to clean your database. If that's the case, you can use the `--fresh` option:

```bash
php artisan scenarios:set --fresh

or

php artisan scenarios:set scenario-alias --fresh
```

## Questions

* Why not just use seeders?
  * IMHO seeders are nice to put your application into a default state not specific ones.
* Why not use commands?
  * You can definitely use commands. I've certainly done so. Nonetheless, I like to see commands as business logic, whereas scenarios is something you need while developing/debugging. This way I can keep my commands folder clean, and my scenarios neatly organized in their own folder.

## Credits

- [Filipe Santos](https://github.com/flipjms)

## License

The MIT License (MIT). Please see [License File](LICENSE.md) for more information.

repository: Flipjms/laravel-scenarios

repo_name: Flipjms/laravel-scenarios


text:
# How To Start Humpback

> Ready to work

First prepare the server, the following three machines as a build cluster example. Please install the `Docker` instance for each machine before you start.

```
SERVER01：<IP_ADDRESS>
SERVER02：<IP_ADDRESS>
SERVER03：<IP_ADDRESS>
```

> Deployment introduction

   You can see `<IP_ADDRESS>` as the Humpback platform center, the largest number of services to start:

   Docker Registry. Image private registry service.

   Humpback-Web. Humpback manage the site.

   Humpback-Center. Provides container scheduling services for cluster mode.

   At the same time the following three servers are activated `Humpback-Agent` to provide local image management function, waiting for the Humpback platform call.

```
| Server           |  Zookeeper |  Docker Registry  |  Humpback-Web  |  Humpback-Agent  |  Humpback-Center  |
|------------------|:----------:|:-----------------:|:--------------:|:----------------:|:-----------------:|
|   <IP_ADDRESS>   |     √      |         √         |        √       |        √         |         √         |
|   <IP_ADDRESS>   |     √      |         X         |        X       |        √         |         X         |
|   <IP_ADDRESS>   |     √      |         X         |        X       |        √         |         X         |
```

   Each server needs to start the `Zookeeper` node to form a cluster, but building a` Zookeeper` cluster is not a must.

   Humpback platform management mode is divided into two types:

   `Single Mode`, In this mode, `Humpback-Web` will directly access the` Humpback-Agent` API for interactive implementation of simple cluster container management, this mode is deployed more single, do not have to start `Humpback-Center` and build` Zookeeper` cluster.

   `Cluster Mode`, Humpback back-end needs to start `Humpback-Center` and` Zookeeper` cluster to support, `Humpback-Center` as a cluster dispatch center to provide container dynamic scheduling allocation function, and` Zookeeper` cluster provides node discovery function, to achieve cluster node flexibility telescopic.

> Zookeeper cluster

   [How to build a Zookeeper cluster](run-zookeeper.md)

> Docker Registry private registry

   [How to deploy Docker Registry](run-registry.md)

> Humpback Web site

   [How to deploy the Humpback site](run-humpback-web.md)

> Humpback Agent

   [How to deploy the Humpback Agent](run-humpback-agent.md)

> Humpback Center

   [How to deploy Humpback Center](run-humpback-center.md)

repository: winifredTomlinson/humpback-io

repo_name: winifredTomlinson/humpback-io


text:
# Bootstrapping an application

This project can be used to bootstrap your application and
distributed as a Debian package.  The build file is based on [Gradle Linux Packaging
Plugin](https://github.com/nebula-plugins/gradle-ospackage-plugin), which includes support for building RPM packages too.

Included is a Jenkinsfile to push to bintray. Take a look at `./bin/push.sh` to set your repository.

### Notable files & directories

`./bin/build.sh` - The build script that will create the Debian package using `./gradlew`

`./bin/push.sh` - The script used to push to your artifact repository, includes an example to push to bintray and deb-s3.

`./build/distributions/` - Contains Debian that is ready for distribution or
installation. You'll want to want upload this to your central repository such as
Artifactory

`./build.gradle` - Describes how the Debian package will be created. Applications files will be copied as stated in `./build.gradle`.

`./deb-config/` - All the files and scripts that will be packaged up as part of
the Debian process

`./deb-config/scripts` - Post/Pre install/un-install scripts to further customize your Debian installation

There are many examples in the [Nebula Plugins](https://github.com/nebula-plugins/gradle-ospackage-plugin/wiki/Usage-Example) repository demonstrating how to extend this example.

repository: justinrlee/armory-bootstrap-app

repo_name: justinrlee/armory-bootstrap-app


text:
# COOPER to stdout

[![Travis](https://img.shields.io/travis/hardwario/cp2stdout/master.svg)](https://travis-ci.org/hardwario/cp2stdout)
[![Release](https://img.shields.io/github/release/hardwario/cp2stdout.svg)](https://github.com/hardwario/cp2stdout/releases)
[![License](https://img.shields.io/github/license/hardwario/cp2stdout.svg)](https://github.com/hardwario/cp2stdout/blob/master/LICENSE)

## Installing

You can install **cp2stdout** directly from PyPI:

```sh
sudo pip3 install -U cp2stdout
```

## Usage

Update config.yml and run

```sh
cp2stdout -c config.yml
```

## License

This project is licensed under the [**MIT License**](https://opensource.org/licenses/MIT/) - see the [**LICENSE**](LICENSE) file for details.


text:
## Using the BitPay PHP client

This SDK provides a convenient abstraction of BitPay's [cryptographically-secure API](https://bitpay.com/api) and allows payment gateway developers to focus on payment flow/e-commerce integration rather than on the specific details of client-server interaction using the API.  This SDK optionally provides the flexibility for developers to have control over important details, including the handling of private keys needed for client-server communication.

It also implements BitPay's remote client authentication and authorization strategy.  No private or shared-secret information is ever transmitted over the wire.

### Dependencies

You must have a BitPay merchant account to use this SDK.  It's free to [sign-up for a BitPay merchant account](https://bitpay.com/start).

If you need a test account, please visit https://test.bitpay.com/dashboard/signup and register for a BitPay merchant test account. Please fill in all questions, so you get a fully working test account.
If you are looking for a testnet bitcoin wallet to test with, please visit https://bitpay.com/wallet and
create a new wallet.
If you need testnet bitcoin please visit a testnet faucet, e.g. https://testnet.coinfaucet.eu/en/ or http://tpfaucet.appspot.com/

For more information about testing, please see https://bitpay.com/docs/testing

### Handling your client private key

Each client paired with the BitPay server requires a ECDSA key.  This key provides the security mechanism for all client interaction with the BitPay server. The public key is used to derive the specific client identity that is displayed on your BitPay dashboard.  The public key is also used for securely signing all API requests from the client.  See the [BitPay API](https://bitpay.com/api) for more information.

The private key should be stored in the client environment such that it cannot be compromised.  If your private key is compromised you should revoke the compromised client identity from the BitPay server and re-pair your client, see the [API tokens](https://bitpay.com/api-tokens) for more information.

To generate the configuration file required to load the SDK:

The [BitPay Config Generator](https://github.com/bitpay/php-bitpay-client-v2/blob/master/examples/ConfigGenerator.php) helps to generate the private key, as well as a environment file formatted in JSON or YML which contains all configuration requirements, that should be stored in the client local file system. It is not recommended to transmit the private key over any public or unsecure networks.

The comments in this script will assist you to create the environment file which you will be able to modify it later.

Once the Config Generator has run and generated the Json/Yml correctly, read the console output and follow the instructions in order to pair your new tokens.

The environment file can be either generated by the script mentioned avobe or created manually by copying the following Json or YML structure:

JSON:
```json
{
  "BitPayConfiguration": {
    "Environment": "",
    "EnvConfig": {
      "Test": {
        "Url": "",
        "PrivateKeyPath": "",
        "PrivateKeySecret": "",
        "ApiTokens": {
          "merchant": "",
          "payroll": ""
        }
      },
      "Prod": {
        "Url": "",
        "PrivateKeyPath": "",
        "PrivateKeySecret": "",
        "ApiTokens": {
          "merchant": "",
          "payroll": ""
        }
      }
    }
  }
}
```
##
YML:
```yml
BitPayConfiguration:
  Environment: null
  EnvConfig:
    Test:
      Url: null
      PrivateKeyPath: null
      PrivateKeySecret: null
      ApiTokens:
        merchant: null
        payroll: null
    Prod:
      Url: null
      PrivateKeyPath: null
      ApiTokens:
        merchant: null
        payroll: null
```

# Installation

## Composer

### Install Composer

```bash
curl -sS https://getcomposer.org/installer | php
```

### Install via composer by hand

Add to your composer.json file by hand.

```javascript
{
    ...
    "require": {
        ...
        "btcpayserver/sdk": "~3.0"
    }
    ...
}
```

Once you have added this, just run:

```bash
php composer.phar update btcpayserver/sdk
```

### Install using composer

```bash
php composer.phar require btcpayserver/sdk:~3.0
```

### Initializing your BtcPay client

Once you have the environment file (JSON or YML previously generated) you can initialize the client on two different ways:

```php
// Provide the full path to the env file which you have previously stored securely.

$bitpay = BtcPaySDK\Client::create()->withFile([FULL_PATH_TO_THE_CONFIG_FILE]);
```

```php
// Initialize with separate variables
// and Private Key stored in file.

$bitpay = BtcPaySDK\Client::create()->withData(
    BtcPaySDK\Env.Test,
    "[FULL_PATH_TO_THE_PRIVATE_KEY]",
    new BtcPaySDK\Tokens(
        "7UeQtMcsHamehE4gDZojUQbNRbSuSdggbH17sawtobGJ", //merchant
        "5j48K7pUrX5k59DLhRVYkCupgw2CtoEt8DBFrHo2vW47" //payroll
    ),
    "YourMasterPassword" //used to decrypt your private key, if encrypted
);
```
```php
// Initialize with separate variables
// and Private Key as HEX string.

$bitpay = BtcPaySDK\Client::create()->withData(
    BtcPaySDK\Env.Test,
    "[PRIVATE_KEY_AS_HEX_STRING]",
    new BtcPaySDK\Tokens(
        "7UeQtMcsHamehE4gDZojUQbNRbSuSdggbH17sawtobGJ", //merchant
        "5j48K7pUrX5k59DLhRVYkCupgw2CtoEt8DBFrHo2vW47" //payroll
    )
);
```
##
### Create an invoice

```php
$invoice = $bitpay->createInvoice(new Invoice(50.0, "USD"));

$invoiceUrl = $invoice->getURL();

$status = $invoice->getStatus();
```

> **WARNING**:
If you get the following error when initiating the client for first time:
"500 Internal Server Error` response: {"error":"Account not setup completely yet."}"

More info [here](https://support.bitpay.com/hc/en-us/articles/203010446-How-do-I-apply-for-a-merchant-account-)

### Retrieve an invoice

```php
$invoice = $bitpay->getInvoice($invoice->getId());
```

### Get exchange Rates

You can retrieve BitPay's [BBB exchange rates](https://bitpay.com/exchange-rates).

```php
$rates = $bitpay->getRates();

$rate = $rates->getRate(Currency::USD); //Always use the included Currency model to avoid typos

$rates->update();
```

See also the test package for more examples of API calls.


text:
---
title: Instance methods
---

<!-- toc -->

To add an instance method to your element, just add a method on the element's prototype.

```
Polymer({
    is: 'cat-element',
    _says: 'meow',
    speak: function() {
      console.log(this._says);
    }
});
```

You can invoke the method on any instance of your element.

```
var cat1 = document.querySelector('cat-element');
cat1.speak();
var cat2 = document.createElement('cat-element');
cat2.speak();
```

## Built-in methods {#instance-methods}

All Polymer elements inherit from [`Polymer.Base`](/1.0/docs/api/Polymer.Base), which
provides a set of useful convenience functions for instances to use.

This section summarizes some common instance methods. For a complete list of methods, see the [`Polymer.Base`](/1.0/docs/api/Polymer.Base) API docs.

*   [`$$(selector)`](/1.0/docs/api/Polymer.Base#method-$$). Returns the first node in this element's local DOM that matches
    `selector`.

*   [`fire(type, [detail], [options])`](/1.0/docs/api/Polymer.Base#method-fire). Fires a custom event. The `options` object can contain
      the following properties:

    -   `node`. Node to fire the event on (defaults to `this`).

    -   `bubbles`. Whether the event should bubble. Defaults to `true`.

    -   `cancelable`. Whether the event can be canceled with `preventDefault`. Defaults to `false`.

### Async and debounce

*   [`async(method, [wait])`](/1.0/docs/api/Polymer.Base#method-async). Calls `method` asynchronously. If no wait time is specified,
    runs tasks with microtask timing (after the current method finishes, but before the
    next event from the event queue is processed). Returns a handle that can be used to cancel
    the task.

*   [`cancelAsync(handle)`](/1.0/docs/api/Polymer.Base#method-cancelAsync). Cancels the identified async task.

*   [`debounce(jobName, callback, [wait])`](/1.0/docs/api/Polymer.Base#method-debounce). Call `debounce` to collapse multiple
    requests for a named task into one invocation, which is made after the wait
    time has elapsed with no new request.  If no wait time is given, the callback
    is called at microtask timing (guaranteed to be before paint).

*   [`cancelDebouncer(jobName)`](/1.0/docs/api/Polymer.Base#method-cancelDebouncer). Cancels an active debouncer without calling the callback.

*   [`flushDebouncer(jobName)`](/1.0/docs/api/Polymer.Base#method-flushDebouncer). Calls the debounced callback immediately and cancels the debouncer.

*   [`isDebouncerActive(jobName)`](/1.0/docs/api/Polymer.Base#method-isDebouncerActive). Returns true if the named debounce task is waiting to run.

### Class and attribute manipulation

*   [`toggleClass(name, bool, [node])`](/1.0/docs/api/Polymer.Base#method-toggleClass). Toggles the named boolean class on the
    host element, adding the class if `bool` is truthy and removing it if
    `bool` is falsey. If `node` is specified, sets the class on `node` instead
    of the host element.

*   [`toggleAttribute(name, bool, [node])`](/1.0/docs/api/Polymer.Base#method-toggleAttribute). Like `toggleClass`, but toggles the named boolean attribute.

*   [`attributeFollows(name, newNode, oldNode)`](/1.0/docs/api/Polymer.Base#method-attributeFollows). Moves a boolean attribute from `oldNode` to
    `newNode`, unsetting the attribute (if set) on `oldNode` and setting it on `newNode`.

*   [`classFollows(name, newNode, oldNode)`](/1.0/docs/api/Polymer.Base#method-classFollows). Moves a class from `oldNode` to
    `newNode`, removing the class (if present) on `oldNode` and adding it to `newNode`

### CSS transforms

*   [`transform(transform, [node])`](/1.0/docs/api/Polymer.Base#method-transform). Applies a CSS transform to the specified node,
    or host element if no node is specified.
    `transform` is specified as a string. For example:

         this.transform('rotateX(90deg)', this.$.myDiv);

*   [`translate3d(x, y, z, [node])`](/1.0/docs/api/Polymer.Base#method-translate3d). Transforms the specified node, or host element
    if no node is specified. For example:

        this.translate3d('100px', '100px', '100px');

### Imports and URLs

*   [`importHref(href, onload, onerror, optAsync)`](/1.0/docs/api/Polymer.Base#method-importHref). Dynamically imports an HTML document.

    ```
    this.importHref('path/to/page.html', function(e) {
        // e.target.import is the import document.
    }, function(e) {
        // loading error
    });
    ```

    **Note:** To call `importHref` from outside a Polymer element, use `Polymer.Base.importHref`.
    { .alert .alert-info }

*   [`resolveUrl(url)`](/1.0/docs/api/Polymer.Base#method-resolveUrl). Takes a URL relative to the `<dom-module>` of an imported Polymer
    element, and returns a path relative to the current document. This method can be used, for example,
    to refer to an asset delivered alongside an HTML import.

repository: Polymer-Japan/docs

gha_language: HTML

repo_name: Polymer-Japan/docs