text:
---
id: getting-started
title:  Welcome to the eth2-docker official documentation portal
sidebar_label: Getting started
---

## eth2-docker v<IP_ADDRESS>

Unofficial docker environment for Ethereum 2.0 clients

## Acknowledgements

Parts of this guide are based on the Linux [guides](https://medium.com/@SomerEsat) written by [Somer Esat](https://twitter.com/SomerEsat).

Without their previous work, this project would not exist.

## High Level Overview

An Ethereum 2.0 node has many moving parts. Here's a high level, conceptual overview.

![Ethereum 2.0 Node](../static/img/Ethereum-2.0.png)

When setting up an Ethereum 2.0 node, you'll:

- Configure and run an Ethereum 1 node and sync it with the Görli testnet or main net
- Alternatively, choose an external provider of Ethereum 1 chain data
- Configure and run an Ethereum 2.0 beacon node and sync it with an Ethereum 2.0 testnet or main net
- Generate validator keys, one per 32 Eth you wish to stake. This can and often is done outside of the
  machine used to run the node, for security reasons.
- Import validator keys into the validator client, each validator key activates one validator
- Once the Ethereum 1 and Ethereum 2.0 nodes are fully synced with the chain, deposit Ethereum
  at the launchpad, 32 eth per validator key. That Ethereum is now locked up until the "merge"
  of Ethereum 2.0 with Ethereum 1.

Here's what then happens:

- The chain processes the deposit and activates the validators: Your validators start earning rewards
  and penalties.
- The beacon node is where it all happens: Block generation, attestations, slashings, with the help
  of the validator(s) inside the validator client, for signing.
- A validator earns a reward for every epoch (6.4 minutes) it is online, and a penalty of 3/4 that
  amount for every epoch it is offline. "Online" means that it sent its scheduled attestation / block
  proposal. This means you want to be online almost 24/7, but do not have to be afraid of a few hours
  of downtime, with the exception of periods of non-finality.
- Greater 2/3 of validators need to be online for the chain to "finalize". If the chain stops finalizing,
  far harsher penalties for offline validators kick in. Stay online during non-finality. The initial
  penalties on main net for this "inactivity" during non-finality have been reduced to 1/4th of their eventual
  values.
- "Slashing" is a harsh penalty and forced exit for malicious validators; regular penalties could be
  described as "Leaking" instead. The most likely mistake that gets you slashed is to run a validator key
  in two separate validator clients simultaneously. The initial slashing penalty on main net has been reduced
  to 1/4th of its eventual value.
- If all of the above was so much Gobbledegook, you need to read the [Ethereum 2.0 primer](https://ethos.dev/beacon-chain/) and come
  back to it every time you have questions.

## Supported clients

This project builds from client teams' official docker images or from official source repositories, pulled
directly from docker hub or github, respectively. In most cases, binary is the default.

Currently supported clients:
- Lighthouse
- Prysm
- Teku
- Nimbus

Currently supported optional components:
- geth, local eth1 node
- besu, local eth1 node - has not been tested extensively by this team. Feedback welcome.
- nethermind, local eth1 node - pruning in beta. Feedback welcome.
- openethereum, local eth1 node - testing mainly, DB corruption resolved.
> Use one of the local eth1 node options or a 3rd-party provider of eth1 chain data to "feed"
> your eth2 beacon node, so you can [propose](https://ethos.dev/beacon-chain/) blocks.
- slasher, Running slasher is optional, but helps secure the chain and may result in additional earnings.
- Grafana dashboard

Please see [WEB](WEB.md) for experimental Web UI support on Prysm, and use the Web instead
of validator-import to import keys.

# USAGE

## Before you start

Warnings about the dangers of running eth2 nodes are in [RECOMMENDATIONS.md](RECOMMENDATIONS.md).
In particular, you must be sure to secure your seed phrase, the mnemonic. Without it, your
staked funds *cannot* be withdrawn.

You may also want to take a look at a [guide to Linux host security](https://www.coincashew.com/coins/overview-eth/guide-or-security-best-practices-for-a-eth2-validator-beaconchain-node#setup-two-factor-authentication-for-ssh-optional).

## Steps to bring an eth2 node up

1. Install prerequisites
2. Choose a client and do initial setup.
3. Build the client
4. Generate deposit files and an eth2 wallet. This can be done within this project, or outside of it
5. Import the validator keystore files generated in the previous step
6. Run the client
7. Finalize the deposit. This is not done within this project
8. A baseline set of Grafana dashboards are included, see step 8.  Feel free to add more, or submit a PR with your favorite dashboards.
9. Configure your system to start the eth2 node on boot (optional)

## Step 1: Install prerequisites

You will need git, docker, and docker-compose. This should work on Linux, possibly MacOS.
Running a node via this project on Windows 10 is [highly discouraged](WINDOWS.md) because of time
synchronization concerns.
Please see [prerequisites](Prerequisites.md) and then come back here.

## Step 2: Choose a client, initial setup

Next, choose a client and configure this project to use it.
Please see [setup instructions](SETUP.md) and then come back here.

## Step 3: Build the client

> **Important** Before you build, verify once more that `LOCAL_UID` in `.env`
> is the UID of your user (check with `echo $UID`), and that the file `.env`
> (dot env) is called exactly that, and contains the parameters you expect.
> You will get errors about missing permissions, during Step 4, if the UID is wrong.

Build all required images. If building from source, this may take 20-30 minutes. Assuming
you cloned the project into `eth2-docker`:
```
cd ~/eth2-docker && sudo docker-compose build
```

## Step 4: Create an eth2 wallet and validator keystore and deposit files

You will deposit eth to the deposit contract, and receive locked eth2 in turn.

> **Vital** [RECOMMENDATIONS.md](RECOMMENDATIONS.md) has comments on key security. If you haven't
read these yet, please do so now. You need to know how to guard your keystore password
and your seed phrase (mnemonic). **Without the mnemonic, you will be unable to withdraw your funds
after the "merge" of Ethereum 2.0 with Ethereum 1. You need the seed phrase or your eth is gone forever.**

> You can create the keys using eth2-docker. For mainnet, you may want to create
> the keys on a machine that is not connected to the Internet, and will be wiped
> afterwards. This can be done by using an [Ubuntu Live USB](https://agstakingco.gitbook.io/eth-2-0-key-generation-ubuntu-live-usb/)
> with [eth2.0-deposit-cli](https://github.com/ethereum/eth2.0-deposit-cli), then
> copy them to the machine the node will run on, and continue from
> "You brought your own keys", below.

Make sure you're in the project directory, `cd ~/eth2-docker` by default.

This command will create the keys to deposit Eth against:

`sudo docker-compose run --rm deposit-cli`

Choose the number of validators you wish to create.
> A validator is synonymous to one 32 Ethereum stake. Multiple validators
> can be imported to a single validator client.

The created files will be in the directory `.eth2/validator_keys` in this project.
> eth2.0-deposit-cli shows you a different directory, that's because it has a view
> from inside the container.

This is also where you'd place your own keystore files if you already have some for import.

### You brought your own keys

They go into `.eth2/validator_keys` in this project directory, not directly under `$HOME`.

## Step 5: Create a validator client wallet by importing validator keys

**Warning** Import your validator key(s) to only *one* client.

> If you want to use the experimental [Prysm Web UI](WEB.md), use it to
> import keys and not this command-line process.

Import the validator key(s) to the validator client:

`sudo docker-compose run --rm validator-import`

> #### Prysm-specific
> - You will be asked whether you will be using the Web UI to import keys.
> Answer "y"es only if you are testing Prysm's experimental Web UI via
> `prysm-web.yml`
> - You will be asked to provide a "New wallet password", independent of the
>   keystore password.
> - If you choose not to store the wallet password with the validator,
>   you will need to edit `prysm-base.yml` and comment out the wallet-password-file
>   parameter

If you choose to save the password during import, it'll be available to the client every
time it starts. If you do not, you'll need to be present to start the
validator client and start it interactively. Determine your own risk profile.

> After import, the files in `.eth2/validator_keys` can be safely removed from the node,
> once you have copied them off the node. You'll need the `deposit_data` file to
> deposit at the launchpad. The `keystore-m` files can be safeguarded in case
> the node needs to be rebuilt, or deleted and recreated from mnemonic if required.
> See [recommendations](RECOMMENDATIONS.md) for some thoughts on key security.

## Step 6: Start the client

To start the client:
```
sudo docker-compose up -d eth2
```
> **Nimbus and Teku**: Beacon and validator client run in the same process, there is only one container for both

If, however, you chose not to store the wallet password with the validator client, you will need
to bring the beacon and, if in use, eth1, up individually instead, then "run"
the validator client so it can prompt you for input:

```
sudo docker-compose up -d eth1 beacon
sudo docker-compose run validator
```

After providing the wallet password, use the key sequence Ctrl-p Ctrl-q to detach
from the running container.

## Step 7: Depositing

**Caution**: You may wish to wait until the beacon node is fully synchronized before you deposit. Check
its logs with `sudo docker-compose logs -f beacon`. This safe-guards against the validator being
marked offline if your validator is activated before the beacon syncs.

Once you are ready, you can send eth to the deposit contract by using
the `.eth2/validator_keys/deposit_data-TIMESTAMP.json` file at the [Pyrmont launchpad](https://pyrmont.launchpad.ethereum.org/)
or [Mainnet launchpad](https://launchpad.ethereum.org). This file was created in Step 4.

> You can transfer files from your node to a machine with a browser using scp. A graphical
> tool such as WinSCP will work, or you can use [command line scp](https://linuxize.com/post/how-to-use-scp-command-to-securely-transfer-files/).

## Step 8: Grafana Dashboards

A baseline set of dashboards has been included.
- [Metanull's Prysm Dashboard JSON](https://raw.githubusercontent.com/metanull-operator/eth2-grafana/master/eth2-grafana-dashboard-single-source-beacon_node.json)
- [Prysm Dashboard JSON](https://raw.githubusercontent.com/GuillaumeMiralles/prysm-grafana-dashboard/master/less_10_validators.json)
- [Prysm Dashboard JSON for more than 10 validators](https://raw.githubusercontent.com/GuillaumeMiralles/prysm-grafana-dashboard/master/more_10_validators.json)
- [Lighthouse Beacon Dashboard JSON](https://raw.githubusercontent.com/sigp/lighthouse-metrics/master/dashboards/Summary.json)
- [Lighthouse Validator Client Dashboard JSON](https://raw.githubusercontent.com/sigp/lighthouse-metrics/master/dashboards/ValidatorClient.json)
- [Nimbus Dashboard JSON](https://raw.githubusercontent.com/status-im/nimbus-eth2/master/grafana/beacon_nodes_Grafana_dashboard.json)
- [Teku Dashboard](https://grafana.com/api/dashboards/12199/revisions/1/download)

Connect to http://YOURSERVERIP:3000/, log in as admin/admin, and set a new password.
> Grafana runs over http without encryption, which is not secure. Do not expose the Grafana port to the Internet. You can
> use [SSH tunneling](https://www.howtogeek.com/168145/how-to-use-ssh-tunneling/) to reach Grafana securely over the Internet.

In order to load other Dashboards, follow these instructions.

- Click on the + icon on the left, choose "Import".
- Copy/paste JSON code from the Raw github page of the Dashboard you chose - click anywhere inside the page, use Ctrl-A to select all and Ctrl-C to copy
- Click "Load"
- If prompted for a data source choose the "prometheus" data source
- Click "Import".

## Step 9: Autostart the client on boot

If you are using the "unless-stopped" restart policy, docker will start the
client for you. That said, you may wish to make sure this happens on
startup even if the client was stopped. In that case, create a service
to start the client on boot.

For Linux systems that use systemd, e.g. Ubuntu, you'd create a systemd
service.

- Copy the file: `sudo cp sample-systemd /etc/systemd/system/eth2.service`
- Edit the file: `sudo nano /etc/systemd/system/eth2.service`
- Adjust the `WorkingDirectory` to the directory you stored the project in.
- Adjust the path to `docker-compose` to be right for your system, see `which docker-compose`
- Test the service: From within the project directory, `sudo docker-compose down` to shut
  it down, then `sudo systemctl daemon-reload`, `sudo systemctl start eth2` to bring it back up,
  and check `sudo docker ps` to see all expected containers are up.
- Enable the service: `sudo systemctl enable eth2`

## Addendum: Monitor the client

Monitoring the logs of the client is useful for troubleshooting
and to judge the amount of time left before the beacon and eth1 nodes
are fully synchronized.

To see a list of running containers:

```
sudo docker ps
```

To see the logs of a container:

```
sudo docker logs -f CONTAINERNAME
```

or

```
sudo docker-compose logs -f SERVICENAME
```

## Addendum: Update the software

This project does not monitor client versions. It is up to you to decide that you
are going to update a component. When you are ready to do so, the below instructions
show you how to.

You can find the current version of your client by running `sudo docker-compose run beacon --version`.

Please see the [changelog](CHANGELOG.md) to see what changed between versions.

### The eth2-docker tool itself

Inside the project directory, run:

`git pull`

Then `cp .env .env.bak` and `cp default.env .env`, and set variables inside `.env`
the way you need them, with `.env.bak` as a guide.

### The client "stack"

If you are using binary build files - the default - you can update everything
in the client "stack" with `sudo docker-compose build --pull`. If you
run shared components in a different directory, such as eth1, traefik, or portainer,
you'd `cd` into those directories and run the command there.

### Eth1

Run:

`sudo docker-compose build --no-cache --pull eth1`

Then stop, remove and start eth1:

`sudo docker-compose stop eth1 && sudo docker-compose rm eth1`

`sudo docker-compose up -d eth1`

### Client

Beacon and validator client share the same image for most clients, we only need to rebuild one.

Run:

`sudo docker-compose build --no-cache --pull beacon`

For Prysm, also run:

`sudo docker-compose build --no-cache --pull validator`

And if using the Prysm slasher, run:

`sudo docker-compose build --no-cache --pull slasher`

Then restart the client:

`sudo docker-compose down && sudo docker-compose up -d eth2`

If you did not store the wallet password with the validator client, come up
[more manually](#start-the-client) instead.

## Addendum: Remove all traces of the client

This project uses docker volumes to store the Ethereum 1 and Ethereum 2.0 databases, as
well as validator keys for the validator client. You can see these volumes with
`sudo docker volume ls` and remove them with `sudo docker volume rm`, as long as they are
not in use.

This can be useful when moving between testnets or from a testnet to main net, without
changing the directory name the project is stored in; or when you want to start over
with a fresh database. Keep in mind that synchronizing Ethereum 1 can take days on main
net, however.

> **Caution** If you are removing the client to recreate it, please be careful
> to wait 10 minutes before importing validator key(s) and starting it again.
> The slashing protection DB will be gone, and you risk slashing your validator(s)
> otherwise.

## Addendum: Add or recover validators

You can use eth2.0-deposit-cli to either recover validator signing keys or add
additional ones, if you wish to deposit more validators against the same mnemonic.
> The same cautions apply as when creating keys in the first place. You
> may wish to take these steps on a machine that is disconnected from Internet
> and will be wiped immediately after creating the keys.

In order to recover all your validator signing keys, run `sudo docker-compose run --rm deposit-cli-add-recover`
and provide your mnemonic, then set index to "0" and the number of validators to the number you had created previously
and are now recreating.

In order to add additional validator signing keys, likewise run `sudo docker-compose run --rm deposit-cli-add-recover`
and provide your mnemonic, but this time set the index to the number of validator keys you had created previously,
for example, `4`. New validators will be created after this point. You will receive new `keystore-m` signing keys
and a new `deposit_data` JSON.

> Please triple-check your work here. You want to be sure the new validator keys are created after
> the existing ones. Launchpad will likely safeguard you against depositing twice, but don't rely
> on it. Verify that the public keys in `deposit_data` are new and you did not deposit for them
> previously.

## Addendum: Voluntary client exit

Ethereum 2.0 has a concept of "voluntary client exit", which will remove the
validator from attesting duties. Locked Eth could be withdrawn after the "merge"
of Ethereum 2.0 with Ethereum 1, and not sooner.

Currently, Prysm and Lighthouse support voluntary exit. This requires a fully synced
beacon node.

### Prysm

To exit, run `sudo docker-compose run --rm validator-voluntary-exit` and follow the
prompts.

If you wish to exit validators that were running on other clients, you can do this
as follows:

- Stop the other client(s), and wait 10 minutes. This is so you won't have
  a validator attest in the same epoch twice.
- Copy all `keystore-m` JSON files into `.eth2/validator_keys` in this project
  directory.
- Stop the Prysm client in this project, `sudo docker-compose down`
- Import the new keys via `sudo docker-compose run validator-import`. Note
  that Prysm assumes they all have the same password. If that's not the case,
  maybe work in batches.
- Verify once more that the old client is down, has been for 10 minutes, and
  can't come back up. **If both the old client and this Prysm run at the same time,
  you will slash yourself**
- Bring the Prysm client up: `sudo docker-compose up -d eth2`
- Check logs until the beacon is synced: `sudo docker-compose logs -f beacon`
- Initiate voluntary exit and follow the prompts: `sudo docker-compose run --rm validator-voluntary-exit`

### Lighthouse

The exit procedure for lighthouse is not very refined, yet.

- Copy the `keystore-m` JSON files into `.eth2/validator_keys` in this project
  directory.
- Run `sudo docker-compose run --rm validator-voluntary-exit /var/lib/lighthouse/validator_keys/<name-of-keystore-file>`,
  once for each keystore (validator) you wish to exit.
- Follow prompts.

> The directory `.eth2/validator_keys` is passed through to docker as `/var/lib/lighthouse/validator_keys`. Lighthouse
> expects you to explicitly name the `keystore-m` file for which you wish to process an exit. Because this can
> be confusing, here's an example:
```
yorick@ethlinux:~/eth2-pyrmont$ ls .eth2/validator_keys/
deposit_data-1605672506.json  keystore-m_12381_3600_0_0_0-1605672506.json
yorick@ethlinux:~/eth2-pyrmont$ sudo docker-compose run --rm validator-voluntary-exit /var/lib/lighthouse/validator_keys/keystore-m_12381_3600_0_0_0-1605672506.json
Starting eth2-pyrmont_beacon_1 ... done
Running account manager for pyrmont testnet
validator-dir path: "/var/lib/lighthouse/validators"

Enter the keystore password for validator in "/var/lib/lighthouse/validator_keys/keystore-m_12381_3600_0_0_0-1605672506.json":
```

### Nimbus

You will need to know the index of your validator as it shows on https://beaconcha.in/ or https://pyrmont.beaconcha.in/ if on Pyrmont testnet, or its public key.

Run `sudo docker-compose run --rm validator-voluntary-exit <INDEX or 0xPUBKEY>` and follow prompts to exit. For example:
- If using an index, here 0, `sudo docker-compose run --rm validator-voluntary-exit 0`
- If using a public key, you need to include "0x" in front of it, for example `sudo docker-compose run --rm validator-voluntary-exit 0xb0127e191555550fae82788061320428d2cef31b0807aa33b88f48c53682baddce6398bb737b1ba5c503ca696d0cab4a`

### Avoid penalties

Note you will need to continue running your validator until the exit
has been processed by the chain, if you wish to avoid incurring offline
penalties. You can check the status of your validator with tools such
as [beaconcha.in](https://beaconcha.in) and [beaconscan](https://beaconscan.com).

## Addendum: Moving a client

Please see the [moving checklist](MOVING.md)

## Addendum: Troubleshooting

A few useful commands if you run into issues. As always, `sudo` is a Linux-ism and may not be needed on MacOS.

`sudo docker-compose stop servicename` brings a service down, for example `docker-compose stop validator`.

`sudo docker-compose down` will stop the entire stack.

`sudo docker-compose up -d servicename` starts a single service, for example `sudo docker-compose up -d validator`.
The `-d` means "detached", not connected to your input session.

`sudo docker-compose run servicename` starts a single service and connects your input session to it. Use the Ctrl-p Ctrl-q
key sequence to detach from it again.

`sudo docker ps` lists all running services, with the container name to the right.

`sudo docker logs containername` shows logs for a container, `sudo docker logs -f containername` scrolls them.

`sudo docker-compose logs servicename` shows logs for a service, `sudo docker-compose logs -f servicename` scrolls them.

`sudo docker exec -it containername /bin/bash` will connect you to a running service in a bash shell. The eth1 service doesn't have a shell
if using geth.

You may start a service with `sudo docker-compose up -d servicename` and then find it's not in `sudo docker ps`. That means it terminated while
trying to start. To investigate, you could leave the `-d` off so you see logs on command line:

`sudo docker-compose up beacon`, for example.

You could also run `sudo docker-compose logs beacon` to see the last logs of that service and the reason it terminated.

If a service is not starting and you want to bring up its container manually, so you can investigate, first bring everything down:

`sudo docker-compose down`, tear down everything first.

`sudo docker ps`, make sure everything is down.

If you need to see the files that are being stored by services such as beacon, validator, eth1 node, grafana, &c, in Ubuntu Linux you can find
those in /var/lib/docker/volumes. `sudo bash` to invoke a shell that has access.

**HERE BE DRAGONS** You can totally run N copies of an image manually and then successfully start a validator in each and get yourself slashed.
Take extreme care.

Once your stack is down, to run an image and get into a shell, without executing the client automatically:

`sudo docker run -it --entrypoint=/bin/bash imagename`, for example `sudo docker run -it --entrypoint=/bin/bash lighthouse`.

You'd then run Linux commands manually in there, you could start components of the client manually. There is one image per client.

`sudo docker images` will show you all images.

## Addendum: Additional resources

[Youtube Channel](https://www.youtube.com/c/YorickDowne)
[Security Best Practices](https://www.coincashew.com/coins/overview-eth/guide-or-security-best-practices-for-a-eth2-validator-beaconchain-node)

# Guiding principles:

- Reduce the attack surface of the client as much as feasible.
  None of the eth2 clients lend themselves to be statically compiled and running
  in "scratch" containers, alas.
- Guide users to good key management as much as possible
- Create something that makes for a good user experience and guides people new to docker and Linux as much as feasible

# Tip Jar

If we've helped you out, in-person or by creating this project, a tip will be very welcome.

Yorick Ethereum: 0xDccf8451070a86183eE70D330C4c43b686E9CF86

LICENSE: MIT
# eth2-docker v<IP_ADDRESS>

Unofficial docker environment for Ethereum 2.0 clients

## Acknowledgements

Parts of this guide are based on the Linux [guides](https://medium.com/@SomerEsat) written by [Somer Esat](https://twitter.com/SomerEsat).

Without their previous work, this project would not exist.

## High Level Overview

An Ethereum 2.0 node has many moving parts. Here's a high level, conceptual overview.

![Ethereum 2.0 Node](Ethereum-2.0.png)

When setting up an Ethereum 2.0 node, you'll:

- Configure and run an Ethereum 1 node and sync it with the Görli testnet or main net
- Alternatively, choose an external provider of Ethereum 1 chain data
- Configure and run an Ethereum 2.0 beacon node and sync it with an Ethereum 2.0 testnet or main net
- Generate validator keys, one per 32 Eth you wish to stake. This can and often is done outside of the
  machine used to run the node, for security reasons.
- Import validator keys into the validator client, each validator key activates one validator
- Once the Ethereum 1 and Ethereum 2.0 nodes are fully synced with the chain, deposit Ethereum
  at the launchpad, 32 eth per validator key. That Ethereum is now locked up until the "merge"
  of Ethereum 2.0 with Ethereum 1.

Here's what then happens:

- The chain processes the deposit and activates the validators: Your validators start earning rewards
  and penalties.
- The beacon node is where it all happens: Block generation, attestations, slashings, with the help
  of the validator(s) inside the validator client, for signing.
- A validator earns a reward for every epoch (6.4 minutes) it is online, and a penalty of 3/4 that
  amount for every epoch it is offline. "Online" means that it sent its scheduled attestation / block
  proposal. This means you want to be online almost 24/7, but do not have to be afraid of a few hours
  of downtime, with the exception of periods of non-finality.
- Greater 2/3 of validators need to be online for the chain to "finalize". If the chain stops finalizing,
  far harsher penalties for offline validators kick in. Stay online during non-finality. The initial
  penalties on main net for this "inactivity" during non-finality have been reduced to 1/4th of their eventual
  values.
- "Slashing" is a harsh penalty and forced exit for malicious validators; regular penalties could be
  described as "Leaking" instead. The most likely mistake that gets you slashed is to run a validator key
  in two separate validator clients simultaneously. The initial slashing penalty on main net has been reduced
  to 1/4th of its eventual value.
- If all of the above was so much Gobbledegook, you need to read the [Ethereum 2.0 primer](https://ethos.dev/beacon-chain/) and come
  back to it every time you have questions.

## Supported clients

This project builds from client teams' official docker images or from official source repositories, pulled
directly from docker hub or github, respectively. In most cases, binary is the default.

Currently supported clients:
- Lighthouse
- Prysm
- Teku
- Nimbus

Currently supported optional components:
- geth, local eth1 node
- besu, local eth1 node - has not been tested extensively by this team. Feedback welcome.
- nethermind, local eth1 node - pruning in beta. Feedback welcome.
- openethereum, local eth1 node - testing mainly, DB corruption resolved.
> Use one of the local eth1 node options or a 3rd-party provider of eth1 chain data to "feed"
> your eth2 beacon node, so you can [propose](https://ethos.dev/beacon-chain/) blocks.
- slasher, Running slasher is optional, but helps secure the chain and may result in additional earnings.
- Grafana dashboard

Please see [WEB](WEB.md) for experimental Web UI support on Prysm, and use the Web instead
of validator-import to import keys.

# USAGE

## Before you start

Warnings about the dangers of running eth2 nodes are in [RECOMMENDATIONS.md](RECOMMENDATIONS.md).
In particular, you must be sure to secure your seed phrase, the mnemonic. Without it, your
staked funds *cannot* be withdrawn.

You may also want to take a look at a [guide to Linux host security](https://www.coincashew.com/coins/overview-eth/guide-or-security-best-practices-for-a-eth2-validator-beaconchain-node#setup-two-factor-authentication-for-ssh-optional).

## Steps to bring an eth2 node up

1. Install prerequisites
2. Choose a client and do initial setup.
3. Build the client
4. Generate deposit files and an eth2 wallet. This can be done within this project, or outside of it
5. Import the validator keystore files generated in the previous step
6. Run the client
7. Finalize the deposit. This is not done within this project
8. A baseline set of Grafana dashboards are included, see step 8.  Feel free to add more, or submit a PR with your favorite dashboards.
9. Configure your system to start the eth2 node on boot (optional)

## Step 1: Install prerequisites

You will need git, docker, and docker-compose. This should work on Linux, possibly MacOS.
Running a node via this project on Windows 10 is [highly discouraged](WINDOWS.md) because of time
synchronization concerns.
Please see [prerequisites](Prerequisites.md) and then come back here.

## Step 2: Choose a client, initial setup

Next, choose a client and configure this project to use it.
Please see [setup instructions](SETUP.md) and then come back here.

## Step 3: Build the client

> **Important** Before you build, verify once more that `LOCAL_UID` in `.env`
> is the UID of your user (check with `echo $UID`), and that the file `.env`
> (dot env) is called exactly that, and contains the parameters you expect.
> You will get errors about missing permissions, during Step 4, if the UID is wrong.

Build all required images. If building from source, this may take 20-30 minutes. Assuming
you cloned the project into `eth2-docker`:
```
cd ~/eth2-docker && sudo docker-compose build
```

## Step 4: Create an eth2 wallet and validator keystore and deposit files

You will deposit eth to the deposit contract, and receive locked eth2 in turn.

> **Vital** [RECOMMENDATIONS.md](RECOMMENDATIONS.md) has comments on key security. If you haven't
read these yet, please do so now. You need to know how to guard your keystore password
and your seed phrase (mnemonic). **Without the mnemonic, you will be unable to withdraw your funds
after the "merge" of Ethereum 2.0 with Ethereum 1. You need the seed phrase or your eth is gone forever.**

> You can create the keys using eth2-docker. For mainnet, you may want to create
> the keys on a machine that is not connected to the Internet, and will be wiped
> afterwards. This can be done by using an [Ubuntu Live USB](https://agstakingco.gitbook.io/eth-2-0-key-generation-ubuntu-live-usb/)
> with [eth2.0-deposit-cli](https://github.com/ethereum/eth2.0-deposit-cli), then
> copy them to the machine the node will run on, and continue from
> "You brought your own keys", below.

Make sure you're in the project directory, `cd ~/eth2-docker` by default.

This command will create the keys to deposit Eth against:

`sudo docker-compose run --rm deposit-cli`

Choose the number of validators you wish to create.
> A validator is synonymous to one 32 Ethereum stake. Multiple validators
> can be imported to a single validator client.

The created files will be in the directory `.eth2/validator_keys` in this project.
> eth2.0-deposit-cli shows you a different directory, that's because it has a view
> from inside the container.

This is also where you'd place your own keystore files if you already have some for import.

### You brought your own keys

They go into `.eth2/validator_keys` in this project directory, not directly under `$HOME`.

## Step 5: Create a validator client wallet by importing validator keys

**Warning** Import your validator key(s) to only *one* client.

> If you want to use the experimental [Prysm Web UI](WEB.md), use it to
> import keys and not this command-line process.

Import the validator key(s) to the validator client:

`sudo docker-compose run --rm validator-import`

> #### Prysm-specific
> - You will be asked whether you will be using the Web UI to import keys.
> Answer "y"es only if you are testing Prysm's experimental Web UI via
> `prysm-web.yml`
> - You will be asked to provide a "New wallet password", independent of the
>   keystore password.
> - If you choose not to store the wallet password with the validator,
>   you will need to edit `prysm-base.yml` and comment out the wallet-password-file
>   parameter

If you choose to save the password during import, it'll be available to the client every
time it starts. If you do not, you'll need to be present to start the
validator client and start it interactively. Determine your own risk profile.

> After import, the files in `.eth2/validator_keys` can be safely removed from the node,
> once you have copied them off the node. You'll need the `deposit_data` file to
> deposit at the launchpad. The `keystore-m` files can be safeguarded in case
> the node needs to be rebuilt, or deleted and recreated from mnemonic if required.
> See [recommendations](RECOMMENDATIONS.md) for some thoughts on key security.

## Step 6: Start the client

To start the client:
```
sudo docker-compose up -d eth2
```
> **Nimbus and Teku**: Beacon and validator client run in the same process, there is only one container for both

If, however, you chose not to store the wallet password with the validator client, you will need
to bring the beacon and, if in use, eth1, up individually instead, then "run"
the validator client so it can prompt you for input:

```
sudo docker-compose up -d eth1 beacon
sudo docker-compose run validator
```

After providing the wallet password, use the key sequence Ctrl-p Ctrl-q to detach
from the running container.

## Step 7: Depositing

**Caution**: You may wish to wait until the beacon node is fully synchronized before you deposit. Check
its logs with `sudo docker-compose logs -f beacon`. This safe-guards against the validator being
marked offline if your validator is activated before the beacon syncs.

Once you are ready, you can send eth to the deposit contract by using
the `.eth2/validator_keys/deposit_data-TIMESTAMP.json` file at the [Pyrmont launchpad](https://pyrmont.launchpad.ethereum.org/)
or [Mainnet launchpad](https://launchpad.ethereum.org). This file was created in Step 4.

> You can transfer files from your node to a machine with a browser using scp. A graphical
> tool such as WinSCP will work, or you can use [command line scp](https://linuxize.com/post/how-to-use-scp-command-to-securely-transfer-files/).

## Step 8: Grafana Dashboards

A baseline set of dashboards has been included.
- [Metanull's Prysm Dashboard JSON](https://raw.githubusercontent.com/metanull-operator/eth2-grafana/master/eth2-grafana-dashboard-single-source-beacon_node.json)
- [Prysm Dashboard JSON](https://raw.githubusercontent.com/GuillaumeMiralles/prysm-grafana-dashboard/master/less_10_validators.json)
- [Prysm Dashboard JSON for more than 10 validators](https://raw.githubusercontent.com/GuillaumeMiralles/prysm-grafana-dashboard/master/more_10_validators.json)
- [Lighthouse Beacon Dashboard JSON](https://raw.githubusercontent.com/sigp/lighthouse-metrics/master/dashboards/Summary.json)
- [Lighthouse Validator Client Dashboard JSON](https://raw.githubusercontent.com/sigp/lighthouse-metrics/master/dashboards/ValidatorClient.json)
- [Nimbus Dashboard JSON](https://raw.githubusercontent.com/status-im/nimbus-eth2/master/grafana/beacon_nodes_Grafana_dashboard.json)
- [Teku Dashboard](https://grafana.com/api/dashboards/12199/revisions/1/download)

Connect to http://YOURSERVERIP:3000/, log in as admin/admin, and set a new password.
> Grafana runs over http without encryption, which is not secure. Do not expose the Grafana port to the Internet. You can
> use [SSH tunneling](https://www.howtogeek.com/168145/how-to-use-ssh-tunneling/) to reach Grafana securely over the Internet.

In order to load other Dashboards, follow these instructions.

- Click on the + icon on the left, choose "Import".
- Copy/paste JSON code from the Raw github page of the Dashboard you chose - click anywhere inside the page, use Ctrl-A to select all and Ctrl-C to copy
- Click "Load"
- If prompted for a data source choose the "prometheus" data source
- Click "Import".

## Step 9: Autostart the client on boot

If you are using the "unless-stopped" restart policy, docker will start the
client for you. That said, you may wish to make sure this happens on
startup even if the client was stopped. In that case, create a service
to start the client on boot.

For Linux systems that use systemd, e.g. Ubuntu, you'd create a systemd
service.

- Copy the file: `sudo cp sample-systemd /etc/systemd/system/eth2.service`
- Edit the file: `sudo nano /etc/systemd/system/eth2.service`
- Adjust the `WorkingDirectory` to the directory you stored the project in.
- Adjust the path to `docker-compose` to be right for your system, see `which docker-compose`
- Test the service: From within the project directory, `sudo docker-compose down` to shut
  it down, then `sudo systemctl daemon-reload`, `sudo systemctl start eth2` to bring it back up,
  and check `sudo docker ps` to see all expected containers are up.
- Enable the service: `sudo systemctl enable eth2`

## Addendum: Monitor the client

Monitoring the logs of the client is useful for troubleshooting
and to judge the amount of time left before the beacon and eth1 nodes
are fully synchronized.

To see a list of running containers:

```
sudo docker ps
```

To see the logs of a container:

```
sudo docker logs -f CONTAINERNAME
```

or

```
sudo docker-compose logs -f SERVICENAME
```

## Addendum: Update the software

This project does not monitor client versions. It is up to you to decide that you
are going to update a component. When you are ready to do so, the below instructions
show you how to.

You can find the current version of your client by running `sudo docker-compose run beacon --version`.

Please see the [changelog](CHANGELOG.md) to see what changed between versions.

### The eth2-docker tool itself

Inside the project directory, run:

`git pull`

Then `cp .env .env.bak` and `cp default.env .env`, and set variables inside `.env`
the way you need them, with `.env.bak` as a guide.

### The client "stack"

If you are using binary build files - the default - you can update everything
in the client "stack" with `sudo docker-compose build --pull`. If you
run shared components in a different directory, such as eth1, traefik, or portainer,
you'd `cd` into those directories and run the command there.

### Eth1

Run:

`sudo docker-compose build --no-cache --pull eth1`

Then stop, remove and start eth1:

`sudo docker-compose stop eth1 && sudo docker-compose rm eth1`

`sudo docker-compose up -d eth1`

### Client

Beacon and validator client share the same image for most clients, we only need to rebuild one.

Run:

`sudo docker-compose build --no-cache --pull beacon`

For Prysm, also run:

`sudo docker-compose build --no-cache --pull validator`

And if using the Prysm slasher, run:

`sudo docker-compose build --no-cache --pull slasher`

Then restart the client:

`sudo docker-compose down && sudo docker-compose up -d eth2`

If you did not store the wallet password with the validator client, come up
[more manually](#start-the-client) instead.

## Addendum: Remove all traces of the client

This project uses docker volumes to store the Ethereum 1 and Ethereum 2.0 databases, as
well as validator keys for the validator client. You can see these volumes with
`sudo docker volume ls` and remove them with `sudo docker volume rm`, as long as they are
not in use.

This can be useful when moving between testnets or from a testnet to main net, without
changing the directory name the project is stored in; or when you want to start over
with a fresh database. Keep in mind that synchronizing Ethereum 1 can take days on main
net, however.

> **Caution** If you are removing the client to recreate it, please be careful
> to wait 10 minutes before importing validator key(s) and starting it again.
> The slashing protection DB will be gone, and you risk slashing your validator(s)
> otherwise.

## Addendum: Add or recover validators

You can use eth2.0-deposit-cli to either recover validator signing keys or add
additional ones, if you wish to deposit more validators against the same mnemonic.
> The same cautions apply as when creating keys in the first place. You
> may wish to take these steps on a machine that is disconnected from Internet
> and will be wiped immediately after creating the keys.

In order to recover all your validator signing keys, run `sudo docker-compose run --rm deposit-cli-add-recover`
and provide your mnemonic, then set index to "0" and the number of validators to the number you had created previously
and are now recreating.

In order to add additional validator signing keys, likewise run `sudo docker-compose run --rm deposit-cli-add-recover`
and provide your mnemonic, but this time set the index to the number of validator keys you had created previously,
for example, `4`. New validators will be created after this point. You will receive new `keystore-m` signing keys
and a new `deposit_data` JSON.

> Please triple-check your work here. You want to be sure the new validator keys are created after
> the existing ones. Launchpad will likely safeguard you against depositing twice, but don't rely
> on it. Verify that the public keys in `deposit_data` are new and you did not deposit for them
> previously.

## Addendum: Voluntary client exit

Ethereum 2.0 has a concept of "voluntary client exit", which will remove the
validator from attesting duties. Locked Eth could be withdrawn after the "merge"
of Ethereum 2.0 with Ethereum 1, and not sooner.

Currently, Prysm and Lighthouse support voluntary exit. This requires a fully synced
beacon node.

### Prysm

To exit, run `sudo docker-compose run --rm validator-voluntary-exit` and follow the
prompts.

If you wish to exit validators that were running on other clients, you can do this
as follows:

- Stop the other client(s), and wait 10 minutes. This is so you won't have
  a validator attest in the same epoch twice.
- Copy all `keystore-m` JSON files into `.eth2/validator_keys` in this project
  directory.
- Stop the Prysm client in this project, `sudo docker-compose down`
- Import the new keys via `sudo docker-compose run validator-import`. Note
  that Prysm assumes they all have the same password. If that's not the case,
  maybe work in batches.
- Verify once more that the old client is down, has been for 10 minutes, and
  can't come back up. **If both the old client and this Prysm run at the same time,
  you will slash yourself**
- Bring the Prysm client up: `sudo docker-compose up -d eth2`
- Check logs until the beacon is synced: `sudo docker-compose logs -f beacon`
- Initiate voluntary exit and follow the prompts: `sudo docker-compose run --rm validator-voluntary-exit`

### Lighthouse

The exit procedure for lighthouse is not very refined, yet.

- Copy the `keystore-m` JSON files into `.eth2/validator_keys` in this project
  directory.
- Run `sudo docker-compose run --rm validator-voluntary-exit /var/lib/lighthouse/validator_keys/<name-of-keystore-file>`,
  once for each keystore (validator) you wish to exit.
- Follow prompts.

> The directory `.eth2/validator_keys` is passed through to docker as `/var/lib/lighthouse/validator_keys`. Lighthouse
> expects you to explicitly name the `keystore-m` file for which you wish to process an exit. Because this can
> be confusing, here's an example:
```
yorick@ethlinux:~/eth2-pyrmont$ ls .eth2/validator_keys/
deposit_data-1605672506.json  keystore-m_12381_3600_0_0_0-1605672506.json
yorick@ethlinux:~/eth2-pyrmont$ sudo docker-compose run --rm validator-voluntary-exit /var/lib/lighthouse/validator_keys/keystore-m_12381_3600_0_0_0-1605672506.json
Starting eth2-pyrmont_beacon_1 ... done
Running account manager for pyrmont testnet
validator-dir path: "/var/lib/lighthouse/validators"

Enter the keystore password for validator in "/var/lib/lighthouse/validator_keys/keystore-m_12381_3600_0_0_0-1605672506.json":
```

### Nimbus

You will need to know the index of your validator as it shows on https://beaconcha.in/ or https://pyrmont.beaconcha.in/ if on Pyrmont testnet, or its public key.

Run `sudo docker-compose run --rm validator-voluntary-exit <INDEX or 0xPUBKEY>` and follow prompts to exit. For example:
- If using an index, here 0, `sudo docker-compose run --rm validator-voluntary-exit 0`
- If using a public key, you need to include "0x" in front of it, for example `sudo docker-compose run --rm validator-voluntary-exit 0xb0127e191555550fae82788061320428d2cef31b0807aa33b88f48c53682baddce6398bb737b1ba5c503ca696d0cab4a`

### Avoid penalties

Note you will need to continue running your validator until the exit
has been processed by the chain, if you wish to avoid incurring offline
penalties. You can check the status of your validator with tools such
as [beaconcha.in](https://beaconcha.in) and [beaconscan](https://beaconscan.com).

## Addendum: Moving a client

Please see the [moving checklist](MOVING.md)

## Addendum: Troubleshooting

A few useful commands if you run into issues. As always, `sudo` is a Linux-ism and may not be needed on MacOS.

`sudo docker-compose stop servicename` brings a service down, for example `docker-compose stop validator`.

`sudo docker-compose down` will stop the entire stack.

`sudo docker-compose up -d servicename` starts a single service, for example `sudo docker-compose up -d validator`.
The `-d` means "detached", not connected to your input session.

`sudo docker-compose run servicename` starts a single service and connects your input session to it. Use the Ctrl-p Ctrl-q
key sequence to detach from it again.

`sudo docker ps` lists all running services, with the container name to the right.

`sudo docker logs containername` shows logs for a container, `sudo docker logs -f containername` scrolls them.

`sudo docker-compose logs servicename` shows logs for a service, `sudo docker-compose logs -f servicename` scrolls them.

`sudo docker exec -it containername /bin/bash` will connect you to a running service in a bash shell. The eth1 service doesn't have a shell
if using geth.

You may start a service with `sudo docker-compose up -d servicename` and then find it's not in `sudo docker ps`. That means it terminated while
trying to start. To investigate, you could leave the `-d` off so you see logs on command line:

`sudo docker-compose up beacon`, for example.

You could also run `sudo docker-compose logs beacon` to see the last logs of that service and the reason it terminated.

If a service is not starting and you want to bring up its container manually, so you can investigate, first bring everything down:

`sudo docker-compose down`, tear down everything first.

`sudo docker ps`, make sure everything is down.

If you need to see the files that are being stored by services such as beacon, validator, eth1 node, grafana, &c, in Ubuntu Linux you can find
those in /var/lib/docker/volumes. `sudo bash` to invoke a shell that has access.

**HERE BE DRAGONS** You can totally run N copies of an image manually and then successfully start a validator in each and get yourself slashed.
Take extreme care.

Once your stack is down, to run an image and get into a shell, without executing the client automatically:

`sudo docker run -it --entrypoint=/bin/bash imagename`, for example `sudo docker run -it --entrypoint=/bin/bash lighthouse`.

You'd then run Linux commands manually in there, you could start components of the client manually. There is one image per client.

`sudo docker images` will show you all images.

## Addendum: Additional resources

[Youtube Channel](https://www.youtube.com/c/YorickDowne)
[Security Best Practices](https://www.coincashew.com/coins/overview-eth/guide-or-security-best-practices-for-a-eth2-validator-beaconchain-node)

# Guiding principles:

- Reduce the attack surface of the client as much as feasible.
  None of the eth2 clients lend themselves to be statically compiled and running
  in "scratch" containers, alas.
- Guide users to good key management as much as possible
- Create something that makes for a good user experience and guides people new to docker and Linux as much as feasible

# Tip Jar

If we've helped you out, in-person or by creating this project, a tip will be very welcome.

Yorick Ethereum: 0xDccf8451070a86183eE70D330C4c43b686E9CF86

LICENSE: MIT


text:
# thumbnailr

The codes uploaded so far :

1) yvue.py ( youtube video url extracter)

This video takes in input the csv file of channel ids and gives out the thumbnails
of the top videos for each YouTube Channel

The csv file is also added named channel_list_top_500.csv

2) scrap_sb : This code extracts the channel ids from the social blade site.
This code is not inculcated in the main code so that the choice of videos for
good thumbnails can be different and so we provide the downloaded dataset from
the same code.

license: MIT

repository: cirbuk/thumbnailr

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: cirbuk/thumbnailr


text:
Next.js Boilerplate

A project boilerplate with [`Next.js`](https://nextjs.org/)

[![Generic badge](https://img.shields.io/badge/License-MIT-red.svg)]()
[![Generic badge](https://img.shields.io/badge/Version-1.0.0-red.svg)]()

## Features

- Project **features**.
  - **Lorem ipsum** dolor sit amet.
  - **Lorem ipsum** dolor sit amet.
  - **Lorem ipsum** dolor sit amet.
  - **Lorem ipsum** dolor sit amet.

## Getting started

Clone this repository and install its dependencies:

```sh
$ git clone https://github.com/fmm312/nextjs-boilerplate
$ cd nextjs-boilerplate
$ yarn
```

## Build / Start App

Builds and start the App (with local server and livereload):

```sh
$ yarn dev
```

Builds for production:

```sh
$ yarn build
```

## Versioning

To keep better organization of releases we follow the [Semantic Versioning 2.0.0](http://semver.org/) guidelines.

## Contributing

Want to contribute? [Follow these recommendations](https://github.com/fmm312/reactjs-boilerplate/blob/main/CONTRIBUTING.md).

## History

See [Releases](https://github.com/fmm312/reactjs-boilerplate/blob/main/CHANGELOG.MD) for detailed changelog.

## License
[MIT License]()

branch_name: refs/heads/main


text:
# Barenboim

[![hex.pm](https://img.shields.io/hexpm/v/barenboim.svg?style=flat-square)](https://hex.pm/packages/barenboim) [![hexdocs.pm](https://img.shields.io/badge/docs-latest-green.svg?style=flat-square)](https://hexdocs.pm/barenboim/) [![Build Status](https://travis-ci.org/mendrugory/barenboim.svg?branch=master)](https://travis-ci.org/mendrugory/barenboim)

 `Barenboim` is prepared to tackle with data streaming dependencies in concurrent flows.

  If your application works with a data streaming and your incoming events could have dependencies between them, the app can have problems when:
  * The Application which is sending the data is not sending the data in the right order.
  * Your Application is treating the data concurrently therefore the order is not ensured.

## Installation
  Add `barenboim` to your list of dependencies in `mix.exs`:

  ```elixir
  def deps do
    [{:barenboim, "~> 0.3.1"}]
  end
  ```

## Configuration
  Barenboim uses [poolboy](https://github.com/devinus/poolboy) and you can configure it depending on your needs:

  ```elixir
  config :barenboim,
    pool_domain: :global,     # default :local
    pool_size: 20,            # default 10
    max_overflow: 3           # default 5
  ```

  You can also configure a delay for a reminder notification. A reminder notification is sent in order to
  avoid corner cases (notification between the data access and the registration of a dependency).
  This time (milliseconds) should be defined depending on your data access function time (see next section).

  ```elixir
  config :barenboim,
    reminder_time: 50     # default 100
  ```

## How to use it
  Define the function that will retrieve the dependency data where `dependency_ref` is the reference of your data
  and call `Barenboim.get_data`. You can also specify a time out in milliseconds.
  ```elixir
  fun = fn(dependency_ref) -> MyDataModule.get(dependency_ref) end
  {:ok, data} = Barenboim.get_data(dependency_ref, fun)
  ```

  Meanwhile, the flow that is processing a new event has to `notify` when the data is available for others.
  ```elixir
  Barenboim.notify({:reference, dependency_ref})
  ```
  Or you can even attach the data:
  ```elixir
  Barenboim.notify({:data, dependency_ref, dependency_data})
  ```
## Test
  Run the tests.
  ```bash
  mix test
  ```

## In honor of
  [Daniel Barenboim](https://en.wikipedia.org/wiki/Daniel_Barenboim)

repository: mendrugory/barenboim

repo_name: mendrugory/barenboim


text:
# Overview

---

- [Server](#server)
- [Packages](#packages)

We create this blog based on Latest technologies of Laravel and VueJs, using Laravel nova,
GraphQL, NuxtJs, Apollo and ...more

## Server
-----------
Server Requirements
The Laravel framework has a few system requirements.

- PHP >= 7.1.3
- npm >= 6.4.1
- nodejs >= 10.15.3
- OpenSSL PHP Extension
- PDO PHP Extension
- Mbstring PHP Extension
- Tokenizer PHP Extension
- XML PHP Extension
- Ctype PHP Extension
- JSON PHP Extension
- BCMath PHP Extension

> More Information [here](https://laravel.com/docs/master#installation)

## Packages
-----------------
### Backend packages
- Laravel
- Laravel Nova
- Lighthouse (Graphql Library)
- Algolia
- Laravel Cors
- Laravel Enum
- Larecipe
- Passport
- Scout
- Socialite
- Telescope
... and more

### Frontend packages
- VueJs
- Nuxt
- Apollo
- Graphql
- Font Awesome
- Moment
- Toast
- Bootstrap
- Disqus
- Awesome swiper
... and more


text:
---
layout: post
title: "Sitecore How-To: Find Unicode Characters in Content"
date:   2018-10-01 00:00:00 -0500
categories: sitecore
tags: sitecore-how-to
author: Erik Carron and Mike Skutta
excerpt: Sometimes unicode characters are accidentally added to content in Sitecore from data migration or from content editors copy-pasting content from some source. Depending on the unicode character, they can appear as random shapes on the front-end. Finding content with these unicode characters can be hard, but the following process will help you.
---

* content
{:toc}

## Overview

This is an article in a series of Sitecore how-to articles. These articles are meant to be quick guides to accomplish various tasks within Sitecore. The how-to articles have proven to be very helpful internally at *One North Interactive* https://www.onenorth.com.  These articles assume working Sitecore knowledge. I just wanted to share the articles with the community. Hopefully you find them helpful.

## How-To

Sometimes unicode characters are accidentally added to content in Sitecore from data migration or from content editors copy and pasting content from some source. Depending on the unicode character, they can appear as random shapes on the front-end. Finding content with these unicode characters can be hard, but the following process will help you.

> Content in a non-English language will use unicode characters, so if the site has multiple languages, you will get a lot of results. To search for a specific unicode character, see the comments in the WHERE clause.

## Step-by-step guide

1. Run the following SQL statement on Master or Web.


text:
Workshop | breadfruit    .recentcomments a{display:inline !important;padding:0 !important;margin:0 !important;}

[breadfruit](http://j4u2.com/breadfruit-static/ "breadfruit")
=============================================================

Can Jamaican youth benefit from …?
----------------------------------

 [![](http://j4u2.com/breadfruit-static/wp-content/uploads/2012/04/vecr-1000x288.jpeg)](http://j4u2.com/breadfruit-static/)

Search

### Main menu

[Skip to primary content](#content "Skip to primary content")

[Skip to secondary content](#secondary "Skip to secondary content")

*   [Home](http://j4u2.com/breadfruit-static/)
*   [1.mobileworks](http://j4u2.com/breadfruit-static/mobileworks/)
*   [2.Thoth](http://j4u2.com/breadfruit-static/thoth/)
*   [Digital Jam 2.0](http://j4u2.com/breadfruit-static/digi-jam/)
*   [Notes](http://j4u2.com/breadfruit-static/notes/)
    *   [EPVisual](http://j4u2.com/breadfruit-static/notes/ep-visual/)
*   [Workshop](http://j4u2.com/breadfruit-static/workshop/)
    *   [Schedule](http://j4u2.com/breadfruit-static/workshop/schedule/)
    *   [Vision](http://j4u2.com/breadfruit-static/workshop/vision-page/)
*   [Workshop #1](http://j4u2.com/breadfruit-static/workshop-1/)
    *   [Day 1](http://j4u2.com/breadfruit-static/workshop-1/day-1/)
    *   [Day 2](http://j4u2.com/breadfruit-static/workshop-1/day-2/)
    *   [Day 3](http://j4u2.com/breadfruit-static/workshop-1/day-3/)
    *   [Day 4](http://j4u2.com/breadfruit-static/workshop-1/day-4/)
    *   [Day 5](http://j4u2.com/breadfruit-static/workshop-1/day-5/)
*   [Workshop #2](http://j4u2.com/breadfruit-static/workshop-2/)

Workshop
========

**Digital Jam 2.0**

**Mobile Application Development Workshop**

**
Workshop #2: Friday May 25 to May 29
****Held at the University of the West Indies, Mona, St. Andrew
****Math Lecture Hall and Lab
****Two lecture and Lab sessions per day: 1pm-4pm, 6pm -9pm (or later)**

**Workshop #1: Monday April 30th, 2012 to Friday May 4
****Held at the University of the West Indies, Mona, St. Andrew
****Math Lecture Hall and Lab
****Three lecture and Lab sessions per day: 10am-1pm,  2pm-5pm, 6pm -9pm (or later)**

**This workshop is free of charge**

The Digital Jam 2.0 Mobile Applications Development workshop will help young developers move ahead of the technical curve by specializing in cutting edge technologies that let developers build effective native mobile applications (e.g.  for the iPhone and Android  or Blackberry phones) using cross-platform tools that deliver greater flexibility and speed to market.

The five days of intensive development support will focus on two key objectives:

1\. Support development of skills of all participants – from beginners to advanced programmers – as needed for to work as a team to implement commercial-strength mobile application.

2\. Establish the partnerships between creative/art practitioners and engineering/programming specialist as needed to deliver uniquely exciting offerings.

Mobile application development requires programming and art skills and course work typically programing covered a by 12 week course at college level. The 5 day workshop can only give a taste and provide assistance to people already along this path.

The approach will be open and dynamic, with the activities of each day depending of the progress made on the previous day and the needs of the participants.  After the first day of team and individual assessments, sessions will be structured to meet the differing needs of beginning, intermediate and advanced programmers. One will not need to attend all sessions for the workshop to meet your needs.

REGISTER FOR WORKSHOP ONLINE

Please provide IMPORTANT REGISTRATION INFORMATION by filling out the REGISTRATION FORM on the Digital Jam 2.0 App Community Forum main page to help us structure the workshop to best meet your needs.

www.digijam.biz

BRING A LAPTOP to the workshop if you have one.

### Leave a Reply [Cancel reply](/breadfruit/workshop/#respond)

You must be [logged in](http://j4u2.com/breadfruit-static/wp-login.php) to post a comment.

[Proudly powered by WordPress](http://wordpress.org/ "Semantic Personal Publishing Platform")

gha_language: HTML

gha_license_id: MIT


text:
# Abled Not Disabled

This app focuses on the development of a learning disability (LD) child’s cognitive abilities.
It has three fundamental games whose focus is to sharpen auditory, hand to eye coordination and specific mental
abilities. A planetary in-game encourages the child to keep the planets, which constantly change direction, in orbit.
This activity not only improves his/her hand-eye coordination but also improves their knowledge of the solar system.
Musical games focus on specific strokes which sharpen the auditory skills of a LD child.
For example, guitar strokes are known to improve long term memory and increase mental alertness.
The piano improves movement, hearing, and visuospatial abilities. Numeral activities such as number counting,
addition and subtraction, and multiplication are also used to improve the speed of information
processing and working memory in the child.

This repository is split up into two parts. The 'APKFile' folder
contains the .apk for the app, while 'ProjectFiles' contains
the Unity scripts and source code.


text:
# Highway
Simulating traffic flow at Roslags Näsby trafikplats in Täby, Sweden as a part of KTH course work in SI1336. Model of road is constructed by using a directed graph with vertices spaced approximately every 30
meters. Cars are simulated by traversing the graph with a time step size of 1/60th of a second.

Built with a *custom* GUI using [SFML](https://github.com/SFML/SFML) in the C++11 standard. Multiprocessing of the simulation is enabled by default.

<img src=latex/animation.gif width=300>

## Installation on Linux
A Dockerfile is provided to automatically compile the code and it's dependencies. To use the GUI, some Xauthority configuration is needed to be performed. A safe manner is provided by running the shell script provided

```
chmod +x build_and_run_image.sh
sudo ./build_and_run_image.sh
```

To run the program, enter the following command in the docker image
```
cd build && ./highway
```

## Features
- Easily visualize traffic from a birds eye view.
- Simulate in real time speed, or with a multiplier.
- Tune spawn rate of cars to your heart's content.
- Variable driver "aggressiveness", which makes drivers want to accelerate and overtake slower drivers.
- Ramp. Meter.
- Skip visualization and get the raw data written in a text file.
- And much more :)

## Dependencies
Application was built using the following dependencies

- [SFML](https://github.com/SFML/SFML) v2.4.2+dfsg-4
- [fonts-open-sans](https://packages.debian.org/sid/fonts-open-sans) v1.11-1

repository: carlschiller/highway

repo_name: carlschiller/highway


text:
Installation
=========

Composer
---------
You'll need to check out [Composer](http://getcomposer.org/) if you have never used it before.

To Install the Latest Version:

	{
		"require":{"blanc0/cecilia":"master-dev"}
	}

PHAR
---------
You can either create your own .phar archive by running the bundled build_phar.php, then simply include it to your project:

	require '/path/to/cecilia.phar';

Bootstrap
---------
You can alternatively require just the Cecilia bootstrap file as follows:

	require '/path/to/cecilia.bootstrap.php';

Configuration
=============

Storage
=============

Cecilia provides a robust storage interface to allow for caching of responses. See [Spotify ]

APC
------

Requires the [APC](http://php.net/manual/en/book.apc.php) Extension

Memcache
--------

Requires the [Memcache](http://php.net/manual/en/book.memcache.php) Extension and [memcached server](http://memcached.org/)

XCache
-------

Requires the [xcache](xcache.lighttpd.net) PHP Extension

WinCache
-------

Requires the [WinCache](http://www.php.net/manual/en/book.wincache.php) PHP Extension

Redis
------

Requires the [Redis](https://github.com/nicolasff/phpredis) PHP Extension and [Redis Server](http://redis.io)

repository: botrelli/cecilia

repo_name: botrelli/cecilia


text:
# travis-deploy-once

You want to test as many node versions as possible and deploy if all of them pass.
This module allows you do just that in a script running in Travis' after_success hook.

```bash
npm install --save travis-deploy-once
```

```js
const deployOnce = require('travis-deploy-once')

try {
  var result = await deployOnce({
    token: 'asd' // GitHub oAuth token, defaults to process.env.GH_TOKEN
  })
} catch (err) {
  // something went wrong, and err will tell you what
}

if (result === true) deployMyThing()
if (result === false) console.log('Some job(s) failed')
if (result === null) console.log('Did not run inside the first job of the build matrix')
```

repository: community-sharing/Community-sharing

gha_language: JavaScript

repo_name: community-sharing/Community-sharing


text:
---
layout: post
title: The Biggest Act of Love
author: Manal Ghosain
categories:
tags:
---

![Family by the ocean](/images/family-by-ocean.jpg)

Love is an essential part of life. It’s what motivates, forms, sustains, and nourishes all forms of creation. We all share the same desire to love and be loved. However, we have different ideas about how we can express our love.

Today I want to share with you an expression of love we don’t usually think about. But it’s the most powerful and helpful thing we can do. So here it goes.

*The biggest act of love is to allow others to be who they are—fully and unconditionally.*

Easier said than done, especially when it comes to matters of the heart. We love our significant other, our family, and our friends. But there are things about them we wish we could change. So we create imaginary ideals for each person we love, and expect them to live up to them.

We want our loved ones to live the best life possible.  And we really want them to understand us, and appreciate what we do for them.

Sometimes things work out according to our expectations. But most of the time we feel either disappointed in others, or guilty that we’re not helping them enough.

What would happen if we just let others be who they are, for no reason other than loving them that much?

## Letting others be

When we let others be who they are, we:

**Trust life.** We trust that our loved ones are on the best path for them. If they need our help or opinion, they’d ask for it. Their unique life is unfolding as it’s meant to be.

**Trust our loved ones.** They are on their path. They are fully capable of changing course, if they need to. They are living their lives, their way.

**Let go of wanting control.** The other part of trusting is letting go of control. We would need to be conscious of our desire to control the situation or the actions of others.

If I’m on a healthy diet, can I let my loved ones eat whatever they want? Or should they try my way, because it’s supposed to be better?

On a logical level, we all know that we can only control our own behavior. But emotionally, we want others to share our path.

How can we let someone poison their body with cigarettes or alcohol, especially when we’re on a health kick?

We need to let go of wanting to control others and trust that their journey is the right one for them, in this moment.

The more we love others, the more we need to allow them to be who they are. We are no better or worse than anyone else.

## The only thing we can do

The only thing we can do when it comes to loving others is to be there for them. Being there doesn’t mean we need to steer their lives in a certain direction. We can give them attention, and support. We can help, only when asked. And then we let them be, and just be with them.

## How to let others be

Letting others be, especially when we deal with them every day, can be a challenge. How can we let them be, when we don’t like what they’re doing, without feeling passive or complacent?

The following ideas can help. I suggest starting with the first idea.

**Imagine it’s a loved one’s last day.**

Before wanting to say or do anything, imagine that this is the last time you will ever get to interact with this person.

Is what you’re about to say, or do, worth it? Is this the last thing you want to remember about the encounter? In all likelihood, you’ll drop it.

The person is way more precious than any opinion or advice we have.

**Choose curious empathy over controlling judgment.**

Instead of saying I wish my father would stop doing this, and focus on his health, I can imagine myself in my mid eighties having all the life experiences I had and choosing to live the way I live. What would that be like? I don’t know.

I admire my father for living through all the things he’s lived through (war, depression, dispossession, extreme weather conditions, losing his father and being responsible for his siblings and mother at the age of 18). I didn’t live all of that. He managed okay before I came along. I don’t know what I’d do if I experienced his life.

Try to be in someone else’s shoes. How would you feel? What would you do?

When we look deep enough, we realize that every person is awe inspiring—not someone who needs to be guided and told what to do.

**Do nothing.**

If the above two steps fail, consciously choose to do, or say, nothing—unless being asked. Let go, as much as you can, of your own fears and insecurities.

Go within. What are you feeling? What do you want? Do you want the other person to do what you want them to do because you’re afraid? Or because you don’t trust them? What’s the worst that could happen if you just let them do their thing?

Surrender to the feelings. Feel the physical sensations in the body. Breathe deeply. When the sensations subside, choose to let go.

If it helps, imagine that you’re not there. For whatever reason, your loved one is doing something, and you’re thousands of miles away, and no one told you. How would you feel and react?

Imagine a world where we all loved and allowed others to be who they are. We’d live in heaven.

True love is freedom from expectations. It’s unconditional kindness and compassion. And it’s within our reach. We can start right now with the people we love the most.

> “The first place to practice love is at home with the family. We should try to love our family more and more by granting them the right to be the way they are, more and more.” ~Lester Levenson


text:
# Central Bedfordshire Council

Support for schedules provided by [Central Bedfordshire Council](https://www.centralbedfordshire.gov.uk/info/163/bins_and_waste_collections_-_check_bin_collection_days/), serving Central Bedfordshire, UK.

## Configuration via configuration.yaml

```yaml
waste_collection_schedule:
    sources:
    - name: centralbedfordshire_gov_uk
      args:
        postcode: POSTCODE
        house_name: HOUSE_NAME
        version: 1

```

### Configuration Variables

**POSTCODE**
*(string) (required)*

**HOUSE_NAME**
*(string) (required)*

This must exactly match your house name that the search on [Central Bedfordshire Council's website](https://www.centralbedfordshire.gov.uk/info/163/bins_and_waste_collections_-_check_bin_collection_days) returns for your given postcode EXCLUDING the comma and postcode

## Example

```yaml
waste_collection_schedule:
    sources:
    - name: centralbedfordshire_gov_uk
      args:
        postcode: "SG156YF"
        house_name: "10 Old School Walk"
```

gha_language: Python


text:
---
title: Experience Makers Bootcamp
description: Starting point for participants of the Experience Makers Bootcamp
doc-type: multipage-overview
exl-id: 400bd9f1-229c-4016-b06b-8fc033f7dbf2
---
# Experience Makers Bootcamp

## Overview

Many organizations aren't aware of the friction that exist in their customers’ journey, which is the consequence of a siloed and fragmented approach in orchestrating customer communication. Data, Profile and Content need to be perfectly aligned to design and deliver exceptional customer experiences.

Join this bootcamp to learn how a platform-based approach can help you get the insights needed to identify and remove friction points to improve your customer's journey.

Personalisation at scale starts with understanding what can be improved, and a real-time view of your customer is critical to this. Insights lead to action, which leads to more insights. Adobe’s unique platform-centric approach gives you the tools to not only drive technological change, but also impact your organization, your team, and your ability to deliver a holistic customer experience instead of a channel-specific customer experience.

>[!VIDEO](https://video.tv.adobe.com/v/344962?quality=12&enable=on)

## Agenda

### Day 1

10:00: Kickoff
10:30: Customer Journey demo: Art of the possible
11:00: 1-1 personalisation, friction hunting, silos, Adobe POV (whiteboard)
11:45: Break
12:00: Solution Architecture breakdown (whiteboard)
13:00: Lunch
14:00: Userflow 1 Registration & Onboarding - walkthrough (why-what-how)
15:30: Break
16:00: Userflow 2 Blending physical and digital - walkthrough & hands-on / deep dive
18:00: Break
18:30: Walk to the restaurant
19:00: Dinner

### Day 2

08:00: Breakfast
08:30: Introduction to user Journey based Delivery, Team Structure, Delivery backlog
09.45: Userflow 3 Blending physical and digital - Walkthrough with hands-on exercise
11.15: Break
11.30: Userflows wrap up  – (what-where-when)
12:00: Group Presentations
12.30: Lunch
13.30: Userflow 4: Customer Analysis - deepdive
14.30: Conclusion, wrap-up & next steps
15.00: Drinks & adjourn

## Prerequisites

- Access to Adobe Experience Platform: [https://experience.adobe.com/platform](https://experience.adobe.com/platform)
- Access to Adobe Experience Platform Data Collection: [https://experience.adobe.com/#/data-collection/](https://experience.adobe.com/#/data-collection/)
- Access to the bootcamp website on [https://bootcamp.aepdemo.net](https://bootcamp.aepdemo.net)

>[!IMPORTANT]
>
>This tutorial was created to facilitate a particular workshop format. It uses specific systems and accounts to which you might not have access. Even without access, we think you can still learn a lot by reading through this very detailed content. If you're a participant in one of the workshops and need your access credentials, please contact your Adobe representative who will provide you with the required information.

## Architecture

Before you start with the hands-on exercises, have a look at the architecture behind this tutorial. This bootcamp will go deep on a number of features and functionalities around Adobe Experience Platform, and will also discuss multiple integrations across a variety of sources and destinations. In order for you to properly understand the architecture behind this tutorial and the overall positioning of Adobe Experience Platform into your enterprise ecosystem, start by reviewing the architecture video and diagram.

Go to [Architecture](https://experienceleague.adobe.com/docs/platform-learn/comprehensive-technical-tutorial-v22/architecture.html?lang=en).

## Videos

The main objective of our Experience Makers Bootcamp is to help organisations understand what personalization at scale means and how it is very different from what most organisations are doing today. To deliver customer experiences that are consistent, contextual and real-time in an omni-channel world, you need a platform-first mindset where you define everything just once and reuse it everywhere. In the bootcamp, we take you on a real journey that combines customer interactions across website, mobile app, call center and and offline, in-store environment to showcase what personalization at scale really means, in a hands-on way.

>[!VIDEO](https://video.tv.adobe.com/v/345446?quality=12&enable=on)

Several other videos have been created that showcase elements of the bootcamp and powerful integrations between Adobe Experience Platform and non-Adobe applications. Click the below link to find an overview of those videos.

Go to [Videos](https://experienceleague.adobe.com/docs/platform-learn/comprehensive-technical-tutorial-v22/videos.html?lang=en).

## YouTube

You can find additional interesting videos [on our YouTube channel](https://www.youtube.com/channel/UCUKG2dkZ9pYuZUPebQ21jUw).

## User Flows

[1. Acquisition](./uc/uc1/uc1.md)

In this user flow, you'll understand all the elements you need to implement acquisition-focused use cases for unknown, unauthenticated users alongside known, authenticated user by using Real-Time CDP.

[2. Registration & Onboarding](./uc/uc2/uc2.md)

In this user flow, you'll understand all the elements you need to implement registration & onboarding use cases by using Real-Time CDP and Adobe Journey Optimizer.

[3. Blending physical and digital](./uc/uc3/uc3.md)

In this user flow, you'll personalize the customer experience across online and offline channels in a consistent way, by using Real-Time CDP and Adobe Journey Optimizer.

[4. Customer Journey Analysis](./uc/uc4/uc4.md)

In this user flow, you'll get familiar with Customer Journey Analytics and you'll gain insights in how customers are evolving from one channel to the other, from online to offline to callcenter and more.


text:
News hub of SSDUT
===============

## Requirements
```
sudo easy_install requests
sudo easy_install beautifulsoup
sudo easy_install redis
sudo easy_install apscheduler
sudo apt-get install redis-server
```

## Usage
### run the script
```
python info.py &
```
### visit the site
open `http://<IP_ADDRESS>:8080` in an incognito window of Chrome(Ctrl+Shift+N)
Read the news you are interested, and click '已阅' or '全部已阅' to filter news.
The screen capture:
![image](images/ssdut-news-hub.png)


text:
# DevOps resource struct module

#### This module is used and consumed by the devops rest api and custom terraform provider for bootcamp section 7.1.4. Its purpose is to organize the structure of the resources defined in this bootcamp section in order to lessen the strain in having to set up structures for client-side communication for the terraform custom provider to talk to the devops api.

## How to import module for the resources built in go:

### Example in how the import is call in your go code:

```go
import "github.com/liatrio/devops-bootcamp/examples/ch7/devops-resources"
```

#### This is how you would pull the module in the default branch [master]

### If you are trying to pull the module from a branch that differs from the default branch then you can do this step:

#### Here is an example of how to include the module inside of the go.mod within the terraform provider:

```go
require github.com/liatrio/devops-bootcamp/examples/ch7/devops-resource [branch]
```

#### When you run go mod tidy go will look for the module at the head of the branch you specified in go.mod

### Now that you have the right path targeted for the import you can now use this module for any code corresponding to client-side communication from the terraform provider to the devops api.

## How to call package devops_resource:

#### To access struct type that is defined in the module you call it like this:

##### Engineer Struct:

```go
devops_resource.Engineer
```

##### Dev Struct:

```go
devops_resource.Dev
```

##### Ops Struct:

```go
devops_resource.Ops
```

##### DevOps Struct:

```go
devops_resource.DevOps
```

## Notes:

### The structs use references of another struct object to manage lists.

- This allows easier management of the lists when updating a resource.

#### Struct Example:

```go
type DevOps struct {
        Id  string `json:"id"`
        Devs []*Dev `json:"dev"`
        Ops []*Ops `json:"ops"`
}
```

##### DevOps Struct is a good example of this since it manages a list of type Dev and Ops.

### Why is the module name long and almost looks like a path.

- Go looks for the path in which the package and module is referenced.
- For this case the repository is github.com(host)/liatrio(owner)/devops-bootcamp(repo)/examples/ch7/devops-resources(path to package)

repository: liatrio/devops-bootcamp

repo_name: liatrio/devops-bootcamp


text:
---
id: testing
title: Testing
sidebar_label: "Testing"
slug: /recipes/testing/
---

Rematch testing works out of the box with many libraries like Jest, Mocha, Ava, and of course works fine with end to end tests like Cypress or Testing Library.

:::tip
You can check our full suite of test of [@rematch/core](https://github.com/rematch/rematch/tree/main/packages/core/test) to check examples of how to test. We're using `jest` but they should work with any testing provider.
:::

## Jest

This tests are based in Jest, but should be pretty similar in other testing frameworks.

### Reducers

Testing with store.

```twoslash include countModel
// @filename: count.ts
import { createModel } from '@rematch/core'
import { RootModel } from "./models"

export const count = createModel<RootModel>()({
	state: 0,
	reducers: {
		increment(state, payload: number) {
			return state + payload
		},
	},
	effects: (dispatch) => ({
		incrementAsync(payload: number, state) {
			dispatch.count.increment(payload)
		},
	}),
})
```

```twoslash include rootModel
// @filename: models.ts
import { Models } from "@rematch/core"
import { count } from "./count"

export interface RootModel extends Models<RootModel> {
  count: typeof count
}

export const models: RootModel = { count }
```

```twoslash include store
// @filename: store.ts
import { init, RematchDispatch, RematchRootState } from '@rematch/core'
import { models, RootModel } from './models'

export const store = init<RootModel>({
	models,
})

export type Store = typeof store
export type Dispatch = RematchDispatch<RootModel>
export type RootState = RematchRootState<RootModel>
```

```ts twoslash
// @include: countModel
// @include: rootModel
// @filename: count.test.ts
// ---cut---
import { init } from "@rematch/core";
import { models, RootModel } from "./models";

describe("[count] model", () => {
  it("incrementAsync effect should increment given a payload", async () => {
    const store = init<RootModel>({
      models,
    });

    await store.dispatch.count.incrementAsync(3);

    const myModelData = store.getState().count;
    expect(myModelData).toEqual(3);
  });
});
```

### Effects

Testing with store.

```ts twoslash
// @include: countModel
// @include: rootModel
// @filename: count.test.ts
// ---cut---
import { init } from "@rematch/core";
import { models, RootModel } from "./models";

describe("[count] model", () => {
  it("effect: my incrementAsync effect should do something", async () => {
    const store = init<RootModel>({
      models,
    });

    await store.dispatch.count.incrementAsync(3);

    const countData = store.getState().count;
    expect(countData).toEqual(3);
  });
});
```

Testing effects directly.

```ts twoslash
// @include: countModel
// @include: rootModel
// @filename: count.test.ts
// ---cut---
import { count } from "./count";

describe("myModel model", () => {
  it("effect: my effectName should do something", async () => {
    const reducerMockFn = jest.fn();

    // bind the functions you want to check
    await (count.effects as any).incrementAsync.call(
      { reducerThatIsGoingToBeCalled: reducerMockFn },
      { payload: "" }
    );

    // checking if it was called
    expect(reducerMockFn).toHaveBeenCalled();

    // checking if it was called with the expected params
    expect(reducerMockFn).toHaveBeenCalledWith("something");
  });
});
```

## Testing Library

To get started with Testing Library tests since they're similar to e2e you have to wrap your React application with the React-Redux Provider:

```twoslash include testUtils
// @filename: testUtils.tsx
// ---cut---
import React from "react"
import { render } from "@testing-library/react"
import { Provider } from "react-redux"
import type { Store } from "redux"

export const renderWithRematchStore = (ui: React.ReactElement, store: Store) =>
  render(ui, {
    wrapper: ({ children }) => <Provider store={store}>{children}</Provider>,
  })
```

```tsx twoslash title="testUtils.tsx"
// @include: testUtils
```

Now, we can just use this `renderWithRemathStore` instead of the native `render` function that `@testing-library` exposes, to render any component that is connected to Rematch store.
(For ex: using `useSelector`, or `useDispatch`)

Imagine an scenario where we have a component called `<ButtonCounter>` that recovers information of the count model and increments the value:

```twoslash include buttonCounter
// @filename: ButtonCounter.tsx
// ---cut---
import React, { useEffect } from "react"
import { useDispatch, useSelector } from "react-redux"
import type { RootState, Dispatch } from "./store"

export const ButtonCounter = () => {
  const dispatch = useDispatch<Dispatch>()
  const counter = useSelector((rootState: RootState) => rootState.count)

  return (
    <div>
      <span aria-label="Counter">Current counter: {counter}</span>
      <button
        aria-label="Increment Button"
        type="button"
        onClick={() => dispatch.count.incrementAsync(1)}
      >
        Increment Asynchronous
      </button>
    </div>
  )
}
```

```tsx twoslash
// @include: countModel
// @include: rootModel
// @include: store
// @include: buttonCounter
```

We could test with Testing Library that pressing in that buttons correctly dispatches the incrementAsync effect and the `counter` value it's correctly refreshed.

```tsx twoslash
// @noErrors
import React from "react";
import { screen } from "@testing-library/react";
import { store } from "./store";
import { renderWithRematchStore } from "./testUtils";

import { ButtonCounter } from "./ButtonCounter";

describe("ButtonCounter", () => {
  it("should be rendered correctly", async () => {
    renderWithRematchStore(<ButtonCounter />, store);
    expect(screen.getByLabelText("Increment Button")).toBeInTheDocument();
    await userEvent.click(screen.getByLabelText("Increment Button"));
    expect(screen.getByLabelText("Increment Button")).toBeInTheDocument();
    expect(screen.getByLabelText("Counter")).toEqual("Current counter: 1");
  });
});
```

Thanks to `aria-label` tags inside our `ButtonCounter` component we can query this DOM elements with the `screen` property exported by Testing Library.

We recover these DOM elements and we use the Testing Library assertions like `.toBeInTheDocument()` to make sure that everything runs fine.

repository: rematch/rematch

gha_language: TypeScript

repo_name: rematch/rematch


text:
# picopic-e2e-tests

[![e2e-tests](https://github.com/jmp/picopic-e2e-tests/actions/workflows/e2e-tests.yml/badge.svg)](https://github.com/jmp/picopic-e2e-tests/actions/workflows/e2e-tests.yml)

This project hosts end-to-end tests for [Picopic](https://github.com/jmp/picopic).

It runs tests using the real frontend hosted at https://picopic.io against
the real backend hosted on https://api.picopic.io.


text:
+++
title = "aws_dynamodb_table Resource"
platform = "aws"
draft = false
gh_repo = "inspec-aws"

[menu.inspec]
title = "aws_dynamodb_table"
identifier = "inspec/resources/aws/aws_dynamodb_table Resource"
parent = "inspec/resources/aws"
+++

Use the `aws_dynamodb_table` InSpec audit resource to test properties of a single DynamoDb Table.

## Installation

{{% inspec_aws_install %}}

## Syntax

### Ensure an DynamoDb Table exists.

```ruby
describe aws_dynamodb_table(table_name: 'table-name') do
  it { should exist }
end
```

## Parameters

`table_name` _(required)_

: The table name used by this DynamoDb Table. This must be passed as a `table_name: 'value'` key-value entry in a hash.

## Properties

`table_name`
: The name of the DynamoDb Table.

`table_status`
: The status of the DynamoDb Table.

`table_arn`
: The Amazon Resource Names of the DynamoDb Table.

`creation_date`
: The date the DynamoDb Table was created. eg. `01/01/2019`.

`number_of_decreases_today`
: The number of provisioned throughput decreases for this table during this UTC calendar day.

`write_capacity_units`
: The maximum number of writes consumed per second before DynamoDb returns a ThrottlingException.

`read_capacity_units`
: The maximum number of strongly consistent reads consumed per second before DynamoDb returns a ThrottlingException.

`item_count`
: The number of entries in the  DynamoDb Table.

`attributes`
: An array of attributes that describe the key schema for the table and indexes. This is returned as a hash. Each entry is composed of: `attribute_name` - The name of this key attribute. `attribute_type` - The datatype of the attribute : `B` - Boolean, `N` - Number, `S` - string.

`key_schema`
: Specifies the attributes that make up the primary key for a table or an index. This is returned as a hash. The attributes in KeySchema must also be defined in the Attributes array. Each element in the KeySchemaElement array is composed of: `attribute_name` - The name of this key attribute. `key_type` - The role that the key attribute will assume: `HASH` - partition key, `RANGE` - sort key.

`global_secondary_indexes`
: A list of global secondary indexes if there is any referenced on the selected table.

## Examples

**Ensure DynamoDb Table status is active.**

```ruby
describe aws_dynamodb_table(table_name: 'table-name') do
  its('table_status') { should eq 'ACTIVE' }
end
```

**Ensure DynamoDb Table has an attribute.**

```ruby
describe aws_dynamodb_table(table_name: 'table-name') do
  its('attributes') { should_not be_empty }
  its('attributes') { should include({:attribute_name =>'table_field', :attribute_type =>'N'}) }
end
```

**Ensure DynamoDb Table has a key_schema.**

```ruby
describe aws_dynamodb_table(table_name: 'table-name') do
  its('key_schema') { should_not be_empty }
  its('key_schema') { should include({:attribute_name =>'table_field', :key_type =>'HASH'}) }
end
```

**Ensure DynamoDb Table has the correct global secondary indexes set.**

```ruby
aws_dynamodb_table(table_name: 'table-name').global_secondary_indexes.each do |global_sec_idx|
  describe global_sec_idx do
    its('index_name') { should eq 'TitleIndex' }
    its('index_status') { should eq 'ACTIVE' }
    its('key_schema') { should include({:attribute_name =>'Title', :key_type =>'HASH'}) }
    its('provisioned_throughput.write_capacity_units') { should cmp 10 }
    its('provisioned_throughput.read_capacity_units') { should cmp 10 }
    its('projection.projection_type') { should eq 'INCLUDE' }
  end
end
```

**Ensure DynamoDb Table is encrypted.**

```ruby
describe aws_dynamodb_table(table_name: 'table-name') do
   it { should be_encrypted}
end
```

## Matchers

{{% inspec_matchers_link %}}

#### be_encrypted

The `be_encrypted` matcher tests if the DynamoDB Table is encrypted.

```ruby
it { should be_encrypted }
```

### exist

The control will pass if the describe returns at least one result.

Use `should_not` to test the entity should not exist.

```ruby
describe aws_dynamodb_table(table_name: 'table-name') do
  it { should exist }
end
```

```ruby
describe aws_dynamodb_table(table_name: 'table-name') do
  it { should_not exist }
end
```

## AWS Permissions

{{% aws_permissions_principal action="DynamoDB:Client:DescribeTableOutput" %}}

You can find detailed documentation at [Actions, Resources, and Condition Keys for Amazon Dynamodb](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazondynamodb.html).

repository: inspec/inspec-aws

gha_language: Ruby

gha_license_id: NOASSERTION

repo_name: inspec/inspec-aws


text:
<img alt="Grenache Logo" width="50%" src="logos/logo-full-rect-black.png" />

Grenache is a DHT based high-performance microservices framework by Bitfinex.
Its decentralised and optimized for performance. Because its simple, it is easy
to understand and to set up.

Grenache uses Distributed Hashtables, known from Bittorrent, to build a network between peers.
Its based on [Kademlia](https://en.wikipedia.org/wiki/Kademlia).

Peers can send each other commands (RPC), and they can also store values in the DHT.
Pub/Sub is also possible.

#### Features
* Decentralised / Distributed architecture
* Easy Bootstrap
* Indefinite scalability and shapes
* High-Performance

### Implementations

#### Grape (the core)
* https://github.com/bitfinexcom/grenache-grape

#### Peer Implementations

Transports:
* WebSocket transport: super-fast, great for Internet
* HTTP transport: great for Internet
* ZeroMQ transport: super-fast, perfect for internal networks

Patterns:
* PUB/GET: put/get data to/from the DHT
* RPC: simple and efficient RPC pattern
* PUB/SUB: (Work In Progress)

Note: At the moment there is no interoperability between WebSocket and ZeroMQ implementations. A Proxy implementation will come later.

##### Node.JS Clients
* https://github.com/bitfinexcom/grenache-nodejs-ws : WebSocket based Grape microservices
* https://github.com/bitfinexcom/grenache-nodejs-http : HTTP based Grape microservices
* https://github.com/bitfinexcom/grenache-nodejs-zmq : ZeroMQ based Grape microservices
* https://github.com/bitfinexcom/grenache-nodejs-ws-tls : WebSocket based Grape microservices with TLS support

##### Ruby Clients
* https://github.com/bitfinexcom/grenache-ruby-ws : WebSocket based Grape microservices
* https://github.com/bitfinexcom/grenache-ruby-http : HTTP based Grape microservices

### Background
* [Distributed Hash Table](http://www.bittorrent.org/beps/bep_0005.html) introduction
* [Kademlia on Wikipedia](https://en.wikipedia.org/wiki/Kademlia)
* [Kademlia: A Peer-to-Peer Information System Based on the XOR Metric](http://www.ic.unicamp.br/~bit/ensino/mo809_1s13/papers/P2P/Kademlia-%20A%20Peer-to-Peer%20Information%20System%20Based%20on%20the%20XOR%20Metric%20.pdf)

#### Composition

##### 1. Grape: Grenache Discovery Node
* Grenache Network building
* DHT interaction APIs for Clients: service discovery, DHT data storage

**Features**

WebSocket API endpoints:
* Announce a Service
* Lookup a Service
* Push data to DHT

##### 2. Client: Grenache Client implementation on specific Transports
* Client/Worker: offer/publish and request/subscribe Services
* Patterns: request/reply, publish/subscribe
* Transports: WebSocket, HTTP, ZeroMQ

**Features**
* Offer / Publish a Service: create and announce a Service on the DHT
* Request / Subscribe to Service: find a Service throught the DHT and connect to it

### Practice

![Grenache Structure](https://raw.githubusercontent.com/bitfinexcom/grenache/master/doc/structure.png)

* client: can both offer/publish or request/subscribe Services

### Contribute
Any contribution in form of question, issue, idea and pull requests is well accepted

### Contacts
* [Paolo Ardoino](https://github.com/prdn)

repository: robertkowalski/grenache

repo_name: robertkowalski/grenache


text:
---
title: Organizations
layout: usermanual-page.hbs
position: 6
---

Organizations offer a way for businesses and large projects to manage many users. They can have multiple administrators and permissions can be handled on a per project basis.

Free Organizations includes:

- Unlimited public projects
- Unlimited public team members
- Project-based permissions
- Offline Archive & Restore
- Ability to remove PlayCanvas branding
- Access to [REST API][2]

You can also purchase an [Organization Plan][1] which includes:

- Unlimited private projects
- Additional storage space

[1]: https://playcanvas.com/plans
[2]: /user-manual/api

branch_name: refs/heads/dev


text:
# Angular Reactive Forms: Objectives and Outcomes

In this lesson you will learn to

- __Create__ `reactive forms` in your Angular application.
- __Perform__ `form validation` using the validation support for reactive forms.

At the end of this lesson you will be able to:

- Add a form to your Angular application using reactive forms.
- Add form validation to your reactive Angular forms

## Lectures

### Reactive Forms

- Explicit management of data flowing between an non-UI data model and a UI-oriented form model
    - Create a tree of Angular form control objects in the component class
    - Bind them to the native form control elements in the template
    - Component class has immediate access to both data model and the form control structure
        - Push data model values to form controls and pull user-changed values back out

- Reactive patterns, testing and validation

### Reactive Form Classes

### Form Builder

### Populate Form Model

###


text:
# Qiskit helper functions

This documents aims to direct you towards useful Qiskit builtin functions that could be of help in the realization of the exercises.

There are many subroutines that could be quite complex and that Qiskit embeds in very simple methods to use. However, the idea of the hackathon is to approach this complexity with simple examples, before understanding how to use those generic and useful Qiskit modules.

## Expectation Value

Qiskit has a method to compute easily expectation values for Pauli operators: https://qiskit.org/documentation/stubs/qiskit.aqua.operators.expectations.PauliExpectation.html#qiskit.aqua.operators.expectations.PauliExpectation

## Unitary to circuit converter

Transpile a unitary to circuit. You can define a unitary using the Operator class (initializable with a List of Lists to build your matrix) and add the quantum circuit corresponding to this unitary by simply calling the method unitary of your QuantumCircuit instance. Info available here: https://qiskit.org/documentation/stubs/qiskit.circuit.QuantumCircuit.unitary.html#qiskit.circuit.QuantumCircuit.unitary

## Create a controlled version of a quantum gate

You can convert a quantum circuit instance to a Qiskit gate instance, and create a controlled gate out of it following the syntax presented here:
https://qiskit.org/documentation/stubs/qiskit.circuit.Gate.control.html#qiskit.circuit.Gate.control

You can then recover the corresponding quantum circuit from the new gate: https://qiskit.org/documentation/stubs/qiskit.circuit.ControlledGate.html#qiskit.circuit.ControlledGate