text:
# TD3 on MuJoCo benchmarks

This example trains a TD3 agent ([Addressing Function Approximation Error in Actor-Critic Methods](http://arxiv.org/abs/1802.09477)) on MuJoCo benchmarks from OpenAI Gym.

## Requirements

- MuJoCo Pro 1.5
- mujoco_py>=1.50, <2.1

## Running the Example

To run the training example:
```
python train_td3.py [options]
```

We have already pretrained models from this script for all the domains listed in the [results](#Results) section. To load a pretrained model:

```
python train_td3.py --demo --load-pretrained --env HalfCheetah-v2 --pretrained-type best --gpu -1
```

### Useful Options

- `--gpu`. Specifies the GPU. If you do not have a GPU on your machine, run the example with the option `--gpu -1`. E.g. `python train_td3.py --gpu -1`.
- `--env`. Specifies the environment. E.g. `python train_td3.py --env HalfCheetah-v2`.
- `--render`. Add this option to render the states in a GUI window.
- `--seed`. This option specifies the random seed used.
- `--outdir` This option specifies the output directory to which the results are written.
- `--demo`. Runs an evaluation, instead of training the agent.
- `--load-pretrained` Loads the pretrained model. Both `--load` and `--load-pretrained` cannot be used together.
- `--pretrained-type`. Either `best` (the best intermediate network during training) or `final` (the final network after training).

To view the full list of options, either view the code or run the example with the `--help` option.

## Known differences

- While the original paper used different numbers of timesteps for which purely random policy is used for different environments (10000 for HalfCheetah and Ant, 1000 for the remaining), we used 10000 across all the environments.
- While [the original implementation](https://github.com/sfujim/TD3) updates the model N times after every episode where N is the length of the episode, our implementation updates the model once every step. In addition, ours does not update the model until the replay buffer has at least 10000 transitions.

## Results

PFRL scores are based on 10 trials using different random seeds, using the following command.

```
python train_td3.py --seed [0-9] --env [env]
```

During each trial, the agent is trained for 1M timesteps and evaluated after every 5000 timesteps, resulting in 200 evaluations.
Each evaluation reports average return over 10 episodes without exploration noise.

### Max Average Return

Maximum evaluation scores, averaged over 10 trials (+/- standard deviation), are reported for each environment.

Reported scores are taken from the "TD3" column of Table 1 of [Addressing Function Approximation Error in Actor-Critic Methods](http://arxiv.org/abs/1802.09477).
Although the original paper used v1 versions of MuJoCo envs, we used v2 as v1 are not supported by recent versions of OpenAI Gym.

| Environment               | PFRL Score            | Reported Score        |
| ------------------------- |:---------------------:|:---------------------:|
| HalfCheetah-v2            | **10417.28**+/-833.17 |     9636.95+/-859.065 |
| Hopper-v2                 |  **3691.14**+/-138.22 |      3564.07+/-114.74 |
| Walker2d-v2               |      4430.85+/-667.57 |  **4682.82**+/-539.64 |
| Ant-v2                    |  **4752.56**+/-992.02 |     4372.44+/-1000.33 |
| Reacher-v2                |      **-2.69**+/-0.08 |          -3.60+/-0.56 |
| InvertedPendulum-v2       |        1000.00+/-0.00 |        1000.00+/-0.00 |
| InvertedDoublePendulum-v2 |     7507.61+/-3903.04 |   **9337.47**+/-14.96 |

### Last 100 Average Return

Average return of last 10 evaluation scores, averaged over 10 trials, are reported for each environment.

Reported scores are taken from the "TD3" row of Table 2 of [Addressing Function Approximation Error in Actor-Critic Methods](http://arxiv.org/abs/1802.09477).
Although the original paper used v1 versions of MuJoCo envs, we used v2 as v1 are not supported by recent versions of OpenAI Gym.

| Environment               | PFRL Score   | Reported Score |
| ------------------------- |:------------:|:--------------:|
| HalfCheetah-v2            | **10047.79** |        9532.99 |
| Hopper-v2                 |  **3400.06** |        3304.75 |
| Walker2d-v2               |      4056.17 |    **4565.24** |
| Ant-v2                    |  **4333.70** |        4185.06 |
| Reacher-v2                |        -3.87 |            N/A |
| InvertedPendulum-v2       |       964.92 |            N/A |
| InvertedDoublePendulum-v2 |      7216.69 |            N/A |

### Training times
These training times were obtained by running `train_td3.py` on a single CPU and a single GPU.

| Environment            | PFRL Time (hours) |
| ---------------------- |:-----------------:|
| HalfCheetah            | 3.29              |
| Hopper                 | 3.27              |
| Walker2d               | 3.34              |
| Ant                    | 3.64              |
| Reacher                | 3.03              |
| InvertedPendulum       | 3.21              |
| InvertedDoublePendulum | 3.21              |

### Learning Curves

The shaded region represents a standard deviation of the average evaluation over 10 trials.

![HalfCheetah-v2](assets/HalfCheetah-v2.png)
![Hopper-v2](assets/Hopper-v2.png)
![Walker2d-v2](assets/Walker2d-v2.png)
![Ant-v2](assets/Ant-v2.png)
![Reacher-v2](assets/Reacher-v2.png)
![InvertedPendulum-v2](assets/InvertedPendulum-v2.png)
![InvertedDoublePendulum-v2](assets/InvertedDoublePendulum-v2.png)

repository: pfnet/pfrl

gha_language: Python

repo_name: pfnet/pfrl


text:
# GraphSAGE: Inductive Representation Learning on Large Graphs

[GraphSAGE](https://cs.stanford.edu/people/jure/pubs/graphsage-nips17.pdf) is a general inductive framework that leverages node feature
information (e.g., text attributes) to efficiently generate node embeddings for previously unseen data. Instead of training individual embeddings for each node, GraphSAGE learns a function that generates embeddings by sampling and aggregating features from a node’s local neighborhood. Based on PGL, we reproduce GraphSAGE algorithm and reach the same level of indicators as the paper in Reddit Dataset. Besides, this is an example of subgraph sampling and training in PGL.

### Datasets
The reddit dataset should be downloaded from the following links and placed in directory ```./data```. The details for Reddit Dataset can be found [here](https://cs.stanford.edu/people/jure/pubs/graphsage-nips17.pdf).

- reddit.npz https://drive.google.com/open?id=19SphVl_Oe8SJ1r87Hr5a6znx3nJu1F2J
- reddit_adj.npz: https://drive.google.com/open?id=174vb0Ws7Vxk_QTUtxqTgDHSQ4El4qDHt

### Dependencies

- paddlepaddle>=1.6
- pgl

### How to run

To train a GraphSAGE model on Reddit Dataset, you can just run

```
 python train.py --use_cuda --epoch 10 --graphsage_type graphsage_mean --normalize --symmetry
```

If you want to train a GraphSAGE model with multiple GPUs, you can just run

```
CUDA_VISIBLE_DEVICES=0,1 python train_multi.py --use_cuda --epoch 10 --graphsage_type graphsage_mean --normalize --symmetry  --num_trainer 2
```

#### Hyperparameters

- epoch: Number of epochs default (10)
- use_cuda: Use gpu if assign use_cuda.
- graphsage_type: We support 4 aggregator types including "graphsage_mean", "graphsage_maxpool", "graphsage_meanpool" and "graphsage_lstm".
- normalize: Normalize the input feature if assign normalize.
- sample_workers: The number of workers for multiprocessing subgraph sample.
- lr: Learning rate.
- symmetry: Make the edges symmetric if assign symmetry.
- batch_size: Batch size.
- samples_1: The max neighbors for the first hop neighbor sampling. (default: 25)
- samples_2: The max neighbors for the second hop neighbor sampling. (default: 10)
- hidden_size: The hidden size of the GraphSAGE models.

### Performance

We train our models for 200 epochs and report the accuracy on the test dataset.

| Aggregator | Accuracy   | Reported in paper |
| --- | --- | --- |
| Mean | 95.70% |  95.0% |
| Meanpool | 95.60% | 94.8% |
| Maxpool | 94.95%  | 94.8% |
| LSTM | 95.13% | 95.4% |

repository: PaddlePaddle/PGL

branch_name: refs/heads/main

extension: md

license_type: permissive

repo_name: PaddlePaddle/PGL


text:
# AWS IAM Controller for Kubernetes
[![Build Status](https://travis-ci.org/mikkeloscar/kube-aws-iam-controller.svg?branch=master)](https://travis-ci.org/mikkeloscar/kube-aws-iam-controller)
[![Coverage Status](https://coveralls.io/repos/github/mikkeloscar/kube-aws-iam-controller/badge.svg?branch=master)](https://coveralls.io/github/mikkeloscar/kube-aws-iam-controller?branch=master)

This is a **Proof of Concept** Kubernetes controller for distributing AWS IAM
role credentials to pods via secrets.

It aims to solve the same problem as other existing tools like
[jtblin/kube2iam](https://github.com/jtblin/kube2iam), namely distribute
different AWS IAM roles to different pods within the same cluster.  However, it
solves the problem in a different way to work around an inherit problem with
the architecture or kube2iam and similar solutions.

#### EC2 metadata service solution (kube2iam)

Kube2iam works by running an EC2 metadata service proxy on each node in order
to intercept role requests made by pods using one of the AWS SDKs. Instead of
forwarding the node IAM role to the pod, the proxy will make an assume role
call to [STS](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html)
and get the role requested by the pod (via an annotation). If the assume role
request is fast, everything is fine, and the pod will get the correct role.
However, if the assume role request is too slow (>1s) then the AWS SDKs will
timeout and try to get credentials via the next option in the chain (e.g.
a file) resulting in the pod not getting the expected role or no role at all.

This is often not a problem in clusters with a stable workload, but if you have
clusters with a very dynamic workload there will be a lot of cases where a pod
starts before kube2iam is ready to provide the expected role. One case is when
scaling up a cluster and a new pod lands on a fresh node before kube2iam,
another case is when a new pod is created and starts before kube2iam got the
event that the pod was created.
During update of the kube2iam daemonset there will also be a short timeframe
where the metadata url will be unavailable for the pods which could lead to a
refresh of credentials failing.

#### Kubernetes secrets solution

Instead of running as a proxy on each node, this controller runs as a
single instance and distributes AWS IAM credentials via secrets. This solves
the race condition problem by relying on a property of Kubernetes which ensures
that a secret, mounted by a pod, must exist before the pod is started. This
means that the controller can even be away for a few minutes without affecting
pods running in the cluster as they will still be able to mount and read the
secrets.
Furthermore having a single controller means there is only one caller for to
the AWS API resulting in fewer calls which can prevent ratelimiting in big
clusters and you don't need to give all nodes the power to assume other roles
if it's not needed.

One minor trade-off with this solution is that each pod requiring AWS IAM
credentials must define a secret mount rather than a single annotation.

**NB** This approach currently only works for some of the AWS SDKs. I'm
reaching out to AWS to figure out if this is something that could be supported.

See the [configuration guide for supported SDKs](/docs/sdk-configuration.md).

## How it works

The controller watches for new pods, if it sees a pod which has an AWS IAM role
defined it will ensure there is a secret containing credentials for the IAM
role which can be mounted as a file by the pod.

Each secret resource created by the controller will have a label
`heritage=kube-aws-iam-controller` to indicate that it's owned by the
controller.
The controller will continuously pull all secrets with this label and ensure
the credentials are refreshed before they expire. It will also cleanup secrets
with credentials which are no longer requested by any pods.

### Specifying AWS IAM role on pods

**See the [configuration guide for supported
SDKs](/docs/sdk-configuration.md)**.

In order to specify that a pod should get a certain AWS IAM role assigned the
pod spec must include a volume mount from a secret with the following secret
name pattern: `aws-iam-<you-iam-role-name>`. Further more a volume mount point
must be defined for each container requiring the role in the pod and each
container must also have the environment variable
`AWS_SHARED_CREDENTIALS_FILE=/path/to/mounted/secret` defined. The environment
variable is used by AWS SDKs and the AWS CLI to automatically find and use the
credentials file.

See a full example in [example-app.yaml](/docs/example-app.yaml).

**Note**: This way of specifying the role on pod specs are subject to change.
It is currently moving a lot of effort on to the users defining the pod specs.
A future idea is to make the controller act as an admission controller which
can inject the required configuration automatically.

## Setup

The `kube-aws-iam-controller` can be run as a deployment in the cluster.
See [deployment.yaml](/docs/deployment.yaml).

Deploy it by running:

```bash
$ kubectl apply -f docs/deployment.yaml
```

To ensure that pods requiring AWS IAM roles doesn't go to the EC2 metadata
service of the node instead of using the credentials file provided by the
secret you must block the metadata service from the pod network on each node.
E.g. with an iptables rule:

```bash
$ /usr/sbin/iptables \
      --append PREROUTING \
      --protocol tcp \
      --destination <IP_ADDRESS> \
      --dport 80 \
      --in-interface cni0 \
      --match tcp \
      --jump DROP
```

Where `cni0` is the interface of the pod network on the node.

**Note**: The controller will read all pods on startup and therefor the memory
limit for the pod must be set relative to the number of pods in the cluster
(i.e. vertical scaling).

### Bootstrap in non-AWS environment

If you need access to AWS from another environment e.g. GKE then the controller
can be deployed with seed credentials and refresh its own credentials used
for the assume role calls similar to how it refreshes all other credentials.

To create the initial seed credentials you must configure an AWS IAM role used
for the assume role calls. In this example the IAM role is created via
cloudformation, but you can do it however you like. The important part is that
the role has permissions to do `sts` calls as it will be assuming other roles.
And you should also allow the role to be assumed by your own user for creating
the initial seed credentials:

```sh
$ cat role.yaml
Metadata:
  StackName: kube-aws-iam-controller-role
Resources:
  KubeAWSIAMControllerRole:
    Type: AWS::IAM::Role
    Properties:
      RoleName: kube-aws-iam-controller-role
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
        - Action: ['sts:AssumeRole']
          Effect: Allow
          Principal:
            AWS: "<arn-of-your-user>"
        Version: '2012-10-17'
      Path: /
      Policies:
      - PolicyName: assumer-role
        PolicyDocument:
          Version: '2012-10-17'
          Statement:
          - Action:
            - sts:*
            Resource: "*"
            Effect: Allow
# create the role via cloudformation
$ aws cloudformation create-stack --stack-name kube-aws-iam-controller-role --template-body=file://role.yaml --capabilities CAPABILITY_NAMED_IAM
```

And then you can use the script `./scripts/get_credentials.sh` to generate
initial credentials and create a secret.

```sh
$ export ARN="arn.of.the.iam.role"
$ kubectl create secret generic aws-iam-<name-of-role> --from-literal "credentials.json=$(./scripts/get_credentials.sh "$ARN")" --from-literal "credentials.process=$(printf "[default]\ncredential_process = cat /meta/aws-iam/credentials.json\n")"
```

Once the secret is created you can deploy the controller using the example
manifest in [deployment_with_role.yaml](/docs/deployment_with_role.yaml).

The controller will use the secret you created with temporary credentials and
continue to refresh the credentials automatically.

## Building

This project uses [Go modules](https://github.com/golang/go/wiki/Modules) as
introduced in Go 1.11 therefore you need Go >=1.11 installed in order to build.
If using Go 1.11 you also need to [activate Module
support](https://github.com/golang/go/wiki/Modules#installing-and-activating-module-support).

Assuming Go has been setup with module support it can be built simply by running:

```sh
export GO111MODULE=on # needed if the project is checked out in your $GOPATH.
$ make
```

repository: cw-sakamoto/kube-aws-iam-controller

branch_name: refs/heads/master

repo_name: cw-sakamoto/kube-aws-iam-controller


text:
---
layout: default
---

# Session P73.2
## Prediction Of Paroxysmal Atrial Fibrillation By Footprint Analysis
## C.-C. Yang

### National Yang-Ming University
### Taipei, Taiwan

This study presents a new, simple algorithm called footprint analysis
to predict risk and onset of paroxysmal atrial fibrillation (PAF) from
single channel surface electrocardiogram. The approach is based on
hypothesis that subject who has risk of PAF may display a specific
pattern in change of heart rate. This can be applied as footprint to
identify the risk and onset of PAF. The binary code (0,1) is assigned
according to difference of adjacent R-R intervals to represent
acceleration and deceleration of heart rate, respectively. A R-R
interval series is continuously calculated by a 17 heartbeats window,
which results in a set of 16-bit number. Each number represents a
specific pattern of heart rate variation. The goal of this algorithm
is to determine which number has higher possibility in PAF patients
for risk assessment, and to identify the number that only present
before onset of PAF. A set of number determined by the algorithm from
learning dataset was then applied as footprint to the testing dataset.
Score for event 1 was 33/50 (CinC Challenge 2001 entry
20010422.030701) and score for event 2 was 38/50 (CinC Challenge 2001
entry 20010423.045638). In conclusion, the successful of this
algorithm is to identify hidden pattern embedded in the highly
dimensional phase space of R-R intervals. Further evaluation in the
link between microscopic variation in R-R intervals and macroscopic
physiologic conditions may be useful in screening and predicting the
onset of atrial arrhythmias.

gha_language: HTML


text:
# eq-terraform-elasticsearch

This Terraform creates a standalone environment that runs an elastic search cluster with the lookup lists deployed and the `eq-lookup-api` to query the lists

## Setup

Copy `terraform.tfvars.example` to `terraform.tfvars` filling in the required values

## Running

  - Run `terraform init` to import the different modules and set up remote state. When asked to provide a name for the state file choose the same name as the `env` value in your `terraform.tfvars`

  - Run `terraform plan` to check the output of terraform

  - Run `terraform apply` to create your infrastructure environment

  - Run `terraform destroy` to destroy your infrastructure environment

license: MIT


text:
*This repository is a mirror of the [component](http://component.io) module [ramitos/resizable-textarea](http://github.com/ramitos/resizable-textarea). It has been modified to work with NPM+Browserify. You can install it using the command `npm install npmcomponent/ramitos-resizable-textarea`. Please do not open issues or send pull requests against this repo. If you have issues with this repo, report it to [npmcomponent](https://github.com/airportyh/npmcomponent).*
# resizable-textarea

make a textarea auto resizable. [demo](http://ramitos.github.com/resizable-textarea/)

## install

```bash
$ component install ramitos/resizable-textarea
```

## api

```js
var rta = require('resizable-textarea');

rta(document.getElementById('some-textarea-id'));
```

## issues

 * the textarea only grows, and doesn't shrink when the text is reduced.

## License

MIT

repository: npmcomponent/ramitos-resizable-textarea

repo_name: npmcomponent/ramitos-resizable-textarea


text:
Detonates one or more files using BitDam integration.
Returns verdict to the War Room and file reputations to the context data.

Supported file types are mainly PDF & microsoft office software.

## Dependencies
This playbook uses the following sub-playbooks, integrations, and scripts.

## Sub-playbooks
* GenericPolling

## Integrations
This playbook does not use any integrations.

## Scripts
* Set

## Commands
* bitdam-get-verdict
* bitdam-upload-file

## Playbook Inputs
---

| **Name** | **Description** | **Default Value** | **Source** | **Required** |
| --- | --- | --- | --- | --- |
| File | The file object of the file to detonate. The File is taken from the context. | None | File | Optional |
| Interval | The duration for executing the pooling (in minutes). | 1 | - | Optional |
| Timeout | The duration after which to stop pooling and to resume the playbook (in minutes). | 10 | - | Optional |

## Playbook Outputs
---

| **Path** | **Description** | **Type** |
| --- | --- | --- |
| BitDam.Analysis.ID | The sample ID. | string |
| DBotScore.Vendor | The name of the vendor: BitDam. | string |
| BitDam.Analysis.Verdict | The analysis verdict. | string |
| BitDam.Analysis.Status | The analysis status. | string |
| DBotScore.Indicator | The name of the sample file or URL. | unknown |
| DBotScore.Type | The 'file' for file samples. | string |
| DBotScore.Score | The actual score. | number |

## Playbook Image
---
![Detonate_File_-_BitDam](https://raw.githubusercontent.com/demisto/content/1bdd5229392bd86f0cc58265a24df23ee3f7e662/docs/images/playbooks/Detonate_File_-_BitDam.png)

repository: demisto/content

gha_license_id: MIT

repo_name: demisto/content


text:
# chego-sqlite

This is a SQLite driver for Chego library.

## Install
```
npm install --save @chego/chego-mysql
```

## Usage
Create a new Chego object using the `chegoSQLite` and configuration object.

The configuration object - `SQLiteConfig` - is optional, if you don't provide one, sqlite will set `:memory:` as a database storage.

```
const { newChego, newQuery } = require("@chego/chego");
const { chegoSQLite } = require("@chego/chego-sqlite");
const chego = newChego(chegoSQLite, {
  database : 'filepath',
  mode     : OpeningMode.OPEN_READWRITE
});

...

const query = newQuery();

await chego.connect();

query.select('*').from('superheroes').where('origin').is.eq('Gotham City').limit(10);

chego.execute(query)
.then(result => {
    console.log('RESULT:', JSON.stringify(result));
    chego.disconnect();
})
.catch(error => {
    console.log('ERROR:', error);
    chego.disconnect();
});

...

```

Under the hood it uses Node.js `sqlite3` module, so please refer to this [link](https://github.com/mapbox/node-sqlite3) for more information on the configuration.

For more information on how `Chego` works with database drivers, please read [Chego Usage guide](https://github.com/chegojs/chego/blob/master/README.md).

## API
```
enum OpeningMode {
    READONLY = sqlite3.OPEN_READONLY,
    READWRITE = sqlite3.OPEN_READWRITE,
    CREATE = sqlite3.OPEN_CREATE
}

type SQLiteConfig = { mode:OpeningMode, database:string }
```

## Contribute
There is still a lot to do, so if you want to be part of the Chego project and make it better, it's great.
Whether you find a bug or have a feature request, please contact us. With your help, we'll make it a great tool.

[How to contribute](https://github.com/orgs/chegojs/chego/CONTRIBUTING.md)

Follow our kanban boards to be up to date

[Kanban board](https://github.com/orgs/chegojs/projects/7)

Join the team, feel free to catch any task or suggest a new one.

## License

Copyright (c) 2019 [Chego Team](https://github.com/orgs/chegojs/people)

Licensed under the [MIT license](LICENSE).

repository: chegojs/chego-sqlite

gha_language: TypeScript

repo_name: chegojs/chego-sqlite


text:
---
title: Plague - Feb 19
catalog: true
tags:
  - reading
permalink: /r_plague_2_19.html
folder: plague
summary:
---

1.  “The night watchman at the hotel, a <b data-toggle="tooltip" data-original-title="{{site.data.glossary.level-headed}}">`level-headed`</b> man, assured me that all these rats meant trouble coming. ‘When the rats leave a ship . . .’ I replied that <b data-toggle="tooltip" data-original-title="{{site.data.answers.plag_d_9_a1}}">`________(适用于船上)`</b>, but for towns it hadn’t yet been demonstrated.

2.  “But he wouldn’t be surprised if <b data-toggle="tooltip" data-original-title="{{site.data.answers.plag_d_9_b1}}">`________(正在酝酿一场地震)`</b>. I admitted that was possible, and then he asked if the prospect didn’t alarm me.

3.  “This excellent example notwithstanding, everybody in town is talking about the rats, and the local newspaper has <b data-toggle="tooltip" data-original-title="{{site.data.answers.plag_d_9_c1}}">`________(起一份作用/参与/介入)`</b>.

4.  Then, immediately following these eccentricities of thought and expression, we <b data-toggle="tooltip" data-original-title="{{site.data.answers.plag_d_9_d1}}">`________(偶然找到)`</b> detailed description of the streetcar service in the town.


text:
# Profile a Game with Blazor WebAssembly

You find many sources to do this exercise with pure JavaScript, some supported on `canvas`, others with only CSS. An example [»»](https://www.geeksforgeeks.org/pong-game-in-javascript/)

**In Blazor...**

![Screen](https://github.com/harveytriana/BlazorGamePractice/blob/master/Screens/bz_pong.png)

Doing it in Blazor is an interesting exercise, the goal here is not a product. I used some of the JavaScript logic, common in sources, and programmed other things for C#. It demonstrates the powerful reactive ability of Blazor, without a line of JavaScript. Try to formalize the code into good practice; It could be done in a single component, but it is not elegant. Didactically it is a good suggestion to see what an architecture would look like for a game written in Blazor.

## Requirements

  - Minimal: Visual Studio 2019 16.8.x | vscode | with NET 5.0

----

License MIT

My Blog: [Blazor Spread](https://www.blazorspread.net)

repository: harveytriana/BlazorGamePractice

repo_name: harveytriana/BlazorGamePractice


text:
# OpenHKGov
Hello, glad to have you on board, Welcome to to OpenHKGov.

As we all know, it is not easy to use the data "published" by the Hong Kong Government. One of the reasons is that they did not include a useful format for data analysis task. To solve this issue, we are trying to build a a open-source Python Library to make data extraction easier for everyone, or at least someone with basic Python programming skills.

# What you can do?

We are at an very early stage of programming, in fact, I just came up with this idea, create a repo, right after an indoor futsal game. Please feel free to leave your feedback, comments or suggestions for us - and that include how to write a better README file (Spoiler alert: I am a beginner developer)

Thanks again for your interest in this project, looking forward to see you soon. Happy coding.

repository: edwardmfho/OpenHKGov

repo_name: edwardmfho/OpenHKGov


text:
# FaceRecognizer-VGG16
There are some of good pre-trained models available over Internet created by some good students, I used VGG16 model for my face recognizer by which anyone can easily detect any persons face just  have to give dataset of images as per need of user. This can be used to Attendance System or CCTV face detection algorithms and many more just feel free to fork this repository to use as per your need.

# Setting Up Environment, Follow this:
```
conda create env -f --name MLOpsRG install numpy python3.7 keras tensorflow==2.0
conda activate MLOpsRG
```

# Make your Own Dataset by using:
[Create your own Dataset](https://github.com/rohitg00/FaceRecognizer-VGG16/blob/master/CreateYourOwnDataset.ipynb)

# Use this file to run the recognizer:
[Face REcognizer](https://github.com/rohitg00/FaceRecognizer-VGG16/blob/master/FaceRecognizer_VGG16.ipynb)

# Output:
![Output for Initial Code](https://github.com/rohitg00/FaceRecognizer-VGG16/blob/master/output.PNG)
![Output for Final Code of FaceRecognixer](https://github.com/rohitg00/FaceRecognizer-VGG16/blob/master/Output2.PNG)

# Author
[Rohit Ghumare](https://github.com/rohitg00/)

# MIT License
[MIT](https://github.com/rohitg00/FaceRecognizer-VGG16/blob/master/LICENSE)


text:
## Day 6 Notes

```
“You can't expect to hit the jackpot if you don't put a few nickels in the machine.”

- Flip Wilson
```

### Accepting Parameters in a Closure

#9 - `strawberry` and `raspberry` should be strings.

### Trailing Closure Syntax

#4 - The `activities` parameter can have an external name, since it's a parameter of a function, not a closure.

### 💡 New Concepts:

- Parameters to closures don't have external names, and **must have a type specified**.

url: https://raw.githubusercontent.com/bruce-wmm/HwS/13f5fc89b1aee2a36b504e2cc8a3deaf9735c18b/01. 100 Days of Swift/00. Swift Fundamentals/006. Closures (Part 1)/README.md

repository: bruce-wmm/HwS

repo_name: bruce-wmm/HwS


text:
# level-fix-range

make reverse ranges easier to use.

## Stability

Stable: Expect patches, possible features additions.

## Example

When you use reverse ranges, you have to reverse the `start` and `end` also,

``` js
db.createReadStream({start: 'a', end: 'z'})
db.createReadStream({start: 'z', end: 'a', reverse: true})
```

this is confusing and bug-ridden.

level-fix-range fixes the options so they always make sense.
if you want a range to reverse, just set reverse.

``` js
var fix = require('level-fix-range')
db.createReadStream({start: 'a', end: 'z'})
db.createReadStream(fix({start: 'a', end: 'z', reverse: true}))
```

When you either `start` _OR_ `end`, and the order is `reversed: true`,
it will also reverse the range,
so that:

``` js
{start: X, end: null} //from X to end of database
{start: null, end: X} //from start of database to X
```
and you will get the some data, whether you have reverse=true|false,
but only the order will change.

## License

MIT

gha_language: JavaScript


text:
# This library is currently in early access

# Backtrace Log4j2 support
[Backtrace](http://backtrace.io/) provides support for log4j2 by providing a special appender that can be connected to any application to send logged information also to the Backtrace dashboard. BacktraceAppender sends also MDC properties and using offline database for error report storage and re-submission in case of network outage.

# Installation via Gradle or Maven

* Gradle
```
dependencies {
    implementation 'com.github.backtrace-labs.backtrace-log4j2:backtrace-log4j2:0.9.0'
}
```

* Maven
```
<dependency>
  <groupId>com.github.backtrace-labs.backtrace-log4j2</groupId>
  <artifactId>backtrace-log4j2</artifactId>
  <version>0.9.0</version>
</dependency>
```

# Configuration

In order to configure the BacktraceAppender, it is mandatory to set the `submissionUrl` parameter or two parameters such as `endpointUrl` and `submissionToken`. Other parameters are optional.

### Example basic configuration using the log4j.properties
```
<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN" packages="backtrace.io.log4j2">
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout pattern="%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n" />
        </Console>
        <BacktraceAppender name="BacktraceAppender" endpointUrl="https://<yourInstance>.sp.backtrace.io:6098/" submissionToken="<submissionToken>"/>
    </Appenders>
    <Loggers>
        <Logger name="backtrace.io" level="off" additivity="false"/>
        <Root level="debug">
            <AppenderRef ref="Console" />
            <AppenderRef ref="BacktraceAppender"/>
        </Root>
    </Loggers>
</Configuration>
```

### Optional parameters:
- `appVersion` - string value which represents your's application version
- `appName` - string value which represents your's application name
- `enableUncaughtExceptionHandler` - boolean value, if `true` library will catch all uncaught exceptions and send to server
- `useDatabase` - boolean value, default `true` (also if this parameter is not specified) the library will store unsent messages in files, if `false` library will not be using any files to store reports
- `maxDatabaseSize` - long value, maximum database size in bytes, by default size is unlimited
- `maxDatabaseRecordCount` - integer value, number of times library will try to send the error report again if sending will finished with fail
- `maxDatabaseRetryLimit` - integer value, maximum number of messages in database. If a limit is set, the oldest error reports will be deleted if there will be try to exceed the limit

# Waiting
By default Backtrace is sending all messages asynchronously and doesn't block main thread. You can wait until all currently messages will be sent with executing method `await`. Optionally as a parameter to `await` method you can pass the maximum time you want to wait for that.

```java
Logger rootLogger = (Logger) LogManager.getRootLogger();
Appender backtraceAppender = (Appender) rootLogger.getAppenders().get("BacktraceAppender");
backtraceAppender.await();
```

# Closing
To make sure that all resources allocated by the library are released, call the `close` method. This method will send the currently processed message and then free all resources. Below you can find example how to do it.

```java
Logger rootLogger = (Logger) LogManager.getRootLogger();
Appender backtraceAppender = (Appender) rootLogger.getAppenders().get("BacktraceAppender");
backtraceAppender.stop();
```

# Debugging library
If you want to disable all logs which comes from this library add to log4j.properties file following line.

```xml
<Logger name="backtrace.io" level="off" additivity="false"/>
```

You can also set the level with which you want to receive logs from this library, eg. ERROR, INFORM or DEBUG.
```xml
<Logger name="backtrace.io" level="error" additivity="true"/>
```


text:
This repository contains different variants of the Blackbox framework 1.7.2 used to test my [Oberon+](https://github.com/rochus-keller/Oberon/blob/master/documentation/The_Programming_Language_Oberon%2B.adoc) parser and validator.

I downloaded Blackbox from the original sites and run *odcread* (see [this post](https://community.blackboxframework.org/viewtopic.php?f=32&t=272&p=1760&hilit=odcread#p1760)) on each Mod/*.odc file to create the corresponding source code text file.

Then I removed some subsystems and transpiled the source code to Oberon+ using my [OberonViewer 0.8.4](https://github.com/rochus-keller/Oberon#code-browser-features). The resulting code needed still some manual modifications.

See in the sub-folders for more information.

The original Blackbox framework source files are licensed under a BSD 2-clause license (see file License.txt).

Here is a screenshot of the current state of the Oberon+ IDE with the Windows Blackbox framework loaded:

![Oberon+ IDE Screenshot](http://software.rochus-keller.info/screenshot_obx_ide_0.3.png)

The ~96 kLOC (physical code lines, no whitespace or comment only lines) require less than two seconds to parse and validate on my HP EliteBook 2530p. See https://github.com/rochus-keller/Oberon for more information.

repository: ProgrammerMohr/BlackboxFramework

repo_name: ProgrammerMohr/BlackboxFramework


text:
# acm

!SLIDE dark

# Platform as a Service

### John Wetherill

!SLIDE left

# Background

* CloudScaling OCS
* Webinar
* OpenStack Horizon and Nova
* Command-line

!SLIDE left

# Starting Point

* Two node cluster
* DEA template on OCS

!SLIDE options-classes-loading left

![alt](images/screenshot1.png)

license: Unlicense

repository: bcferrycoder/acm-paas

repo_name: bcferrycoder/acm-paas


text:
# 3.1.4 - Use Typedoc Tags

Priority | ID | Category | Criteria | Impacts
---------|----|----------|----------|--------
Minor | [3.1.4][3.1.4] | Documentation | Docblocks must use Typedoc tags. | [Adoption][ADOPTION], [Contributions][CONTRIBUTIONS], [Project Maintenance][PROJECT-MAINTENANCE]

Table of Contents:

- [Description](#description)
- [Discussion](#discussion)
  - [Why Docblocks?](#why-docblocks)
  - [Why Typedoc?](#why-typedoc)
- [Examples](#examples)

## Description

Docblocks must use Typedoc tags.

**We've adopted Typedoc as our auto-doc generator**.

We need to use the following Typedoc tags in our documentation:

* `{@link}` makes it easier for readers to navigate from one exported type, function or method to other, related items.
* `@category` makes it easier for readers to find and see related items in one place.
* `@internal` makes sure that Typedoc doesn't clutter up the generated docs with items that aren't part of our public API.
* `@param` means that readers don't have to dig into our source code to work out what a function or method's parameter is meant to be.
* `@return` or `@returns` (both work) also means that readers don't have to dig into our source code to work out what a function or method is sending back to the caller.
* `@template` helps to demystify any generic types we use.

## Discussion

### Why Docblocks?

Good documentation is important. It helps people to start using our code in the first place, and to use it with limited friction. It also helps people contribute new features to our existing code.

Unfortunately, most people simply do not have time to create hand-written / manually-maintained documentation. It can easily add 20-30% on top of the time it takes to write thoroughly-tested code. So a compromise is necessary.

We need to use a tool that can automatically generate documentation from our code and docblocks together.

We are assuming that the auto-generated docs could be the only documentation available to end-users and contributors alike.

### Why Typedoc?

Honestly, right now, all the available doc tools for Typescript fall a bit short.

We have to pick one, and for better or worse, we're going with Typedoc for now.

* It's very easy to use.
* It uses a minimal number of doctags. That should reduce the amount of work we have to do in the future to migrate to a better tool if/when one comes along.
* The docs it generates are just-about good enough to use as reference docs.
* It does have issues with a couple of Typescript features that we use heavily:
  * functions assigned to constants
  * deconstructed objects

We're keeping an eye on the [@microsoft/tsdoc](https://github.com/microsoft/tsdoc) initiative (which the Typedoc authors are contributing to). As it stabilises and tools adopt it, we'll revisit this.

## Examples

This example shows how a docblock should look.

```typescript
/**
 * `Value` describes the behaviour of data that does have a value,
 * but does not have an identity (a primary key).
 *
 * It is useful for ensuring all value objects have a *minimal* set
 * of common behaviour, whether or not they share a common base class.
 *
 * Use {@link Entity} for data that does have an identity.
 *
 * @category Archetypes
 * @template T the type that is wrapped
 */
export interface Value<T> {
    /**
     * `implementsValue()` is a type-guard.
     *
     * It was added to help the `isValue()` type guard function.
     */
    implementsValue(): this is Value<T>;

    /**
     * `valueOf()` returns the wrapped value.
     *
     * For types passed by reference, we do NOT return a clone of any kind.
     * You have to be careful not to accidentally change this value.
     *
     * @returns the wrapped value
     */
    valueOf(): T;
}
```

[ADOPTION]: ../../impacted-areas/ADOPTION.md
[CONTRIBUTIONS]: ../../impacted-areas/CONTRIBUTIONS.md
[CORRECTNESS]: ../../impacted-areas/CORRECTNESS.md
[GOVERNANCE]: ../../impacted-areas/GOVERNANCE.md
[PROJECT-MAINTENANCE]: ../../impacted-areas/PROJECT-MAINTENANCE.md
[ROBUSTNESS]: ../../impacted-areas/ROBUSTNESS.md
[SECURITY]: ../../impacted-areas/SECURITY.md
[TESTABILITY]: ../../impacted-areas/TESTABILITY.md
[3.1.4]: ./3.1.4.md

repository: SafelyTyped/ts-coding-standards

repo_name: SafelyTyped/ts-coding-standards


text:
# Version Control demo

This demo will walk you through the basics of using `git` and the GitHub platform. It assumes that you already have `git` [installed](https://git-scm.com/) and that you have [ssh access to GitHub](https://help.github.com/en/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) setup.

## Cloning the repository

First we will clone the newly created repository. If you navigate to the GitHub repository page, [`https://github.com/dlej/d2k-git-demo`](https://github.com/dlej/d2k-git-demo), you will find a button to clone:

![](images/clone_ssh.png)

Then in a terminal, we can clone the repository using this address `git clone`, and we will have a copy of the repository with  the files `LICENSE` and `README.md` on our local machine.

```
$ git clone git@github.com:dlej/d2k-git-demo.git
Cloning into 'd2k-git-demo'...
Warning: Permanently added the RSA host key for IP address '<IP_ADDRESS>' to the list of known hosts.
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0
Receiving objects: 100% (4/4), done.
Checking connectivity... done.

$ ls
d2k-git-demo/

$ cd d2k-git-demo/

$ ls
LICENSE  README.md
```

## Pushing code to GitHub

Let's suppose we create two new files called `mylibrary.py` (view [here](https://github.com/dlej/d2k-git-demo/blob/eeeb7f94c15227406f5572a8f9070890f2cc5d7e/mylibrary.py)) and `experiment1.py` (view [here](https://github.com/dlej/d2k-git-demo/blob/eeeb7f94c15227406f5572a8f9070890f2cc5d7e/experiment1.py)) that allow us to run an experiment. Our experiment gives the following output:

```
$ python experiment1.py
hello world! how are you?
```

Since our experiment works as we expect, we'd like to add the new code to GitHub. To do this, we first commit our changes to the local repository, then push what we have committed to the local repository to the remote repository at `github.com`.
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   experiment1.py
        new file:   mylibrary.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        __pycache__/

```

Once we have all of our changes staged, we create our commit with `git commit`, providing along with the commit a message indicating the nature of the change:

```
$ git commit -m "hello world experiment"
[master eeeb7f9] hello world experiment
 2 files changed, 17 insertions(+)
 create mode 100644 experiment1.py
 create mode 100644 mylibrary.py
```

Every commit has a checksum that can be used to identify the commit. For this commit, the `eeeb7f9` are the first 7 digits of the checksum. Once we have created our local commit, we can push our changes to GitHub:

```
$ git push
Warning: Permanently added the RSA host key for IP address '<IP_ADDRESS>' to the list of known hosts.
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 583 bytes | 0 bytes/s, done.
Total 4 (delta 0), reused 0 (delta 0)
To git@github.com:dlej/d2k-git-demo.git
   1c715c4..eeeb7f9  master -> master
```

Now our repository at `github.com` contains the same code as checked in to commit `eeeb7f9` on our local machine.

## Branching and merging

A good practice, especially when you have multiple collaborators working on a code base simultaneously, is to do work locally on new branches rather than the `master` branch. This makes it much easier to resolve conflicts when the same file is being edited by multiple people at once.

### Branching

Suppose that Alice decides that she wants to write a new experiment. She can create a new branch starting from the current commit on master using `git checkout -b`:

```
$ git checkout -b experiment2
Switched to a new branch 'experiment2'
```

This branch only exists on Alice's local machine, however, so she has create the branch on the remote repository.

```
$ git push origin experiment2
Total 0 (delta 0), reused 0 (delta 0)
remote:
remote: Create a pull request for 'experiment2' on GitHub by visiting:
remote:      https://github.com/dlej/d2k-git-demo/pull/new/experiment2
remote:
To git@github.com:dlej/d2k-git-demo.git
 * [new branch]      experiment2 -> experiment2
```

At the same time, Bob comes a long to the repository and thinks it needs some tidying up, so he also creates a new branch to work:

```
$ git checkout -b tidying
Switched to a new branch 'tidying'

$ git push origin tidying
Total 0 (delta 0), reused 0 (delta 0)
remote:
remote: Create a pull request for 'tidying' on GitHub by visiting:
remote:      https://github.com/dlej/d2k-git-demo/pull/new/tidying
remote:
To git@github.com:dlej/d2k-git-demo.git
 * [new branch]      tidying -> tidying
```

### Merging

#### Command-line

Suppose that Bob finishes his changes first. He has made some tweaks to `mylibrary.py` and added `.gitignore` (view [here](https://github.com/dlej/d2k-git-demo/blob/3f9037e3097624a7ab1649d20e8a2e9fd681459e/.gitignore)) so that the `__pycache__` directory is ignored by `git`. He can view his changes to existing files such as `mylibrary.py` using `git diff`:

```
$ git diff
diff --git a/mylibrary.py b/mylibrary.py
index bc39ba8..bc94bd1 100644
--- a/mylibrary.py
+++ b/mylibrary.py
@@ -2,9 +2,9 @@ class HelloWorld(object):

     def __init__(self):

-        self.message = 'hello world!'
+        self.message = 'Hello, World!'

-    def say(self, extra_message=None):
+    def say_message(self, extra_message=None):

         if extra_message is None:
             return self.message
```

Bob then commits his changes:

```
$ git add .gitignore mylibrary.py

$ git status
On branch tidying
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   .gitignore
        modified:   mylibrary.py

$ git commit -m "Added .gitignore and fixed grammar."
[tidying 3f9037e] Added .gitignore and fixed grammar.
 2 files changed, 3 insertions(+), 2 deletions(-)
 create mode 100644 .gitignore
```

He then pushes the changes to the remote `tidying` branch created before. However, he has not pushed to this branch before, so he has to additionally provide the arguments `-u origin tidying` to set the destination of the push for this branch:

```
$ git push -u origin tidying
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (4/4), 398 bytes | 0 bytes/s, done.
Total 4 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To git@github.com:dlej/d2k-git-demo.git
   eeeb7f9..3f9037e  tidying -> tidying
Branch tidying set up to track remote branch tidying from origin.
```

Now it is time for him to merge his changes into the `master` branch using. First he will merge any changes on the master branch into the `tidying` branch using `git merge`, then merge the `tidying` branch into `master`. This way, if there are any conflicts in merging, he can resolve them on the working branch. Finally, he will push the new changes to the remote `master` branch.

```
$ git merge master
Already up-to-date.

$ git checkout master
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.

$ git merge tidying
Updating eeeb7f9..3f9037e
Fast-forward
 .gitignore   | 1 +
 mylibrary.py | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)
 create mode 100644 .gitignore

$ git push
Total 0 (delta 0), reused 0 (delta 0)
To git@github.com:dlej/d2k-git-demo.git
   eeeb7f9..3f9037e  master -> master
```

#### Pull requests

Alice has finally finished her work, which consists of some tweaks to `mylibrary.py` and a new `experiment2.py` (view [here](https://github.com/dlej/d2k-git-demo/blob/f924cef164cb02a9a9e3942a293aadcba6e3945c/experiment2.py)). The new experiment generates some Fibonacci numbers:

```
$ python experiment2.py
1 1 2 3 5 8 13 21 34 55
```

Alice did not end up needing the changes she made to `mylibrary.py`, but she will commit them anyway.

```
$ git add experiment2.py mylibrary.py

$ git status
On branch experiment2
Changes to be committed:
  (use "git reset HEAD <file>..." to unstage)

        new file:   experiment2.py
        modified:   mylibrary.py

Untracked files:
  (use "git add <file>..." to include in what will be committed)

        __pycache__/

$ git commit -m "added experiment 2 and updated mylibrary"
[experiment2 f924cef] added experiment 2 and updated mylibrary
 2 files changed, 11 insertions(+), 2 deletions(-)
 create mode 100644 experiment2.py

$ git push -u origin experiment2
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 539 bytes | 0 bytes/s, done.
Total 4 (delta 1), reused 0 (delta 0)
remote: Resolving deltas: 100% (1/1), completed with 1 local object.
To git@github.com:dlej/d2k-git-demo.git
   eeeb7f9..f924cef  experiment2 -> experiment2
Branch experiment2 set up to track remote branch experiment2 from origin.
```

Now that she has pushed her commit to the remote branch, she can create a pull requeston GitHub, which is a request to merge her branch into the `master` branch.

![](images/pull_request_create.png)

However, because both Alice and Bob edited the same part of `mylibrary.py`, git is unable to automatically merge the two commits. So, Alice can resolve the merge conflict manually.

![](images/pull_request_must_resolve.png)

Alice will use the online editor to perform the conflict resolution:

![](images/pull_request_resolve_before.png)

There she sees that Bob's change was to fix the capitalization and punctuation of `'hello world!'`. She resolves the conflict by keeping `self.message = message` from her branch but updating the default parameter setting to `message='Hello, World!'` like Bob wanted.

![](images/pull_request_resolve_after.png)

Then she can mark the conflict as resolved and commit the changes. Lastly, she can merge the pull request to bring the changes into the `master` branch.

![](images/pull_request_merge.png)

To get the changes locally, Alice will have to update her local copy of the `master` branch with `git pull`:

```
$ git checkout master
Switched to branch 'master'
Your branch is behind 'origin/master' by 3 commits, and can be fast-forwarded.
  (use "git pull" to update your local branch)

$ git pull
Updating 3f9037e..1fb3f83
Fast-forward
 experiment2.py | 9 +++++++++
 mylibrary.py   | 4 ++--
 2 files changed, 11 insertions(+), 2 deletions(-)
 create mode 100644 experiment2.py
```

## Reproducing experiments

Alice now wants to go back and run `experiment1.py` again, so she tries to run it.

```
$ python experiment1.py
Traceback (most recent call last):
  File "experiment1.py", line 5, in <module>
    print(helloworld.say('how are you?'))
AttributeError: 'HelloWorld' object has no attribute 'say'
```

Oh no! Something went wrong. Turns out, when Bob made his changes, he changed something in `mylibrary.py` that broke `experiment1.py`. But Alice can still run this experiment if she rolls back the code base to what it was when she created the experiment originally by checking out commit `eeeb7f9`.

```
$ git checkout eeeb7f9
M       README.md
Note: checking out 'eeeb7f9'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at eeeb7f9... hello world experiment

$ python experiment1.py
hello world! how are you?
```

This works exactly as it did originally. Alice can return to the normal `master` branch simply by checking out `master`.

```
$ git checkout master
M       README.md
Previous HEAD position was eeeb7f9... hello world experiment
Switched to branch 'master'
Your branch is up-to-date with 'origin/master'.
```


text:
---
title: Seventh Day Adventist Hymnal - 401-410
metadata:
    description: |
      Seventh Day Adventist Hymnal - 401-410
    keywords: |
      Seventh Day Adventist Hymnal, adventhymnals, advent hymnals 401-410
    author: Brian Onang'o
---

#### Advent Hymnals
## Seventh Day Adventist Hymnal - 401-410

# Index of Titles
# | Title
-- |-------------
401|[In Imitation, Lord of Thee](/seventh-day-adventist-hymnal/401-500/401-410/In-Imitation,-Lord-of-Thee)
402|[By Christ Redeemed](/seventh-day-adventist-hymnal/401-500/401-410/By-Christ-Redeemed)
403|[Let Us Break Bread Together](/seventh-day-adventist-hymnal/401-500/401-410/Let-Us-Break-Bread-Together)
404|[Now Let Us From This Table Rise](/seventh-day-adventist-hymnal/401-500/401-410/Now-Let-Us-From-This-Table-Rise)
405|[O God, Unseen, Yet Ever Near](/seventh-day-adventist-hymnal/401-500/401-410/O-God,-Unseen,-Yet-Ever-Near)
406|[Love Consecrates the Humblest Act](/seventh-day-adventist-hymnal/401-500/401-410/Love-Consecrates-the-Humblest-Act)
407|[Sent Forth by God\`s Blessing](/seventh-day-adventist-hymnal/401-500/401-410/Sent-Forth-by-God`s-Blessing)
408|[Lord, Enthroned in Heavenly Splendor](/seventh-day-adventist-hymnal/401-500/401-410/Lord,-Enthroned-in-Heavenly-Splendor)
409|[Jesus Invites His Saints](/seventh-day-adventist-hymnal/401-500/401-410/Jesus-Invites-His-Saints)
410|[Thy Broken Body, Gracious Lord](/seventh-day-adventist-hymnal/401-500/401-410/Thy-Broken-Body,-Gracious-Lord)

repository: GospelSounders/adventhymnals

repo_name: GospelSounders/adventhymnals


text:
# Docker secret updater

As docker doesn't have a docker secret update command, here is a bash script for updating secrets without stopping any service.

# HOW IT WORKS? 🔩

The script will create a new "second" secret and update the desire service with the new "second" secret. Doing this way you will be able to manage your main secret without stopping the service. Then the script will create your main secret with the new env.file and update the desire service with it.

# USAGE 🖥

You can run the script without arguments for checking the usage.

./DockerSecret_updater. sh <env.file> <secret_name> <service_name>

repository: sergioarroyop/Docker-secret-updater

repo_name: sergioarroyop/Docker-secret-updater


text:
---
date: '2018-05-09'
layout: rafaga
rafagas:
- desc: USA diversity is growing, but still population segregation by neighborhoods
    exists by a range of factors
  keyw: minorities
  link: https://www.washingtonpost.com/graphics/2018/national/segregation-us-cities/
  microlink: {}
- desc: 'Lived spaces map tool; mapping two types of distances: geographical and travel
    time journeys'
  keyw: distances
  link: https://github.com/aourednik/georecits
  microlink:
    desc: An application for mapping journeys and lived spaces in a web browser -
      aourednik/georecits
    image: https://avatars3.githubusercontent.com/u/7204421?s=400&v=4
    logo: https://github.githubassets.com/favicon.ico
    title: aourednik/georecits
- desc: Old style map of Bellingham breweries and near bike shops using city Open
    Data
  keyw: beers
  link: https://petrichor.studio/2018/04/04/happy-national-beer-day-bellingham-bike-shops-breweries-map/
  microlink:
    desc: It’s National Beer Day this Saturday, April 7th! I’m celebrating by posting
      this Bicycle to Breweries Map of Bellingham, my home city.
    image: https://petrichor.studio/wp-content/uploads/2018/04/BhamBeerMap_Smallest.png
    logo: https://www.petrichor.studio/wp-content/uploads/2018/01/cropped-favicon-1-192x192.jpg
    title: 'NCAA Basketball: Who’s Come the Farthest?Fantasy Mapping: Place Names
      & Design (and free Adobe map assets!)'
  nocheck: true
- desc: A three meters ribbon mapping the full Mississippi river, rolled inside a
    spool, used by steamboat river tourists around 1860
  keyw: mississippi
  link: https://www.atlasobscura.com/articles/mississippi-river-ribbon-map
  microlink:
    desc: Steamboat tourists of the late 1860s wrapped it around a spool.
    image: https://assets.atlasobscura.com/media/W1siZiIsInVwbG9hZHMvYXNzZXRzLzFjNjZlZDliMTVlMGQ2MDEwMV80OTk1MDAwLmpwZyJdLFsicCIsImNvbnZlcnQiLCIiXSxbInAiLCJjb252ZXJ0IiwiLXF1YWxpdHkgODEgLWF1dG8tb3JpZW50Il0sWyJwIiwidGh1bWIiLCI2MDB4PiJdXQ/4995000.jpg
    logo: https://assets.atlasobscura.com/media/W1siZnUiLCJodHRwczovL3MzLmFtYXpvbmF3cy5jb20vYXRsYXMtZGV2L21pc2MvaWNvbnMvYXBwbGUtdG91Y2gtaWNvbi5wbmciXSxbInAiLCJjb252ZXJ0IiwiLXF1YWxpdHkgODEgLXN0cmlwIl1d/apple-touch-icon.png
    title: This 11-Foot ‘Ribbon Map’ Puts the Whole Mississippi River in Your Pocket
rid: 865
---

repository: geoinquiets/rafagas

branch_name: refs/heads/gh-pages

gha_language: SCSS

gha_license_id: NOASSERTION

repo_name: geoinquiets/rafagas


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

### Description

mpg321.c in mpg321 0.3.2-1 does not properly manage memory for use with libmad 0.15.1b, which allows remote attackers to cause a denial of service (memory corruption seen in a crash in the mad_decoder_run function in decoder.c in libmad) via a crafted MP3 file.

### POC

#### Reference
- http://seclists.org/fulldisclosure/2017/Jul/94
- https://www.exploit-db.com/exploits/42409/

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

repository: trickest/cve

repo_name: trickest/cve


text:
---
date: 2022-02-03
title: 'Understanding docker compose for building microservices'
shortTitle: 'Understanding docker compose for building microservices'
description: 'Understanding docker compose for building microservices'
template: post
featuredImage: '../thumbnails/docker.png'
thumbnail: '../thumbnails/docker.png'
slug: understanding-docker-compose-for-building-services
categories:
  - docker
  - microservice
  - aws
tags:
  - nodejs
  - docker
  - microservice
---

## “What, Why, How” Docker Compose?

we’ve discussed how we can turn docker containers into development machines in my ealier posts. In this post, we’ll talk about how we will grip the strengths of docker containers to run a multi-container application. Let’s dive into the process.

# What is docker Compose? Why docker Compose?

Docker compose is a simple yet powerful tool that is used to run multiple containers as a single service.* For example*, suppose you have an application which requires Nginx as a web server and PostgreSQL as a database service. In this case by docker-compose, you can create one single file (docker-compose.yml ) which will create both the containers as a single service without starting each separately

Docker Compose is used to run multiple containers as a single service. For example, suppose you had an application which required NGNIX and MySQL, you could create one file which would start both the containers as a service without the need to start each one separately.

How Docker Compose Works?

1. use yaml files to configure application services (docker-compose.yaml)

2. can start all the services with a single command ( docker-compose up )

3. can stop all the service with a single command ( docker-compose down )

4. able to scale up the specific services when required.

5. works in all environments: production, staging, development, testing, as well as CI workflows

Step 1 || Install Docker Compose

Run below command from your Linux terminal to install docker-compose:

    $ pip install -U docker-compose

    # check version:
    $ docker-compose -v

    Note: docker-compose mostly comes along while installing docker in both Mac and windows.

Step 2 || Create Docker Compose file

Now, create a docker compose file at any location on your system named docker-compose.yml and add below content to that yaml file.

    services:

      web:
        image: nginx         # webserver for our web application
      database:
        image: postgres     # postgresql is used as database

you can select more from [https://hub.docker.com/search?q=&type=image](https://hub.docker.com/search?q=&type=image)

Step 3 || Check the validity of file by command

check the validity of the yaml file by running:

    $ docker-compose config

    output: ERROR: The Compose file './docker-compose.yml' is invalid because:Unsupported config option for services: 'web'result:

To resolve the error you must add a version on top of the file matched with your docker-compose version. check all version compatibility here: [https://docs.docker.com/compose/compose-file/](https://docs.docker.com/compose/compose-file/)

so our updated file will look like:

    version: "3"
    services:

      web:
        image: nginx
      database:
        image: postgres

Step 4|| Run docker-compose.yml file

Now, run following command to run your docker-compose file:

    $ docker-compose up -d         # -d or --detach means detached mode
> detached mode (-d, --detach) : Detached mode shown by -d or — detach means a docker container is running in the background of your terminal. It doesn’t receive input or display any output .

When the process will be done you will see something like this at the very end of your terminal:

    Creating dockercomposefile_web_1      ... done
    Creating dockercomposefile_database_1 ... done

Step 5 || Verify running containers

Now verify whether your containers are running or not by:

    $ docker ps           # or you can run docker-compose ps

you will see something like this:

![](https://cdn-images-1.medium.com/max/2482/1*tvhTUwfPo9mKaCktqqJ7rQ.png)

Hooa! your containers are successfully running!

Step 6 || expose nginx in a specific port

In our yaml file we’ve just used minimum code to run the service. Now if we want to add more, like we want to expose nginx in a specif port we can do it by adding below content to the yaml file:

    ports:
      - "6080:80"

    # It means expose the port 80(default port of nginx) of the web server and expose it to the 6080 port of host machine.

Now our file will look like:

    version: "3"
    services:

      web:
        image: nginx
        ports:
          - "6080:80"
      database:
        image: postgres

Run docker ps again and see the changes!

![](https://cdn-images-1.medium.com/max/2524/1*LEjPlf0hzt0YU199KHLpmQ.png)

Now go to [http://localhost:6080/](http://localhost:6080/) of your host machine, you will see nginx is running!

Step 7|| Bring down the application

To stop the running containers run below command:

    $ docker-compose down      # all containers will be stopped

    # verify whether the containers are stopped or not
    $ docker ps

Scaling up the service

Suppose you need to scale up your database and need four instances of the database instead of one. you can scale up the service running below command:

    $ docker-compose -d --scale database=4

    # Will start the container and create four instances of database service

Verify whether the instances have been created or not by:

    $ docker ps

you can see we have one nginx server running and four database services are running:

![4 instances of the database have been created](https://cdn-images-1.medium.com/max/2622/1*7b8SRI0w92Af-nXXIpau7Q.png)*4 instances of the database have been created*

Now stop the containers running docker-compose down

Oh Great! By now, you are done with the basic of docker-compose .

example of docker-compose for nodejs and mysql application

entrypoint script to initialize container data at runtime

```sh
set -e

npm install
npm run build

if [ "${1#-}" != "${1}" ] || [ -z "$(command -v "${1}")" ]; then
  set -- node "$@"
fi

exec "$@"
```

```yaml

version: "3"

services:
    node:
        build: .
        command: npm run debug
        ports:
            - 3000:3000
        volumes:
            - ./:/server
            - ./docker/node/node-docker-entrypoint.sh:/usr/local/bin/docker-entrypoint.sh
        depends_on:
            - mysql
    mysql:
        image: mysql:5.7
        ports:
            - 3306:3306
        volumes:
            - db-data:/var/lib/mysql
        environment:
            MYSQL_ROOT_PASSWORD: test
            MYSQL_DATABASE: test
            MYSQL_USER: test
            MYSQL_PASSWORD: test
volumes:
    db-data: {}
```

## Lets explore one more example and look into every components

A sample file could look like this:
```yaml
version: '3.3'

services:
   db:
     image: mysql:5.7
     volumes:
       - db_data:/var/lib/mysql
     restart: always
     environment:
       MYSQL_ROOT_PASSWORD: somewordpress
       MYSQL_DATABASE: wordpress
       MYSQL_USER: wordpress
       MYSQL_PASSWORD: wordpress

   wordpress:
     depends_on:
       - db
     image: wordpress:latest
     ports:
       - "8000:80"
     restart: always
     environment:
       WORDPRESS_DB_HOST: db:3306
       WORDPRESS_DB_USER: wordpress
       WORDPRESS_DB_PASSWORD: wordpress
       WORDPRESS_DB_NAME: wordpress
volumes:
    db_data: {}
```

As you can see this file contains a whole Wordpress application including the MySQL database. Each of these services is treated as a separate container that can be swapped in and out when you need it.

Now that we know the basic structure of a Compose file let's continue by looking at the important concepts.

Concepts / Keywords
------------------
The core aspects of the Compose file are its concepts which allow it to manage and create a network of containers. In this section, we will explore these concepts in detail and take a look at how we can use them to customize our Compose configuration.

Services:
---------
The services tag contains all the containers which are included in the Compose file and acts as their parent tag.

```yaml
services:
  proxy:
    build: ./proxy
  app:
    build: ./app
  db:
    image: postgres
```
Here you can see that the services tag contains all the containers of the Compose configuration.

Base image (Build):
-------------------
The base image of a container can be defined by either using a preexisting image that is available on DockerHub or by building images using a Dockerfile.

Here are some basic examples:
```yaml
version: '3.3'

services:
    alpine:
        image: alpine:latest
        stdin_open: true
        tty: true
        command: sh
```
Here we use a predefined image from DockerHub using the image tag.
```yaml
version: '3.3'
services:
    app:
        container_name: website
        restart: always
        build: .
        ports:
            - '3000:3000'
    command:
        - 'npm run start'
```
In this example, we define our images using the build tag which takes the destination of our Dockerfile as a parameter.

The last option of defining the base image is to use a Dockerfile with a custom name.
```yaml
build:
    context: ./dir
    dockerfile: Dockerfile.dev
Ports:
```
Exposing the ports in Compose works similarly as in the Dockerfile. We differentiate between two different methods of exposing the port:

Exposing the port to linked services:
```yaml
expose:
 - "3000"
 - "8000"
```
Here we publish the ports to the linked services of the container and not to the host system.

Exposing the port to the host system:

ports:
  - "8000:80"  # host:container
In this example, we define which port we want to expose and the host port it should be exposed to.

You can also define the port protocol which can either be UDP or TCP:
```yaml
ports:
  - "8000:80/udp"
```
Commands:
Commands are used to execute actions once the container is started and act as a replacement for the CMD action in your Dockerfile.

The CMD action is the first command that gets executed when the container is started and is therefore mostly used to start a process e.g. start your website through a CLI command like npm run start.
```yaml
app:
        container_name: website
        restart: always
        build: ./
        ports:
            - '3000:3000'
        command:
            - 'npm run start'
```
Here we create a service for a website and add the starting command using the command tag. This command will be executed after the container has started and will then start the website.

For more information about CMD, RUN, and Entrypoint you can read this article which discusses the details and compares their functionality.

Volumes:
-------
Volumes are Docker's preferred way of persisting data which is generated and used by Docker containers. They are completely managed by Docker and can be used to share data between containers and the Host system.

They do not increase the size of the containers using it, and their context is independent of the lifecycle of the given container.

Docker Volumes
------------
Src: https://docs.docker.com/storage/volumes/
There are multiple types of volumes you can use in Docker. They can all be defined using the volumes keyword but have some minor differences which we will talk about now.

Normal Volume:

The normal way to use volumes is by just defining a specific path and let the Engine create a volume for it. This can be done like this:
```yaml
volumes:
# Just specify a path and let the Engine create a volume
  - /var/lib/mysql
```
Path mapping:

You can also define absolute path mapping of your volumes by defining the path on the host system and mapping it to a container destination using the: operator.
```
volumes:
  - /opt/data:/var/lib/mysql
```
Here you define the path of the host system followed by the path of the container.

Named volume:
------------
Another type of volume is the named volume which is similar do the other volumes but has it's own specific name that makes it easier to use on multiple containers. That's why it's often used to share data between multiple containers and services.

volumes:
  - datavolume:/var/lib/mysql
Dependencies:
Dependencies in Docker are used to make sure that a specific service is available before the dependent container starts. This is often used if you have a service that can't be used without another one e.g. a CMS (Content Management System) without its database.
```yaml
   ghost:
        container_name: ghost
        restart: always
        image: ghost
        ports:
            - 2368:2368
        environment:
            - .
        depends_on: [db]
    db:
        image: mysql
        command: --default-authentication-plugin=mysql_native_password
        restart: always
        environment:
            MYSQL_ROOT_PASSWORD: example
```
Here we have a simple example of a Ghost CMS which depends on the MySQL database to work and therefore uses the depends_on command. The depends_on command takes an array of string which defines the container names the service depends on.

Environment variables:
---------------------
Environment variables are used to bring configuration data into your applications. This is often the case if you have some configurations that are dependent on the host operating system or some other variable things that can change.

There are many different options of passing environment variables in our Compose file which we will explore here:

You can set environment variables in a container using the "environment" keyword, just like with the normal docker container run --environment command in the shell.
```yaml
web:
  environment:
    - NODE_ENV=production
```
In this example, we set an environment variable by providing a key and the value for that key.

Passing an environment variable:

You can pass environment variables from your shell straight to a container by just defining an environment key in your Compose file and not giving it a value.
```yaml
web:
  environment:
    - NODE_ENV
```
Here the value of NODE_ENV is taken from the value from the same variable in the shell which runs the Compose file.

Using an .env file:

Sometimes a few environment variables aren't enough and managing them in the Compose file can get pretty messy. That is what .env files are for. They contain all the environment variables for your container and can be added using one line in your Compose file.
```yaml
web:
  env_file:
    - variables.env
```

Networking
----------
Networks define the communication rules between containers, and between containers and the host system. They can be configured to provide complete isolation for containers, which enables building applications that work together securely.

By default Compose sets up a single network for each container. Each container is automatically joining the default network which makes them reachable by both other containers on the network, and discoverable by the hostname defined in the Compose file.

Specify custom networks:
Instead of only using the default network you can also specify your own networks within the top-level networks key, allowing to create more complex topologies and specifying network drivers and options.
```yaml
networks:
  frontend:
  backend:
    driver: custom-driver
    driver_opts:
      foo: "1"
```
Each container can specify what networks to connect to with the service level "networks" keyword, which takes a list of names referencing entries of  the top-level "networks" keyword.
```yaml
services:
  proxy:
    build: ./proxy
    networks:
      - frontend
  app:
    build: ./app
    networks:
      - frontend
      - backend
  db:
    image: postgres
    networks:
      - backend
```
You can also provide a custom name to your network (since version 3.5):
```yaml
version: "3.5"
networks:
  webapp:
    name: website
    driver: website-driver
```
For a full list of the network configuration options, see the following references:

Top-level network key
Service-level network key
External (Pre-existing) networks:
You can use pre-existing networks with Docker Compose using the external option.
```yaml
networks:
  default:
    external:
      name: pre-existing-network
```
In this example, Docker never creates the default network and just uses the pre-existing network defined in the external tag.

Configure the default networks:
Instead of defining your own networks you could change the settings of the default network by defining an entry with the name default under the "networks" keyword.
```yaml
version: "3"
services:
  web:
    build: .
    ports:
      - "8000:8000"
  db:
    image: postgres

networks:
  default:
    driver: custom-driver
```

In this example, the web container can reach the database using one of the two hostnames (db or database).

CLI
All the functionality of Docker-Compose is executed through its build in CLI, which has a very similar set of commands to what is offered by Docker.

- build    Build or rebuild services
- help     Get help on a command
- kill     Kill containers
- logs     View output from containers
- port     Print the public port for a port binding
- ps       List containers
- pull     Pulls service images
- rm       Remove stopped containers
- run      Run a one-off command
- scale    Set number of containers for a service
- start    Start services
- stop     Stop services
- restart  Restart services
- up       Create and start containers
- down     Stops and removes containers

They are not only similar but also behave like their Docker counterparts. The only difference is that they affect the entire multi-container architecture which is defined in the docker-compose.yml file instead of a single container.

Some Docker commands are not available anymore and have been replaced with other commands that make more sense in the context of a completely multi-container setup.

The most important new commands include the following:
```bash
docker-compose up
docker-compose down
```
Using Multiple Docker Compose Files
The use of multiple Docker Compose files allows you to change your application for different environments (e.g. staging, dev, and production) and helps you run admin tasks or tests against your application.

Docker Compose reads two files by default, a docker-compose.yml file, and an optional docker-compose.override.yml file. The docker-compose.override file can be used to store overrides of the existing services or define new services.

To use multiple override files, or an override file with a different name, you can pass the -f option to the docker-compose up command. The base Compose file has to be passed on the first position of the command.
```bash
docker-compose up -f override.yml override2.yml
```
When you use multiple configuration files, you need to make sure that the paths are relative to the base Compose file which is specified first with the -f flag.

Now let's look at an example of what can be done using this technique.
```bash
# original service
npm run dev

# new service
npm run start
```
Here you override the old run command with the new one which starts your website in production instead of dev mode.

When you use multiple values on options like ports, expose, DNS and tmpfs, Docker Compose concatenates the values instead of overriding them which is shown in the following example.

```yaml
# original service
expose:
    - 3000

# new service
expose:
    - 8080
```
Compose in production
Docker Compose allows for easy deployment because you can deploy your whole configuration on a single server. If you want to scale your app, you can run it on a Swarm cluster.

There are still things you probably need to change before deploying your app configuration to production. These changes include:

Binding different ports to the host
Specifying a restart policy like restart: always to avoid downtime of your container
Adding extra services such as a logger
Removing any unneeded volume bindings for application code
After you have taken these steps you can deploy your changes using the following commands:
```bash
docker-compose build
docker-compose up --no-deps -d
```
This first rebuilds the images of the services defined in the compose file and then recreates the services.

Example
Now that we have gone through the theory of Compose let's see some of the magic we just talked about in action. For that, we are going to build a simple Node.js application with a Vue.js frontend which we will deploy using the tools we learned about earlier.

Let's get started by cloning the repository with the finished Todo list application so we can directly jump into the Docker part.

Lets explote this docker compose file

```yaml
services:
    nodejs:
        build:
            context: ./backend/
            dockerfile: Dockerfile
        container_name: nodejs
        restart: always
        environment:
            - HOST=mongo
        ports:
            - '3000:3000'
        depends_on: [mongo]
    mongo:
        container_name: mongo
        image: mongo
        ports:
            - '27017:27017'
        # volumes:
        #     - ./data:/data/db
    frontend:
        build:
            context: ./frontend/
            dockerfile: Dockerfile
        container_name: frontend
        restart: always
        ports:
            - '8080:8080'
```

This should give you a project with the following folder structure:

Folderstructure
Node-Vue Todo list folderstructure
Now that we have the project setup lets continue by writing our first Dockerfile for the Node.js backend.
```dockerfile
FROM node:latest

# Create app directory
WORKDIR /usr/src/app

# Install app dependencies
COPY package*.json ./

RUN npm install

# Bundle app source
COPY . .

EXPOSE 3000:3000
CMD [ "node", "server.js" ]
```
All right, let's understand what's going on here by walking through the code:

First, we define the base image using the FROM keyword
Then we set the directory we are going to work in and copy our local package.json file into the container
After that, we install the needed dependencies from the package.json file and expose the port 3000 to the host machine
The CMD keyword lets you define the command which will be executed after the container startup. In this case, we use it to start our express server using the node server.js command.
Now that we have finished the Dockerfile of the backend lets complete the same process for the frontend.
```dockerfile
FROM node:lts-alpine

RUN npm install -g http-server

WORKDIR /app

COPY package*.json ./
COPY .env ./

RUN npm install

COPY . .

RUN npm run build

EXPOSE 8080
CMD [ "http-server", "dist" ]
```
This file is similar to the last one but installs an HTTP server which displays the static site we get when building a Vue.js application. I will not go into further detail about this script because it isn't in the scope of this tutorial.

With the Dockerfiles in place, we can go ahead and write the docker-compose.yml file we learned so much about.

First, we define the version of our Compose file (in this case version 3)
```yaml
version: '3'
After that, we start defining the services we need for the project to work.

services:
    nodejs:
        build:
            context: ./backend/
            dockerfile: Dockerfile
        container_name: nodejs
        restart: always
        environment:
            - HOST=mongo
        ports:
            - '3000:3000'
        depends_on: [mongo]
```
The nodejs service uses the Dockerfile of the backend which we created above and publishes the port 3000 to the host machine. The service also depends on the mongo service which means that it lets the database start first before starting itself.

Next, we define a basic MongoDB service which uses the default image provided on DockerHub.
```yaml
     mongo:
        container_name: mongo
        image: mongo
        ports:
            - '27017:27017'
        volumes:
            - ./data:/data/db
```
This service also publishes a port to the host system and saves the data of the database in a local folder using a volume.

The last service we need to define is the frontend which uses the frontend Dockerfile to build the image and publishes port 8080 to the host system.
```yaml
    frontend:
        build:
            context: ./frontend/
            dockerfile: Dockerfile
        container_name: frontend
        restart: always
        ports:
            - '8080:8080'
```
That is it! We have finished our Docker files and can now move on to running the application. This is done using the following two commands:
```bash
# builds the images from the dockerfiles
docker-compose build

# starts the services defined in the docker-compose.yml file
# -d stands for detached
docker-compose up -d
```
As indicated by the terminal output, your services are now running and you are ready to visit the finished website on localhost:8080 which should look something like this:

docker-compose logs

This command will display all logs of the running containers and can help you debug your errors or check the current state of your application.

That is it for the project. The source code for the whole project can be found on my Github.

Conclusion
You made it all the way until the end! I hope that this article helped you understand the Docker Compose and how you can use it to improve your development and deployment workflow as a developer.

If you have found this useful, please consider recommending and sharing it with other fellow developers. If you have any questions or feedback, let me know in the comments down below.


text:
# Common module of Exasol Virtual Schemas Adapters 15.3.1, released 2022-01-05

Code name: Fixed incomplete logs

## Summary

In this released we fixed the [logging](https://docs.exasol.com/database_concepts/virtual_schema/logging.htm). Due to a bug log messages in the create-virtual-schema and get-capabilites calls where not logged.

## Bug Fixes

* #227: Fixed incomplete logs

## Dependency Updates

repository: exasol/virtual-schema-common-java

gha_language: Java

repo_name: exasol/virtual-schema-common-java


text:
# Interface: AdditionalData

[CdvPurchase](../modules/CdvPurchase.md).[Braintree](../modules/CdvPurchase.Braintree.md).AdditionalData

Data for a Braintree payment request.

## Table of contents

### Properties

- [dropInRequest](CdvPurchase.Braintree.AdditionalData.md#dropinrequest)

## Properties

### dropInRequest

• `Optional` **dropInRequest**: [`Request`](CdvPurchase.Braintree.DropIn.Request.md)

Specify the full DropIn Request parameters for full customization.

When set, this takes precedence over all other options.


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

### Description

There's a flaw in binutils /opcodes/tic4x-dis.c. An attacker who is able to submit a crafted input file to be processed by binutils could cause usage of uninitialized memory. The highest threat is to application availability with a lower threat to data confidentiality. This flaw affects binutils versions prior to 2.34.

### POC

#### Reference
No PoCs from references.

#### Github
- https://github.com/ARPSyndicate/cvemon
- https://github.com/Live-Hack-CVE/CVE-2020-35494


text:
# Docker Container by zihengCat

[![Build Status](https://travis-ci.com/zihengCat/docker-container-by-zihengcat.svg?branch=master)](https://travis-ci.com/zihengCat/docker-container-by-zihengcat)

Some `Dockerfile` projects written by zihengCat.

# `Dockerfile` Projects

- Docker - Fluent Bit

> https://github.com/fluent/fluent-bit

- Docker Apache Airflow

> https://github.com/apache/airflow

- Docker Apache Superset

> https://github.com/apache/incubator-superset

- Docker Apache Hadoop

> https://github.com/apache/hadoop

- Docker Cerebro

> https://github.com/lmenezes/cerebro

- Docker Cloudera Hue

> https://github.com/cloudera/hue

- Docker Elasticsearch

> https://github.com/elastic/elasticsearch

- Docker Kibana

> https://github.com/elastic/kibana

- Docker Jenkins

> https://github.com/jenkinsci/jenkins

- Docker Nginx

> https://github.com/nginx/nginx

- Docker MariaDB

> https://github.com/MariaDB/server

- Docker PostgreSQL

> https://github.com/postgres/postgres

- Docker Python

> https://github.com/python/cpython

- Docker Redis

> https://github.com/antirez/redis

- Docker Redis Commander

> https://github.com/joeferner/redis-commander

- Docker Redash

> https://github.com/getredash/redash

- Docker Odoo

> https://github.com/odoo/odoo

# License

[MIT](./LICENSE)

<!-- EOF -->

repository: zihengCat/docker-container-by-zihengcat

repo_name: zihengCat/docker-container-by-zihengcat


text:
My personal scratchpad / documents about hanabi.

### Links

* [hanabi live](https://hanabi.live/)
* [hanabi live conventions](https://github.com/Zamiell/hanabi-conventions)
* [two bots I wrote in python](https://github.com/fpvandoorn/hanabi)
* [start on a bot I contributed to in standard ML](https://github.com/fpvandoorn/hanabi-1)

repository: fpvandoorn/hanabi-scratchpad

repo_name: fpvandoorn/hanabi-scratchpad


text:
# Docker Image for rust

# Usage

Change directory to your project root.

Then you enter into docker image.

```
docker run -it --rm -v ${PWD}:/source idein/rust-stable
```

and following command works

```
cargo build
```

# License

MIT

repository: Idein/docker-rust-stable

repo_name: Idein/docker-rust-stable


text:
# [BanFromDiscord](https://github.com/pollovolante/BanFromDiscord)

banhammerbanhammerbanhammerbanhammerbanhammer

# Setup

Clone the repository with `git clone https://github.com/pollovolante/BanFromDiscord` or download and extract the zip file.

## Installation

**Note: You need [NodeJS](https://nodejs.org) installed on your system.**

Install dependencies by running `npm i` in your terminal.

## Discord Bot

You first need to create a Discord bot and then copy the bot token. Do so by following this guide [here](https://discordjs.guide/preparations/setting-up-a-bot-application.html).\
Duplicate [`.env.example`](https://github.com/pollovolante/BanFromDiscord/blob/main/src/.env.example) and rename it as `.env`. Not `.env.txt`, **just `.env`**.\
**Now put the bot token into `.env`.**\
If you want you can also change the bot prefix in the same file.

## Add Roblox Script

Replace **`ip`** with your backend server's IP address on line 17 of [`BanFromDiscord.lua`](https://github.com/pollovolante/BanFromDiscord/blob/main/BanFromDiscord.lua#L17).\
Then create a webhook into a log channel to receive info from the Roblox server and copy the webhook URL.
![Creating a webhook](https://www.minitool.com/images/uploads/news/2021/03/make-discord-webhooks-for-github/make-discord-webhooks-for-github-1.png)\
Now paste the webhook URL at line 16 of [`BanFromDiscord.lua`](https://github.com/pollovolante/BanFromDiscord/blob/main/BanFromDiscord.lua#L16).\
Finally, select everything and paste it into a script inside ServerScriptService.

## Running the backend server

Now you only have to start up the backend server and Discord bot.\
Run `npm start` in your terminal and that's it!\
Time to destroy players from Discord >:D

## Commands Usage

### Duration arguments
| Actual duration | Passed argument |
|-|-|
| 30 minutes | `30m` |
| 2 hours | `2h` |
| 10 days | `10d` |
| 3 weeks | `3w` |

### Commands

**`§temp` - Temporary Ban**\
Usage: `§temp robloxUsername banDuration reason`\
Example 2 day ban: `§temp polloarrosto01 2d using exploits`

**`§gameban` - Permanent Ban**\
Usage: `§gameban robloxUsername reason`\
Example permanent ban: `§gameban polloarrosto01 exploiting noob`

**`§unban` - Unban**\
Usage: `§unban robloxUsername reason`\
Example unban: `§unban polloarrosto01 because yes`

repository: SmidtDeveloping/BanFromDiscord

repo_name: SmidtDeveloping/BanFromDiscord


text:
This profile contains the following variations from [Encounter](http://hl7.org/fhir/STU3/encounter.html):

1. Zero or more <span style='color:green'> extension </span>  sliced
   * Exactly one Patient medication check undertaken extension
1. One or more participant(s)


text:
Cuckoo filters
--------------

[![Build Status](https://travis-ci.org/huydhn/cuckoo-filter.svg?branch=master)](https://travis-ci.org/huydhn/cuckoo-filter)
[![codecov.io](https://codecov.io/gh/huydhn/cuckoo-filter/master.svg)](http://codecov.io/gh/huydhn/cuckoo-filter?branch=master)

A Cuckoo filter is a data structure for probabilistic set-membership
queries with a low false positive probability (FPP). As an improvement
over the classic Bloom filter, items can be added or removed into
Cuckoo filters at will. A Cuckoo filter also utilizes space more
efficiently.

Cuckoo filters were originally described in:
 Fan, B., Andersen, D. G., Kaminsky, M., & Mitzenmacher, M. D. (2014, December).
 Cuckoo filter: Practically better than bloom.
 In Proceedings of the 10th ACM International on Conference on emerging Networking
 Experiments and Technologies (pp. 75-88). ACM.

This package implements the basic Cuckoo filter as well as several
derivations built on top of it.

Installation
------------

The package can be installed from
[PyPI](https://pypi.org/project/scalable-cuckoo-filter)

```
pip install scalable-cuckoo-filter
```

Classic Cuckoo filter
---------------------

```python
import math

from random import randrange
from cuckoo.filter import CuckooFilter

capacity = 1000000
error_rate = 0.000001
# Create a classic Cuckoo filter with a fixed capacity of 1000000
# buckets
cuckoo = CuckooFilter(capacity=capacity, error_rate=error_rate)

bucket_size = 6
# Setting the bucket size is optional, the bigger the bucket,
# the more number of items a filter can hold, and the longer
# the fingerprint needs to be to stay at the same error rate
cuckoo = CuckooFilter(capacity=capacity, error_rate=error_rate, bucket_size=bucket_size)

# The fingerprint length is computed using the following formula:
fingerprint_size = int(math.ceil(math.log(1.0 / error_rate, 2) + math.log(2 * bucket_size, 2)))

for _ in range(1, 100000):
    item = str(randrange(1,<PHONE_NUMBER>))
    cuckoo.insert(item)

    if cuckoo.contains(item):
        print '{} has been added'.format(item)

    cuckoo.delete(item)

    if not cuckoo.contains(item):
        print '{} has been removed'.format(item)
```

Bitarray Cuckoo filter
----------------------

A classic Cuckoo filter is implemented using a Python list of Bucket
objects. Each Bucket, again, stores a fixed list of fingerprints. The
implementation is easy and straightforward but unnecessary wasteful
for applications that needs to keep hundreds of millions of items.

The bitarray Cuckoo filter is built to deal with such situation. The
whole filter is compressed into a bitarray to minimize memory usage.
For example, a bitarray Cuckoo filter with capacity of 100.000.000,
bucket size of 4, and error rate of 0.000001 will requires:

- 23-bit fingerprint, computed using the above formula.
- <IP_ADDRESS> bits = 1.08 GB = capacity * bucket size * fingerprint.

And it can theoretically store up to 400.000.000 items at full capacity.

```python
import math

from random import randrange
from cuckoo.filter import BCuckooFilter

capacity = 1000000
error_rate = 0.000001
# Create a bit array Cuckoo filter with a fixed capacity of 1000000
# buckets
cuckoo = BCuckooFilter(capacity=capacity, error_rate=error_rate)

bucket_size = 6
# Setting the bucket size is optional, the bigger the bucket,
# the more number of items a filter can hold, and the longer
# the fingerprint needs to be to stay at the same error rate
cuckoo = BCuckooFilter(capacity=capacity, error_rate=error_rate, bucket_size=bucket_size)

# The fingerprint length is computed using the following formula:
fingerprint_size = int(math.ceil(math.log(1.0 / error_rate, 2) + math.log(2 * bucket_size, 2)))

for _ in range(1, 100000):
    item = str(randrange(1,<PHONE_NUMBER>))
    cuckoo.insert(item)

    if cuckoo.contains(item):
        print '{} has been added'.format(item)

    cuckoo.delete(item)

    if not cuckoo.contains(item):
        print '{} has been removed'.format(item)
```

Scalable Cuckoo filter
----------------------

Having a fix capacity is a problem when using Cuckoo filter in practice.
Allocating too much capacity and it goes to waste while allocating too
little and it degrades the filter performance and causes FP. Therefore,
the scalable Cuckoo filter is introduced as an attempt to solve the fix
capacity issue.

Inspired by Scalable Bloom filter, Scalable Cuckoo filter utilizes
multiple filters to scale the capacity dynamically.  When an existing
filter approaches its capacity, a new one, double in size, will be
created.  A scalable Cuckoo filter will handle all usual operations
seamlessly and transparently.

Internally, scalable Cuckoo filter uses bitarray Cuckoo filter for
efficiency although it can be changed easily.

```python
import math

from random import randrange
from cuckoo.filter import ScalableCuckooFilter

initial_capacity = 1000000
error_rate = 0.000001
# Create a scalable Cuckoo filter with an initial capacity of 1000000
# buckets
cuckoo = ScalableCuckooFilter(initial_capacity=initial_capacity, error_rate=error_rate)

bucket_size = 6
# Setting the bucket size is optional, the bigger the bucket,
# the more number of items a filter can hold, and the longer
# the fingerprint needs to be to stay at the same error rate
cuckoo = ScalableCuckooFilter(initial_capacity=initial_capacity, error_rate=error_rate, bucket_size=bucket_size)

# The fingerprint length is computed using the following formula:
fingerprint_size = int(math.ceil(math.log(1.0 / error_rate, 2) + math.log(2 * bucket_size, 2)))

for _ in range(1, 100000):
    item = str(randrange(1,<PHONE_NUMBER>))
    cuckoo.insert(item)

    if cuckoo.contains(item):
        print '{} has been added'.format(item)

    cuckoo.delete(item)

    if not cuckoo.contains(item):
        print '{} has been removed'.format(item)
```

repository: huydhn/cuckoo-filter

repo_name: huydhn/cuckoo-filter