text:
# SALTY DOG

Rule-based JSON/YAML validator using JSON schemas. Capable of filtering elements to validate partial documents,
supports multiple documents per stream or file, inserting defaults, and other magic.

- [SALTY DOG](#salty-dog)
  - [Getting Started](#getting-started)
  - [Status](#status)
  - [Releases](#releases)
  - [Build](#build)
  - [Install](#install)
    - [Docker](#docker)
    - [Node](#node)
      - [Global](#global)
      - [Project](#project)
  - [Usage](#usage)
    - [Modes](#modes)
      - [Check Mode](#check-mode)
      - [Fix Mode](#fix-mode)
        - [Default Values](#default-values)
        - [Coercing Values](#coercing-values)
      - [List Mode](#list-mode)
    - [Rules](#rules)
      - [Enabling Rules](#enabling-rules)
      - [Validate Rules](#validate-rules)
  - [License](#license)

## Getting Started

`salty-dog` is distributed as a package and container, and can be installed or pulled:

```shell
> docker pull ssube/salty-dog:master
> yarn add -D salty-dog
> yarn global add salty-dog
```

**Note:** while the container is the preferred way of running `salty-dog`, it has a serious limitation: `docker run`
combines `stdout` and `stderr`, making it impossible to separate logs and the output document. Writing either the logs
or dest to a file works around this.

To download, validate, and apply a Kubernetes resource:

```shell
> curl https://raw.githubusercontent.com/ssube/k8s-shards/master/roles/apps/gitlab/server/templates/ingress.yml | \
    salty-dog \
      --rules rules/kubernetes.yml \
      --source - \
      --tag kubernetes | \
    kubectl apply --dry-run -f -

...
{"name":"salty-dog","hostname":"cerberus","pid":7860,"level":30,"msg":"all rules passed","time":"2019-06-16T02:04:37.797Z","v":0}
ingress.extensions/gitlab created (dry run)
```

## Status

[![Pipeline status](https://img.shields.io/gitlab/pipeline/ssube/salty-dog.svg?gitlab_url=https%3A%2F%2Fgit.apextoaster.com&logo=gitlab)](https://git.apextoaster.com/ssube/salty-dog/commits/master)

[![Open bug count](https://img.shields.io/github/issues-raw/ssube/salty-dog/type-bug.svg)](https://github.com/ssube/salty-dog/issues?q=is%3Aopen+is%3Aissue+label%3Atype%2Fbug)
[![Open issue count](https://img.shields.io/github/issues-raw/ssube/salty-dog.svg)](https://github.com/ssube/salty-dog/issues?q=is%3Aopen+is%3Aissue)
[![Closed issue count](https://img.shields.io/github/issues-closed-raw/ssube/salty-dog.svg)](https://github.com/ssube/salty-dog/issues?q=is%3Aissue+is%3Aclosed)

[![Renovate badge](https://badges.renovateapi.com/github/ssube/salty-dog)](https://renovatebot.com)
[![Known vulnerabilities](https://snyk.io/test/github/ssube/salty-dog/badge.svg)](https://snyk.io/test/github/ssube/salty-dog)
[![Dependency status](https://img.shields.io/david/ssube/salty-dog.svg)](https://david-dm.org/ssube/salty-dog)
[![Dev dependency status](https://img.shields.io/david/dev/ssube/salty-dog.svg)](https://david-dm.org/ssube/salty-dog?type=dev)

[![Maintainability score](https://api.codeclimate.com/v1/badges/5d4326d6f68a2fa137cd/maintainability)](https://codeclimate.com/github/ssube/salty-dog/maintainability)
[![Technical debt ratio](https://img.shields.io/codeclimate/tech-debt/ssube/salty-dog.svg)](https://codeclimate.com/github/ssube/salty-dog/trends/technical_debt)
[![Quality issues](https://img.shields.io/codeclimate/issues/ssube/salty-dog.svg)](https://codeclimate.com/github/ssube/salty-dog/issues)

[![Language grade: JavaScript](https://img.shields.io/lgtm/grade/javascript/g/ssube/salty-dog.svg?logo=lgtm)](https://lgtm.com/projects/g/ssube/salty-dog/context:javascript)
[![Total alerts](https://img.shields.io/lgtm/alerts/g/ssube/salty-dog.svg)](https://lgtm.com/projects/g/ssube/salty-dog/alerts/)
[![MIT license](https://img.shields.io/github/license/ssube/salty-dog.svg)](https://github.com/ssube/salty-dog/blob/master/LICENSE.md)
[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fssube%2Fsalty-dog.svg?type=shield)](https://app.fossa.io/projects/git%2Bgithub.com%2Fssube%2Fsalty-dog?ref=badge_shield)

## Releases

[![Github release version](https://img.shields.io/github/tag/ssube/salty-dog.svg)](https://github.com/ssube/salty-dog/releases)
[![Commits since release](https://img.shields.io/github/commits-since/ssube/salty-dog/v0.6.1.svg)](https://github.com/ssube/salty-dog/compare/v0.6.1...master)

[![npm release version](https://img.shields.io/npm/v/salty-dog.svg)](https://www.npmjs.com/package/salty-dog)
[![Docker image size](https://images.microbadger.com/badges/image/ssube/salty-dog:master.svg)](https://microbadger.com/images/ssube/salty-dog:master)

## Build

This project is written in Typescript and requires `node` and `yarn` to build.

```shell
> git clone git@github.com:ssube/salty-dog.git
> cd salty-dog
> make
```

After building, run with `node out/index.js` or install run as `salty-dog`:

```shell
> cd salty-dog
> yarn global add file:$PWD
```

`make` targets are provided for some common arguments:

```shell
> curl https://raw.githubusercontent.com/ssube/k8s-shards/master/roles/apps/gitlab/server/templates/ingress.yml | \
    make run-stream 2> >($(yarn bin)/bunyan) > >(kubectl apply --dry-run -f -)

...
[2019-06-16T03:23:56.645Z]  INFO: salty-dog/8015 on cerberus: all rules passed
ingress.extensions/gitlab created (dry run)
```

## Install

### Docker

To run with Docker: `docker run --rm ssube/salty-dog:master`

The latest semi-stable image is `ssube/salty-dog:master`. All
[tags are listed here](https://cloud.docker.com/repository/docker/ssube/salty-dog/tags).

The Docker container is published for each branch and git tag, tagged with the git tag (or branch slug).

Rules are baked into the image in `/salty-dog/rules`. To use custom rules, mount them with
`-v $(pwd)/rules:/salty-dog/rules:ro` and load with `--rules /rules/foo.yml`.

### Node

#### Global

To install with Yarn as a global CLI tool: `yarn global add salty-dog`

To run with Node:

```shell
> export PATH="${PATH}:$(yarn global bin)"
> salty-dog --help
```

#### Project

To install with Yarn for a single project: `yarn add -D salty-dog`

To run with Node:

```shell
> export PATH="${PATH}:$(yarn bin)"
> salty-dog --help
```

## Usage

### Modes

`salty-dog` can run in a few different modes: `check` mode will report errors, `fix` mode will attempt to modify the
input document, and `list` mode will print the active set of rules.

#### Check Mode

By default, `salty-dog` will validate the structure and contents of the `--source` document. If all rules pass, the
document will be printed to `--dest`.

```shell
> cat examples/kubernetes-resources-pass.yml | salty-dog \
    --rules rules/kubernetes.yml \
    --tag kubernetes

...
[2019-06-15T23:53:34.223Z]  INFO: salty-dog/19839 on cerberus: all rules passed

> cat examples/kubernetes-resources-fail.yml | salty-dog \
    --rules rules/kubernetes.yml \
    --tag kubernetes

...
[2019-06-15T23:56:04.764Z] ERROR: salty-dog/22211 on cerberus: some rules failed (errors=1)

```

The `--source` and `--dest` default to stdin and stdout, respectively, but a path may be provided:

```shell
> salty-dog \
    --rules rules/kubernetes.yml \
    --tag kubernetes \
    --source examples/kubernetes-resources-pass.yml \
    --dest /tmp/kubernetes-resource.yml

...
[2019-06-15T23:53:34.223Z]  INFO: salty-dog/19839 on cerberus: all rules passed
```

#### Fix Mode

`salty-dog` can also add default values to missing properties in `fix` mode. If a rule does not immediately pass
with the `--source` document, but defaults are provided in the schema, the defaults will be inserted before printing to
`--dest`.

```shell
> salty-dog fix \
    --source examples/kubernetes-resources-some.yml \
    --rules rules/kubernetes.yml \
    --tag kubernetes
```

##### Default Values

Properties that appear in the schema with a `default` provided will be added to each element as it is checked. Rules
apply in order, as do their defaults.

##### Coercing Values

Properties that appear in the document with a different `type` than they have in the schema may be coerced, if the
value is compatible with the schema type. [The full matrix of valid type coercions](https://ajv.js.org/coercion.html)
is documented by Ajv.

#### List Mode

`salty-dog` can list the active set of rules, to help debug tags and inclusion. Both `--source` and `--dest` are
ignored in `list` mode.

```shell
> salty-dog list \
    --rules rules/kubernetes.yml \
    --tag kubernetes

...
[2019-06-30T18:39:11.930Z]  INFO: salty-dog/26330 on cerberus: listing active rules
    rules: [
      {
        "desc": "resource limits are too low",
        "level": "debug",
        "name": "kubernetes-resources-minimum-cpu",

...
    ]
```

### Rules

Rules combine a jsonpath expression and JSON schema to select and validate the document.

The rule's `select` expression is used to select nodes that should be validated, which are `filter`ed, then `check`ed.

The structure of rule files and the rules within them [are documented here](docs/rules.md).

#### Enabling Rules

All rules are disabled by default and must be enabled by name, level, or tag.

To enable a single rule by name, `--include-name foo-rule`.

To enable a group of rules by level, `--include-level warn`.

To enable a group of rules by tag, `--include-tag foo`.

#### Validate Rules

To validate the rules in the `rules/` directory using the meta-rules:

```shell
> make test-rules

...
{"name":"salty-dog","hostname":"cerberus","pid":29403,"level":30,"msg":"all rules passed","time":"2019-06-16T00:56:55.132Z","v":0}
```

## License
[![FOSSA Status](https://app.fossa.io/api/projects/git%2Bgithub.com%2Fssube%2Fsalty-dog.svg?type=large)](https://app.fossa.io/projects/git%2Bgithub.com%2Fssube%2Fsalty-dog?ref=badge_large)

repository: camo-f/salty-dog

repo_name: camo-f/salty-dog


text:
# To compile and start the client in production mode

To install the dependencies do:

```
npm install
```

Build the application:

```
npm run build:prod
```

To start the application do:

```
npm start
```

# Developing

To update bebop-bridge-shared do and explicit:
```
npm install bebop-bridge-shared
```

# Debugging with VSCode

```
npm run build:dev
```

Hit F5.

# If things are messed up

Do a 'npm cache clear', and there are global npm modules installed here:
C:\Users\jruesch\AppData\Roaming\npm\node_modules
Clean this up.

# Deprecated: Issues with Errorhandler typings

Replace thisin errorhandler index.d.ts:
  function errorHandler(options?: errorHandler.Options): express.ErrorRequestHandler;
with this
function errorHandler(options?: errorHandler.Options): express.ErrorHandler;

# Flightplans on Bebop

Bebop flightplan:

```
ftp://<IP_ADDRESS>/internal_000/flightplans/flightPlan.mavlink
```
```
anonymous
@anonymous
```

Somewhere might be this path required.... don't remember why/where
```
ftp://<IP_ADDRESS>/data/ftp/internal_000/flightplans/flightPlan.mavlink
```

license: MIT

repository: jrgenerative/bebop-bridge-service

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: jrgenerative/bebop-bridge-service


text:
# (Round) CNCDoveTailCut
Generate GCode for cutting dove tail joints with a CNC milling machine

## Getting Started

Install the module with:
```sh
$ npm install cncdovetailcut
```

Install with cli command

```sh
$ npm install -g cncdovetailcut
```

## Documentation

The following commands are available to use:

_Usage:_ cncdovetailcut gcode [options] [command]

_Commands:_

  gcode [options]
     generate gcode for specified parameters

_Options:_

  -h, --help             output usage information
  -v, --version          Program version

##Credits

* converting canvas to GCode: [GCanvas](https://github.com/em/gcanvas)
* drawing a smooth line (millable from inside and outside) through a number of points: [Cardinal-Spline-JS](https://github.com/epistemex/cardinal-spline-js)

repository: asmuelle/CNCDoveTailCut

repo_name: asmuelle/CNCDoveTailCut


text:
---
title: "What are some pilots that have involved the industry? "
date: 2023-03-16T04:20:22.672Z
type: General
---
The TradeTrust team in IMDA has orchestrated several industry-led eBL Trade Financing pilots involving Buyers, Sellers, Banks, Shipping Lines and Business Solution Providers.

These pilots seek to demonstrate TradeTrust’s ability to:\
a. Digitalise the Bill of Lading document (among other required trade documents) which is commonly used in documentary trade financing arrangements \
b. Facilitate online presentation of all required electronic documents to the banks for verification and title ownership transfer (for eBL)\
c. Decentralise the transactions for an eBL by allowing pilot participants to use different digital solutions/platforms to verify and transact the digital document

Below is an illustration of the pilot scope for documentary trade financing arrangements such as Letter of Credit (L/C), Documents against Acceptance (D/A) and Documents against Payment (D/P) where an eBL is issued, sent, verified and endorsed to the next party in the financing value chain.

![](/static/uploads/general_faq_pilots-2x-100.jpg)

Potential benefits of such pilots include raising efficiency of the process, reducing the overall financing lead time and lowering risk of frauds involved for all parties. Local banks such as UOB and DBS were participants of these pilots.

repository: TradeTrust/tradetrust-website

gha_language: TypeScript

repo_name: TradeTrust/tradetrust-website


text:
# Compo

[![Gem Version](https://badge.fury.io/rb/compo.svg)](http://badge.fury.io/rb/compo)
[![Build Status](https://travis-ci.org/CaptainHayashi/compo.svg)](https://travis-ci.org/CaptainHayashi/compo)

**Compo** is a library providing mixins and base classes for setting up
composite objects.

It's similar to the Gang of Four Composite pattern, but in Compo
children are identified in their parents by an *ID*,
such as an index or hash key, that the child is aware of at all times.

Compo was designed for models whose composite
structure can be expressed as URLs made from their recursive ID trails.

## Installation

Add this line to your application's Gemfile:

    gem 'compo'

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install compo

## Usage

Compo consists of several classes and mixins that implement various parts of the composite pattern.  In increasing order of general usefulness, they are:

### Base mixins

- **Composite**, which specifies the #add/#remove/#remove_id/#get_child API on top of an implementation;
- **Movable**, which creates a #move_to method that simplifies the act of moving a child between Composites;
- **ParentTracker**, which implements keeping track of a child's parent and the child end of #add/#remove;
- **URLReferenceable**, which allows the current position of an object in a hierarchy of composites to be retrieved as an URL-style reference;
- **Branch**, which is simply a **Moveable** **URLReferenceable** **ParentTracker**.

### Composite implementation classes

These implement the methods needed for **Composite** to work, but don't implement moving, parent tracking, or anything else.

- **ArrayComposite**, which is a class that implements **Composite** using an Array, with IDs being the array indices;
- **HashComposite**, which is a class that implements **Composite** using a Hash, with IDs being the hash keys;
- **NullComposite**, which allows no children but implements **Composite** in a way such that all operations fail;

### Simple leaf and node classes

These include **Branch**, and thus can be moved around, added to and removed from composites, and track their current parents and IDs.

- **Leaf**, which is based on NullComposite and is intended for objects that don't have children but can be placed in other Composites;
- **ArrayBranch**, which is based on ArrayComposite;
- **HashBranch**, which is based on HashComposite.

Generally, you'll only need to use these classes (use **Leaf** when creating objects that can be part of other objects but not have children themselves, **ArrayBranch** when an object has a list of ordered children *whose ordering changes as more children are added and deleted*, and **HashBranch** when it has a collection of children with arbitrary IDs).

## Contributing

1. Fork it
2. Create your feature branch (`git checkout -b my-new-feature`)
3. Commit your changes (`git commit -am 'Add some feature'`)
4. Push to the branch (`git push origin my-new-feature`)
5. Create new Pull Request


text:
# Discord  Widget

[![pipeline status](https://gitlab.com/Venipa/discord-widget/badges/master/pipeline.svg)](https://gitlab.com/Venipa/discord-widget/commits/master)

![](https://i.mavis.moe/f/vOfYdHWT7E/nhklvwcxuyb243gif.gif)

### Usage

```html
<div data-discordId="discord-guild-id"></div>

<!-- Include the actual Script -->
<script src="./dist/app.js"></script>
<!-- Initiating Script with the selected data attribute -->
<script>
    $(document).ready(function () {
        $('[data-discordId]').DiscordMidget();
    });
</script>
```

### Default Properties/Options

```
elements: $(this)
Width: "100%"
minWidth: ""
minHeight: "600px"
maxWidth: "100%"
maxHeight: "100px"
extraClasses: ""
```

### License

```
MIT License

Discord Midget Author Thiago Cosmovici
Copyright (c) 2018 Discord Midget

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

 IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
```

### Projects used

- [Tippy](https://atomiks.github.io/tippyjs/)

### Socials

- [Instagram](https://www.instagram.com/venipaa/)
- [Email - admin<EMAIL_ADDRESS>- Discord: Cascade#0001

repository: Venipa/discord-widget

gha_language: CSS

gha_license_id: NOASSERTION

repo_name: Venipa/discord-widget


text:
# SIFT Bootstrap

Ubuntu 14.04 is the only distribution supported by this script.

## DEPRECATED WARNING

This script/repo has been deprecated in favor of managing and installing SIFT using [saltstack](https://github.com/sans-dfir/sift-saltstack). You must use 16.04 going forward to install SIFT using SaltStack or the SIFT CLI.

The preferred method of installation is done via the [SIFT CLI tool](https://github.com/sans-dfir/sift-cli). This command line utility will download and validate install signatures and SHA hashes before installing.

## Issues

If you have bugs or issues to track please use https://github.com/sans-dfir/sift/issues


text:
# meet-me-in-the-middle

![PyPI - License](https://img.shields.io/pypi/l/meetme)
![PyPI - Python Version](https://img.shields.io/pypi/pyversions/meetme)
![PyPI](https://img.shields.io/pypi/v/meetme?color=blue)
[![Build Status](https://travis-ci.com/andrew-curthoys/meetme.svg?branch=master)](https://travis-ci.com/andrew-curthoys/meetme)

# Overview
Meet Me in the Middle is a flight search engine for meeting up with friends, family, and loved ones who live in a different city. The user will input two origin cities and MMitM will output a table with flight prices for common destinations

# Usage
Create a 'flight_frame' object and give it a name. User will need to input their API key & API secret to authenticate to run requests.
```python
import meet_me
ff = meet_me.FlightFrame(api_key, api_secret)
```

To return a dataframe with destinations and combined prices call the 'lets_go' method. Minimum inputs are two origin cities, a departure date, and trip duration.

```python
ff.lets_meet('LAX','JFK', '2020-01-01', 7)
```

repository: andrew-curthoys/meet-me-in-the-middle

gha_language: Python

gha_license_id: MIT

repo_name: andrew-curthoys/meet-me-in-the-middle


text:
# Hometask: Allocator

## You should type on command line:

    if you want to pass tests:
        -> make test

    if you want to clear all created files:
        -> make clear

#### Allocator is a structure which supports basic functions like reset and alloc. After calling reset, the allocator allows you to use your memory again. Alloc gives to you oppotunitues to take memory what you size you want but if the requested size will be bigger  that available memory in Allocator, it returns to you nullptr pointer.


text:
---
description: Welcome to Prefect 2!
tags:
    - overview
    - quick start
    - resources
---

# Quick Start

Welcome to Prefect!

Whether you've been working with Prefect for years or this is your first time, this collection of tutorials will guide you through the process of defining, running, monitoring and eventually automating your first Prefect 2 workflow.

First and foremost, you'll need [a working version of Prefect 2 installed](installation.md).

From there, you can [follow along with the tutorials](/tutorials/first-steps/), which iteratively build up the various concepts and features that you'll need to get the most out of your workflows.

If you want to take a deeper dive into the concepts that make up the Prefect ecosystem, check out our [Concepts documentation](/concepts/overview).

## Get started with Prefect 2

To jump right in and get started using Prefect 2, you'll need to complete the following steps:

- [Install Prefect](/getting-started/installation/).

That's it! You're ready to [start writing local flows](/tutorials/first-steps/). Flow run details for these flows will appear in the [Prefect 2 UI](/ui/overview/) without additional configuration.

If you want to start running flows on a schedule, via the API, from the Prefect UI, or on distributed infrastructure, you'll need to understand a few additional concepts and perform some configuration.

- Start a [Prefect Orion API server](/ui/overview/) with `prefect orion start` or create a [free Prefect Cloud account](/ui/cloud-getting-started/).
- [Set `PREFECT_API_URL`](/tutorials/orion/#running-the-prefect-server) to enable communication between your execution environment and the Prefect Orion server or Prefect Cloud API.
- Configure [storage](/tutorials/storage/) to persist flow and task data.
- Create a [deployment](/tutorials/deployments/) for a flow, giving the API metadata about where your flow's code is stored and how your flow should be run.
- [Start an agent](/concepts/work-queues/#agent-overview) that can execute scheduled or ad-hoc flow runs from your deployments.

If you have used Prefect 1 and are familiar with Prefect workflows, we recommend reading through the [Prefect 2 tutorials](/tutorials/first-steps/). Prefect 2 flows and subflows offer new functionality, and running deployments with [agents and work queues](/tutorials/deployments/) reflects a significant change in how you configure orchestration components.

## Migrating from Prefect 1

If you are already running flows with Prefect 1, our [Migration Guide](/migration-guide/) provides an overview of changes you'll find in Prefect 2 and suggested practices for migrating your existing flows to work with Prefect 2.

And as suggested previously, we recommend reading through the [Prefect 2 tutorials](/tutorials/first-steps/) for worked examples of writing flows and tasks with Prefect 2.

!!! help "Additional Resources"
    If you don't find what you're looking for here there are many other ways to engage, ask questions and provide feedback:

    - [Prefect's Slack Community](https://www.prefect.io/slack/) is helpful, friendly, and fast growing - come say hi!
    - [Prefect Discourse](https://discourse.prefect.io/) is a knowledge base with plenty of tutorials, code examples, answers to frequently asked questions, and troubleshooting tips. Ask any question or just [browse through tags](https://discourse.prefect.io/docs).
    - [Open an issue on GitHub](https://github.com/PrefectHQ/prefect/issues) for bug reports, feature requests, or general discussion
    - [Email<EMAIL_ADDRESS>to setup a demo, get dedicated support or learn more about our commercial offerings

repository: Clearcover/prefect

repo_name: Clearcover/prefect


text:
## AWS Identity: Using Cognito for serverless consumer apps

In this workshop, you learn how to build a serverless customer-facing microservices application demonstrating end-to-end authentication and authorization using Amazon Cognito, Amazon API Gateway, AWS Lambda, and all things AWS Identity and Access Management (IAM). You have the opportunity to build an end-to-end functional app with a secure identity provider showcasing user authentication patterns.

## Start the workshop:

Visit the site to get started: [https://serverless-idm.awssecworkshops.com/](https://serverless-idm.awssecworkshops.com/)

## License

This library is licensed under the Apache 2.0 License.


text:
---
title: React Hooks Modal
slug: /react-hooks-modal
date: 2019-01-13
cover:
  img: modal.svg
  source: Codyhouse
  url: https://codyhouse.co/gem/svg-modal-window
tags:
  - JS
  - Web Dev
  - Tutorial
---

What to do on a cold and wet January weekend? Why not check out the new [React alpha (16.8)](https://reactjs.org/blog/2018/11/27/react-16-roadmap.html#react-16x-q1-2019-the-one-with-hooks). **The one with Hooks** as it's come to be called.

All it took was a little skimming through [the docs](https://reactjs.org/docs/hooks-intro.html), followed by updating `react` and `react-dom`.

```sh
yarn add react@next react-dom@next
```

That's it. Ready to start coding. But what to do first? One thing that seemed a good fit for hooks are modals. I'd implemented them once or twice before and in both cases came away with the feeling that a class component with all its boilerplate is overkill considering the tiny bit of state management required for modal functionality. As expected, using hooks I was able to boil it down quite considerably. This is what I ended up with.

```jsx:title=src/components/modal/index.js
import React from 'react'

import { ModalBehind, ModalDiv, Close } from './styles'

const Modal = ({ open, closeModal, children }) => {
  return (
    <ModalBehind open={open} onClick={closeModal}>
      <ModalDiv onClick={event => event.stopPropagation()}>
        <Close onClick={closeModal} />
        {children}
      </ModalDiv>
    </ModalBehind>
  )
}

export default Modal
```

And here are the styled components imported on line 3.

```js:title=src/components/modal/styles.js
import styled from 'styled-components'
import { Close as Cross } from 'styled-icons/material'

export const ModalBehind = styled.div`
  position: fixed;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  background-color: rgba(0, 0, 0, 0.5);
  display: grid;
  visibility: ${props => (props.open ? `visible` : `hidden`)};
  opacity: ${props => (props.open ? `1` : `0`)};
  transition: 0.5s;
  z-index: 2;
`

export const ModalDiv = styled.div`
  display: grid;
  align-items: center;
  box-sizing: border-box;
  align-self: center;
  justify-self: center;
  background: var(--color-background);
  height: max-content;
  max-height: 80vh;
  width: 80vw;
  position: relative;
  overflow: scroll;
  border-radius: 0.5em;
  transition: 0.3s;
  box-shadow: 0 0 3em black;
  margin: calc(0.5em + 2vw);
`

export const Close = styled(Cross).attrs({ size: `2em` })`
  position: absolute;
  top: 0.5em;
  right: 0.4em;
  cursor: pointer;
`
```

As you can see, the styles are longer than the component itself. That's where I spent most of my time too. Figuring out how to use React hooks took mere minutes. Props to the React team (pun intended) for the excellent onboarding experience!

Anyways, regarding usage, notice that the modal component doesn't actually handle it's own state. That's done by the parent component. As an example here's a [list of photos](/nature) that when clicked enter a higher-resolution modal view.

```js
import React, { useState, Fragment } from 'react' // highlight-line

import Masonry from 'components/Masonry'
import Modal from 'components/Modal'

import { Thumbnail, LargeImg } from './styles'

export default function Photos({ photos }) {
  const [modal, setModal] = useState() // highlight-line
  return (
    <Masonry>
      {photos.map((img, index) => (
        <Fragment key={img.title}>
          <Thumbnail
            onClick={() => setModal(index)} // highlight-line
            alt={img.title}
            src={img.src}
          />
          // highlight-next-line
          <Modal open={index === modal} {...{ modal, setModal }}>
            <LargeImg alt={img.title} src={img.src} />
          </Modal>
        </Fragment>
      ))}
    </Masonry>
  )
}
```

So basically just 4 lines of code to control the list of modals (and 2 of those do other things as well). I have to say, I was pretty impressed by that. For comparison, this is how much code the class implementation needed (just the JS, no styles yet).

```jsx
import React from 'react'
import { connect } from 'react-redux'

import { toggleModal } from '../redux/actions'
import './Modal.css'

class Modal extends React.Component {
  handleClickOutside = event => {
    if (this.node && !this.node.contains(event.target)) {
      const { dispatch, name } = this.props
      dispatch(toggleModal(name))
    }
  }

  componentDidMount() {
    if (this.props.closeOnClickOutside)
      document.addEventListener(`mousedown`, this.handleClickOutside)
  }

  componentWillUnmount() {
    document.removeEventListener(`mousedown`, this.handleClickOutside)
  }

  render() {
    const { modal, name, closeButton, toggleModal, children } = this.props
    if (!modal) return null
    return (
      <div ref={node => (this.node = node)} id={name + `-modal`}>
        {closeButton && (
          <button className="close-button" onClick={toggleModal}>
            ✕
          </button>
        )}
        {children}
      </div>
    )
  }
}

const mapStateToProps = (state, { name }) => {
  return {
    modal: state.modals[name],
  }
}

export default connect(mapStateToProps)(Modal)
```

Admittedly this component is bloated further by using Redux but even without it, it's much harder to read and maintain. I'd call this use case a definite win for React Hooks!

## Semantic HTML

One thing I should mention for future readers who want to use this `Modal` component: Once Chrome's new [`<dialog>` tag](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog) gets better [browser support](https://caniuse.com/#feat=dialog), it would improve semantics to use it for the modal container, i.e.

```js
// previously: styled.div
export const ModalDiv = styled.dialog`
  ...;
`
```

and then maybe use the `::backdrop` pseudo-element for the modal background.

```js
export const ModalDiv = styled.dialog`
  ::backdrop {
    ...;
  }
`
```

However, bear in mind that using `::backdrop` would make it more difficult to close the modal on clicks outside of it, i.e. on the background. This is because React is unable to attach `onClick` event handlers to pseudo-elements and it seems unlikely this will change down the road. A workaround would be to use the new `useRef` and `useEffect` hook to create an event listener on the browser's `window` object that checks for the target of the `click` event. That would complicate things a little, though, since the listener would have to trigger on _all_ clicks and check that the modal doesn't include the target before closing. Something like so:

```jsx:title=components/modal/index.js
import React, { useRef, useEffect } from 'react'

import { ModalBehind, ModalDiv, Close } from './styles'

const handleClickOutside = (node, closeModal) => event => {
  if (node && !node.contains(event.target)) closeModal()
}

export default function Modal({ open, closeModal, children }) {
  const ref = useRef()
  useEffect(() => {
    const handler = handleClickOutside(ref.current, closeModal)
    document.addEventListener('mousedown', handler)
    return () => document.removeEventListener('mousedown', handler)
  })
  return (
    <ModalDiv ref={ref} open={open}>
      <Close onClick={closeModal} />
      {children}
    </ModalDiv>
  )
}
```

## Keyboard controls

If you have a list of modals and you'd like users to be able to go to the next or previous modal using the arrow keys, you can add an event listener with the `useEffect` hook for this as well.

```js:title=src/components/modal/index.js
import React, { useEffect } from 'react'

import { ModalBehind, ModalDiv, Close, Next, Prev } from './styles'

// highlight-start
const handleArrowKeys = (modal, setModal) => event => {
  if (event?.key === `ArrowRight`) setModal(modal + 1)
  else if (event?.key === `ArrowLeft`) setModal(modal - 1)
  else if (event?.key === `Escape`) setModal()
}
// highlight-end

export default function Modal({ open, modal, setModal, ...rest }) {
  // highlight-start
  const { showArrows, className, children } = rest
  useEffect(() => {
    const handler = handleArrowKeys(modal, setModal)
    document.addEventListener(`keydown`, handler)
    return () => document.removeEventListener(`keydown`, handler)
  })
  // highlight-end
  if (open) {
    return (
      // Passing setModal to onClick without arguments implicitly
      // sets to undefined, i.e. closes the modal.
      <ModalBehind open={open} onClick={setModal}>
        <ModalDiv onClick={event => event.stopPropagation()} className={className}>
          <Close onClick={setModal} />
          // highlight-start
          {showArrows && (
            <>
              <Next onClick={() => setModal(modal + 1)} />
              <Prev onClick={() => setModal(modal - 1)} />
            </>
          )}
          // highlight-end
          {children}
        </ModalDiv>
      </ModalBehind>
    )
  } else return null
}

export default Modal
```

The new styled components `Next` and `Prev` share most of their CSS with `Close` so it makes sense to reuse that:

```js:title=src/components/modal/styles.js
import styled, { css } from 'styled-components'

import { Close as Cross, NavigateNext, NavigateBefore } from 'styled-icons/material'

const controlsCss = css`
  position: absolute;
  cursor: pointer;
  z-index: 1;
  color: ${props => props.white && `white`};
  background: ${props => props.white && `rgba(0, 0, 0, 0.5)`};
  border-radius: 50%;
  padding: 0.1em;
  transition: 0.3s;
  :hover {
    transform: scale(1.07);
  }
`

export const Close = styled(Cross).attrs({ size: `2em` })`
  ${controlsCss};
  top: 0.5em;
  right: 0.4em;
`

export const Next = styled(NavigateNext).attrs({ size: `2em` })`
  ${controlsCss};
  top: 50%;
  right: 0.4em;
`

export const Prev = styled(NavigateBefore).attrs({ size: `2em` })`
  ${controlsCss};
  top: 50%;
  left: 0.4em;
`
```

For the full and most up to date implementation of this component, check out [this site's Github repo](https://github.com/janosh/blog/tree/master/src/components/Modal).

repository: daosonit/blog

repo_name: daosonit/blog


text:
# Changelog
All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

<!-- ## [Unreleased]

### Added
### Changed
### Deprecated
### Removed
### Fixed
### Security -->

## [2.0.0] - 2020-08-10

### Added

- `/cs osm` and `/cs osmnear` to run any overpass query in an area and plot the path
- `/cs gis_jp` command, to get better elevation data in Japan.

- `/cs draw` command:
  - Keyhole markup language (.kml) support.
- `/cs rails` command:
  - `regex` option (allow you to select rail type)

- Every command that places blocks:
  - `height` option to set wall height.
  - `onGround` option to draw on the ground or not.
  - `offset` option to set ground offset.
  - `ignoreBuildings` option to ignore existing buildings.
  - `ignoreVegetation` option to ignore vegetation.
  - `ignoredBlocks` & `allowedBlocks` options.

### Changed

- `/cs ign` is now `/cs gis_fr`
- The syntax of all commands has been changed. Options are now in the form of a JSON object, offering much more flexibility.
- `/cs rails <mode>` command and `/cs hedges <mode>` have been split into different commands: `rails`, `railsnear`, `hedges`, `hedgesnear`.

### Removed

- `list` command. Use `/cs help` instead.

### Fixed

- OSM commands for the western hemisphere.
- Corrupted values in elevation commands.
- `undefined` values in some commands

### Security

- Updated Node modules.

## [1.4.0] - 2020-05-24

### Added

- `hedges` command: traces hedges around farmland

### Changed

- `rails` syntax
  - now takes block option.

## [1.3.1] - 2020-05-20

### Added

- `ign` command
  - Smoothing step.

### Changed

- `ign` command
  - Support for regions of all shapes.
  - Faster calculations (request parallelization).

## [1.3.0] - 2020-05-13

### Added

- `ign` command.

### Changed

- `tpdms` and `tpll` are now unified.

### Removed

- `tpdms` command.

## [1.2.0] - 2020-05-07

### Added

- `address` command.

## [1.1.1] - 2020-05-06

### Fixed

- `rails` command now scan for all rails instead of a small subset.

## [1.1.0] - 2020-05-05

### Added

- `rails` command.

repository: TjhVarga/BTE-tools

repo_name: TjhVarga/BTE-tools


text:
![Grantinee](./grantinee.png)

# Grantinee

Grantinee is a library to manage your database permissions. It supports MySQL and Postgres, allowing for granular per-table, and per-column permission setting. Tight and explicit permissions, instead of "allow all access" approach, may enhance the data security in your app, and make the GDPR compliance easier for multi-user databases (like when you have a service-oriented architecture).

[![Gem Version](https://badge.fury.io/rb/grantinee.svg)](https://badge.fury.io/rb/grantinee)
[![CircleCI](https://circleci.com/gh/blinkist/grantinee/tree/master.svg?style=svg&circle-token=be47ddf3e39aa44795797ae40c06bd42144ad888)](https://circleci.com/gh/blinkist/grantinee/tree/master)

## Installation

Add this line to your application's Gemfile:

```ruby
gem 'grantinee'
```

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install grantinee

## Usage

Before you start using Grantinee you need to configure it.

### User ActiveRecord connection (Rails)

As long as you use Grantinee's executable, everything is plug-and-play. Just make sure that you operate in the right environment, and your database user has granting rights (most likely it won't have them for security reasons). Simply run:

    $ RAILS_ENV=production bundle exec grantinee

If you'd like to use Grantinee programmatically as a library, you will need to create two things:

```ruby
# Create or pass an existing logger
Grantinee.logger = ::Logger.new(STDOUT)

# (optional) Manually call ActiveRecord detection
Grantinee::Engine.detect_active_record_connection!
```

### Custom database connection

You may create an initializer, providing each information separately:

```ruby
Grantinee.configure do |c|
  c.engine   = :mysql

  c.username = 'root'
  c.password = 'password'
  c.hostname = 'localhost'
  c.port     = 3306
  c.database = 'database_name'
end
```

Alternatively you can use the database URL (looking at you Heroku):

```ruby
Grantinee.configure do |c|
  c.engine = :mysql
  c.url    = "mysql://root:password@localhost:3306/database_name"
end
```

In case you do not want to or cannot use an initializer, you can save your configuration in a standalone ruby file, which you pass as an argument in the command line, i.e.:

    $ grantinee -c ./config/grantinee.yml

### Command line options

Grantinee provides flexible configuration options through the command line parameters, you can easily review them, by running:

    $ grantinee --help

```
Usage: grantinee [options]
    -h, --help                       Displays help
    -v, --verbosity=LEVEL            Set verbosity level to debug, info, warn, error, fatal, or unknown (default: warning)
    -r, --require=FILE               Application boot file path (default: ./config/environment.rb)
    -f, --file=FILE                  Permission definitions file path (default: ./Grantinee)
    -c, --config=FILE                Database configuration file path
```

## Permissions definition

You can use the DSL to quickly set up your permissions:

```ruby
on "database_name" do
  # User on any host
  user :username do
    select :users, [ :id, :name ]
    insert :users, [ :tracking_id ]
    update :users, [ :tracking_id ]

    all :articles
  end

  # Or user on a specific host
  user<EMAIL_ADDRESS>do
    select :users, [ :id, :name ]
    insert :users, [ :tracking_id ]
  end
end

```

## Development

After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).

## Contributing

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

## License

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

## Code of Conduct

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

repository: blinkist/grantinee

gha_language: Ruby

repo_name: blinkist/grantinee


text:
# Change Log

This log documents the significant changes for each release.
This project follows [Semantic Versioning](http://semver.org/).

## [2.1.1] - 06-16-2020
### Changed
- Cloned from https://github.com/InvokIT/js-untar.git and fixed a bug
  that a "Maximum call stack size exceeded" error might occur when the tar file is too big.
- Updated some npm packages and gulp concofiguration.

repository: lhcye/js-untar

repo_name: lhcye/js-untar


text:
---
title: Back2Roots - My static site generator
date: 2020-02-04T22:50:00+01:00
template: blogpost.twig
---

To bootstrap this blog, I wanted to do something new. Far away from the new hotness of static site generators like [Gatsby](https://www.gatsbyjs.org/) or [Next.js](https://nextjs.org/).

## Motivation

I wanted to do something _simple_, but at the same time, _I wanted to learn new things about Node and TypeScript_!

So I came up with [Back2Roots](https://github.com/andi1984/back2roots) which is a Node-based static site generator using Markdown and Twig as a templating language. Of course, the feature list is far more reduced than it would be for any existing generator, but while working on Back2Roots I learn about Node and TypeScript.

So, in the end, I'm building my new blog with a new, custom tool that I've to build on my own while learning new things. So what can I expect more?

Back2Roots is an open-source project. Feel free to fork and adapt it to your needs or let me know about feature requests or bug reports!

## TypeScript + Node + Markdown + Twig

The project is based on Node with [TypeScript](https://www.typescriptlang.org/) from the ground up. The actual static site generation happens via

1. parsing the markdown files via [markdown-it](https://github.com/markdown-it/markdown-it)
2. setup Twig infrastructure via [twig.js](https://github.com/twigjs/twig.js)
3. passing the markdown data through the Twig instance which generates the final HTML files

## It's open-source!

The project is published on [Github](https://github.com/andi1984/back2roots) under [MIT License](https://github.com/andi1984/back2roots/blob/develop/LICENSE).

branch_name: refs/heads/develop

gha_language: JavaScript


text:
[Overview](index.md) | [Store](store.md) | [View](view.md) | [Binding and Lifecycle](binding_and_lifecycle.md) | [State preservation](state_preservation.md) | [Logging](logging.md) | Time travel

## Time travel

Time travel is a power debugging tool. Basically it allows you to record all events and states from all active `Stores`. When events are recorded you can explore them, replay and debug. The core functionality is multiplatform and is available for all supported targets.

If you want to use the time travel tool you have to use the [TimeTravelStoreFactory](https://github.com/arkivanov/MVIKotlin/blob/master/mvikotlin-timetravel/src/commonMain/kotlin/com/arkivanov/mvikotlin/timetravel/store/TimeTravelStoreFactory.kt).

> ⚠ Time travel is a debugging tool and may affect performance, ideally it should not be used in production.

### Using TimeTravelStoreFactory

The `TimeTravelStoreFactory` is used to create implementations of `Store` that are able to record and replay events.

Suppose we have the following `Store` factory:

```kotlin
internal class CalculatorStoreFactory(private val storeFactory: StoreFactory) {

    fun create(): CalculatorStore =
        object : CalculatorStore, Store<Intent, State, Nothing> by storeFactory.create(
            name = "CounterStore",
            // ...
        ) {
        }

    // Omitted code
}
```

It accepts a `StoreFactory` and uses it to create an implementation of the `CalculatorStore`. You can now pass any `StoreFactory` here. So if you want to enable time travel just pass an instance of the `TimeTravelStoreFactory`:

```kotlin
val storeFactory = TimeTravelStoreFactory(DefaultStoreFactory)

CalculatorStoreFactory(storeFactory).create()
```

You can also combine it with the `LoggingStoreFactory` in the following way:

```kotlin
val storeFactory = LoggingStoreFactory(TimeTravelStoreFactory(DefaultStoreFactory))

CalculatorStoreFactory(storeFactory).create()
```

Normally you should define a global `StoreFactory` somewhere in the main app and pass it down to all the dependencies.

### Time travel UI

You can integrate a special UI into your app which provides controls for time travel and displays a list of recorded events. It is also possible to explore and debug any recorded event. Debugging means you can put a breakpoint in your code and fire a previously recorded event. You can do usual debugging when the breakpoint is triggered.

For Android you can use the [TimeTravelView](https://github.com/arkivanov/MVIKotlin/blob/master/mvikotlin-timetravel/src/androidMain/kotlin/com/arkivanov/mvikotlin/timetravel/widget/TimeTravelView.kt).
For iOS you can copy-paste [TimeTravelViewController](https://github.com/arkivanov/MVIKotlin/blob/master/sample/todo-app-ios/todo-app-ios/TimeTravelViewController.swift) from the sample app.

Check out the following videos demonstrating time travel UI:
- [Debugging Android application with MVIKotlin](https://youtu.be/_bbxR503-u0)
- [Debugging iOS application with MVIKotlin](https://youtu.be/MJCYQzeL-w8)

Alternatively you can create your own time travel UI. Please refer to [TimeTravelController](https://github.com/arkivanov/MVIKotlin/blob/master/mvikotlin-timetravel/src/commonMain/kotlin/com/arkivanov/mvikotlin/timetravel/controller/TimeTravelController.kt) for more information.

### Time travel plugin for IntelliJ IDEA and Android Studio

There is a more convenient tool for Android - time travel IDEA plugin. This can be used directly from IDE so there is no need to integrate any additional UI.

You will need to run the [TimeTravelServer](https://github.com/arkivanov/MVIKotlin/blob/master/mvikotlin-timetravel/src/androidMain/kotlin/com/arkivanov/mvikotlin/timetravel/server/TimeTravelServer.kt) in your Android app so the plugin could connect to it. Please refer to the [samples](https://github.com/arkivanov/MVIKotlin/tree/master/sample/todo-app-android) for more examples.

#### How to install

You can find the plugin in the IntelliJ IDEA [Marketplace](https://plugins.jetbrains.com/plugin/14241-mvikotlin-time-travel). It can be installed directly from IntelliJ IDEA or Android Studio. Please navigate to Settings -> Plugins -> Marketplace and type "MVIKotlin" in the search field.

#### Demo videos

Check out the video demonstrating the time travel IDEA plugin:

[![Debugging Android application with IntelliJ IDEA time travel plugin](https://img.youtube.com/vi/Tr2ayOcVU34/0.jpg)](https://youtu.be/Tr2ayOcVU34)

Check out the video demonstrating how you can export/import the time travel data using the IDEA plugin:

[![Export/import time travel data in Android with MVIKotlin IDEA plugin](https://img.youtube.com/vi/SIxfSgBkHS0/0.jpg)](https://youtu.be/SIxfSgBkHS0)

### Time travel client app for desktop

This is a standalone time travel client for desktop. It can connect to any application running the [TimeTravelServer](https://github.com/arkivanov/MVIKotlin/blob/master/mvikotlin-timetravel/src/darwinCommonMain/kotlin/com/arkivanov/mvikotlin/timetravel/server/TimeTravelServer.kt). It can be an Android, or an iOS, or even macOS app.

Check out examples of [iOS app](https://github.com/arkivanov/MVIKotlin/tree/master/sample/todo-app-ios) and [Android app](https://github.com/arkivanov/MVIKotlin/tree/master/sample/todo-app-android) running `TimeTravelServer`.

<img src="media/time-travel-client-app.png" width="512">

#### How to install

The time travel client application for desktop is not published yet so you will need to build and run it from [sources](/home/aivanov/dev/workspace/MVIKotlin/mvikotlin-timetravel-client/app-desktop). To run the client, run the following command (the minimum JDK version 11 is required):

```
./gradlew :mvikotlin-timetravel-client:app-desktop:run
```

##### Building a distributable version

The time travel client for desktop is implemented using [Compose for Desktop](https://github.com/JetBrains/compose-jb). So it is possible to assemble a distributable version. Please read the corresponding [documentation page](https://github.com/JetBrains/compose-jb/tree/master/tutorials/Native_distributions_and_local_execution).

[Overview](index.md) | [Store](store.md) | [View](view.md) | [Binding and Lifecycle](binding_and_lifecycle.md) | [State preservation](state_preservation.md) | [Logging](logging.md) | Time travel

#### Demo videos

Check out the video demonstrating the time travel client app for macOS:

[![Debugging iOS application using MVIKotlin time travel client app](https://img.youtube.com/vi/rj6GwA2ZQkk/0.jpg)](https://youtu.be/rj6GwA2ZQkk)

repository: sellmair/MVIKotlin

repo_name: sellmair/MVIKotlin


text:
# Setup Redis on your System

There are many ways to install and use redis. Here are the ways we do it in this guide:

- Using a Virtual Machine (aka remote host)
- macOS
- Linux (debian systems)
- Windows
- Docker

## Using a Virtual Machine via [this blog post](https://www.codingforentrepreneurs.com/blog/remote-redis-servers-for-development)

__Install docker__
```
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
```

__Run redis__
```
docker run --restart always -d -p 6379:6379 redis
```

__Get remote IP Address__ (if you don't already have it)
```
REMOTE_IP=$(ip -4 addr show eth0 | grep -oP '(?<=inet\s)\d+(\.\d+){3}')
echo $REMOTE_IP
```

__Your redis url__

```
echo "$REMOTE_IP:6379"
```
Copy your $REMOTE_IP and use it on your local computer here to use below

_ping it_
```
echo PING | nc <IP_ADDRESS> 6379
```
Notice we're not using `redis-cli` because we do not have it installed.

## macOS
### 1. Install redis via [homebrew](https://brew.sh) [formula](https://formulae.brew.sh/formula/redis)
```
brew update
brew install redis
```

### 2. Start Redis
```
brew services start redis
```

### 3. Verify Redis

```
redis-cli ping
```
> Do you see `pong` as a response? If so, you have redis installed.

### 4. Verify Redis without `redis-cli`
```
echo PING | nc <IP_ADDRESS> 6379
```

## Linux (debian)

### 1. Install via apt
```
sudo apt update
sudo apt install redis-server -y
```

### 2. Verify Redis

```
redis-cli ping
```
> Do you see `pong` as a response? If so, you have redis installed.

### 4. Verify Redis without `redis-cli`
```
echo PING | nc <IP_ADDRESS> 6379
```

## Windows

Install using [memurai](https://www.memurai.com/) or docker (below).

## Using Docker

### 1. Using a pre-built image
```
docker run -it --rm -p 6379:6379 redis
```
> This is the official docker image for redis.

or

### 2. Using a Dockerfile (aka custom build)__

__`Dockerfile`__
```dockerfile
FROM redis

CMD ["redis-server"]
```

__build it__
```
docker build  -t my-redis  -f Dockerfile .
```

__run it__
```
docker run -it --rm -p 6379:6379 my-redis
```

__ping it__
```
echo PING | nc <IP_ADDRESS> 6379
```
> Notice we're not using `redis-cli` because we do not have it installed.

repository: afaleti/python-website-scraper

path: /setup/Setup Redis.md

filename: Setup Redis.md

repo_name: afaleti/python-website-scraper


text:
# nvm-latests
[nvm](https://github.com/creationix/nvm) is an awesome tool to keep control over several instances of [iojs](http://iojs.org) and [Node](http://nodejs.org) on your computer.

The only problem I've found with nvm is that it doesn't update itself and it's hard to see if there's new version, or what the latests version is.

This simple (!) tool solves that.

You can got to http://nvm-latest.herokuapp.com and copy the current url, or you can just go:
´´´bash
	curl http://nvm-latest.herokuapp.com/script | bash
´´´

or using Wget:

´´´bash
wget -qO- http://nvm-latest.herokuapp.com/script | bash
´´´
# Principle
I will not store the script but rather get it from github.
I will cache the latests tag from github for 24 h.

# kanban
Here's what I'm doing right now

## Todo
- deploy to Heroku
- latests version is stored (where?) and only looked up once per day

## Doing
- /script returns the raw script for curl-ling scenarios

## Done
- Home page has copy-button for the script to get it on clipboard
- Home page has copy-button for the script to get it on clipboard with sudo-prefix
- Home page has link for the latests version
- add Makefile
- add config object
- set up inital structure of project

repository: marcusoftnet/nvm-latests

repo_name: marcusoftnet/nvm-latests


text:
# BirthdayWeather demo Xamarin app
This is one of the demo apps I built and used in my CodeMash 2019 Xamarin talk.

## Pre-requisites
The weather data used in this app comes from the Dark Sky API. If you want to use this code you will need a [Dark Sky API key](https://darksky.net/dev). Once you have your key be sure to add it to the `DarkSkyWeatherService` class on [line 15](https://github.com/edsnider/birthdayweather-app/blob/master/BirthdayWeather/BirthdayWeather/Services/DarkSkyWeatherService.cs#L15).

repository: edsnider/birthdayweather-app

repo_name: edsnider/birthdayweather-app


text:
# Hooking in with events

By default, the [generated client factory](cli/generate-clientfactory.md) provides an `EventDispatchingCaller` to the generated client.
This caller makes it possible to listen for SOAP events:

- `\Phpro\SoapClient\Event\RequestEvent`
- `\Phpro\SoapClient\Event\ResponseEvent`
- `\Phpro\SoapClient\Event\FaultEvent`

You can subscribe your own listeners to the configured `EventDispatcher`. For example:

```php
class ResponseFailedSubscriber implements SubscriberInterface
{
    // implement interface
}

$dispatcher->addSubscriber(new ResponseFailedSubscriber());
```

This package ships with some default subscriber plugins:

- [Logger subscriber](event-subscribers/logger.md)
- [Validator subscriber](event-subscribers/validator.md)

repository: phpro/soap-client

gha_language: PHP

repo_name: phpro/soap-client


text:
# axe-core basic examples: Scripting

Go to the [GitHub Playbook-Automation published page](https://section508coordinators.github.io/Dev-Automation/)

## Tool: axe-core library: Scripting w/Selenium WebDriver

The scripts (JavaScript) in this project are meant to provide relatively simple examples, on which you can build, of how to use the axe-core accessibility engine for accessibility testing using Selenium WebDriver as well as both the Chrome and Firefox browser engines.

## Automated tools and rulesets

Because automated tools provide the tester with the efficiency of pass/fail conclusions, it is critical to thoroughly assess that logic – also known as its ***rules***. A tool’s collective rules or ruleset should be assessed to determine its accuracy as well as the degree to which its logic aligns with your organization’s ***target accessibility standard***. In the case of DHS, the target accessibility standard to which the automated tools on this site are compared are as follows:

#### DHS target accessibility standard

- [The Section 508 ICT Testing Baseline for Web (October 2020 | version 3.0)](https://section508coordinators.github.io/ICTTestingBaseline/) (ICT Baseline)
- [Trusted Tester: Section 508 Conformance Test Process for Web (June 2019 | version 5.0)](https://section508coordinators.github.io/TrustedTester/) (TTv5)

#### Ruleset assessments and recommended rules

Not all automated tool rulesets on the market perfectly align with the pass/fail success criteria as expressed by the DHS standard. However upon analysis, DHS OAST has identified specific rules, for specific vendor accessibility ruleset libraries, that provide value in identifying accessibility to the DHS Standard.

Those analyses of vendor accessibility rulesets and the OAST ruleset recommendations reside in the following folder on this site: https://github.com/Section508Coordinators/Dev-Automation/tree/master/rulesets.

## Technology requirements

These examples use the following technology stack:

- Nodejs 6+
- Git (Bash window is fine)
- Chrome browser version 59+
- Chrome WebDriver (use your version of Chrome)
- Firefox browser
- Firefox (Gecko) WebDriver
- Selenium WebDriver
- axe-WebDriverJs
- JavaScript

## Setup

Perform the following steps to setup your environment to run the examples:

1. Install Nodejs 6+
2. Install Git
3. Install Selenium Webdriver: `npm install selenium-webdriver --no-save`
4. Install axe-core webdriverjs and its dependencies: `npm install @axe-core/webdriverjs`
5. Running the examples, as is, will require you to have the Firefox and Chrome browsers installed on the machine. Also, you will need to install the corresponding WebDrivers as follows:
   1. **Chrome**
      1. Requires Chrome browser version 59+
      2. Install the Chromedriver version that corresponds to your Chrome browser version and ensure its file system location is in your Windows PATH statement
   2. **Firefox**
      1. Requires any relatively current Firefox browser
      2. Install Gecko driver and ensure it is in your PATH statement

## Usage/Syntax

In a Git Bash window, run: `node <script_name>`

In response, the script 1 will:

1. Invoke a visual instance of Firefox containing a test page. In the case of script 2, a headless Chrome is invoked which will cause a momentary Chrome UI to open and when the test is done, close.
2. When testing is complete for either script, a summary of the axe-core accessibility test results will be written to the command window.

### Example scripts

- Script 1: Example of a basic script that calls the *Firefox* browser engine
  - `01_axe-core_BasicScript.js`
- Script 2: Example of a basic script that calls the *Chrome* headless engine
  - `02_axe-core_BasicScript.js`

## More Information

See the resources below for more information that may be helpful in further customizing the examples for your organization's use:

#### Axe-core and Selenium WebDriver

More information on axe-core accessibility scripting to the Selenium WebDriverJS can be found at the [Deque GitHub WebDriverJs](https://github.com/dequelabs/axe-core-npm/tree/develop/packages/webdriverjs) repository.

#### Axe-core accessibility rules

A full list of axe-core rules (test logic) can be found here: https://github.com/dequelabs/axe-core/blob/develop/doc/rule-descriptions.md.

#### Full API reference for developers

More comprehensive guidance on the axe-core engine can be found in the [Axe JavaScript Accessibility API](https://github.com/dequelabs/axe-core/blob/develop/doc/API.md).

01/30/2021 | 09:27p

repository: Globalesm/Dev-Automation

repo_name: Globalesm/Dev-Automation


text:
---
date: 2020-05-02
title: "Linting files with Vale: an introduction"
author: Deanna
excerpt: One technical writer's journey in learning more about testing documentation.
---
My journey into learning more about testing documentation began a few months ago. I joined the Write the Docs [Slack](https://www.writethedocs.org/slack/) group because I wanted to learn more about technical writing trends and tools. As I learned more about technical writing tools and processes, one term came up a few times: docs as code.

A quick Google search told me that docs as code essentially means:

* Writing your documentation with the same tools you do code
* Writing your documentation files in a markup language like Markdown or Asciidoc
* Storing your doc files in a version control system, like Git
* Building and deploying a documentation site
* Testing your documentation

I work on a team that uses the docs as code workflow to some extent, so I was familiar with writing documentation in Markdown and using Git for version control, and somewhat familiar with building and deploying a documentation site, but I had no experience with testing documentation. So I decided to learn more about it.

---

If you read my previous [post](https://technicaltidbits.net/journal/test-your-docs/), technical writers and other documentation specialists use **linters** to test their documentation.

>Linters for code look for syntax errors, code smells, typos, and other bugs. Linters for documentation look for style errors, spelling and punctuation errors, or broken links.

Two popular linters I've learned about are write-good and Vale. Both are useful for writers looking to make sure that their documentation has a consistent style, consistent tone, and no spelling/grammar errors.

If you're interested in using Vale, you can either use the desktop application, Vale Server, or the command-line interface (CLI) for linting. I personally like Vale because you can customize it to use third-party styles or even create your own rules specific to your company's brand guidelines.

Because docs as code and testing documentation are growing in popularity, I thought it'd be useful to write a three-part series that teaches the basics of using Vale. This series will focus on the CLI, not the application.

By the end of the series, you'll know how to install, configure, and lint your own documentation files. Look out for part one soon!

## Further reading

### Docs as code

* Tom Johnson's blog post about [docs as code tools](https://idratherbewriting.com/learnapidoc/pubapis_docs_as_code.html)
* Anne Gentle's book, [Docs Like Code](https://www.amazon.com/dp/B0784ZJWSR/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1)

### Testing documentation

* More about testing documentation from [Write the Docs](https://www.writethedocs.org/guide/tools/testing/)

### Vale

* [Vale CLI website](https://github.com/errata-ai/vale)

gha_language: Vue


text:
# React, Redux and Material UI Introduction

## Project startup

We'll use the `create-react-app` archetype:

```
npx create-react-app [APP NAME]
npm install
npm start
```

The latter will invoke `react-scripts` to create a development build, watch files for changes, as well as start a server on port 3000, which you can check out in your browsers.

## Project structure

The following files are of interest in the initial project structure:

### package.json

As with any node managed project, `package.json` is where you will put all your dependencies and build scripts.

### src/index.js

This is the root of the project, the file invoked to start the project.

```
ReactDOM.render(<App />, document.getElementById('root'));
```

This line renders the `App` component in the element called `root` of the initial DOM, which you can inspect at `public/index.html`. Notice that file is outside the `src` folder, so the expectation would be not to change it unless absolutely necessary.

### src/App.js

This is a [component](https://reactjs.org/docs/react-component.html). It extends `React.Component` and must implement the `render` method.

The following methods can also be implemented to control the component's lifecycle:

- `componentDidMount` - will trigger after the component was inserted into the DOM; typically all asynchronous processing should be started here
- `componentDidUpdate` - will trigger after the component has been redrawn due to change detection;
- `componentWillUnmount` - will trigger before the component's DOM presence is removed; typically any cleaning needed should be placed here
- `componentDidCatch` - will trigger when an uncaught error is thrown by this component; all components should implement this with an appropriate error handler

The component also has a class member `props` that contains all attributes passed to the component.

The component can have a regular stylesheet attached, simply by importing it.

## Routing

Four steps to enable routing:

First, create the routes:

```javascript
export default [
    {
        path: "/",
        component: Home,
        exact: true,
    },
    {
        path: "/page/:page",
        component: Page,
        exact: true,
    }
]
```

Then, wrap the entry point component in the `BrowserRouter`:

```javascript
import { BrowserRouter as Router } from "react-router-dom";

...

        <Router>
            <App />
        </Router>
```

In the entry point component, render the route outlet:

```javascript
import { Route, Switch } from 'react-router-dom';
import routes from "../../routes";
    ...

    <Switch>
          {routes.map(route => <Route key={route.path} {...route} />)}
    </Switch>

```

When we want to navigate to a path:

```javascript
import { Link } from 'react-router-dom';

...

    <Link to={'/my/path'}>My Link</Link>
```

If we want to get the route parameters, we can find them inside the React Component class, in `this.props.match.params.myParam`.

## JSX

The content returned by the `render` method in `App.js` is somewhat unusual.

Indeed, that's not regular javascript, nor is it regular HTML. That's React's templating language, called [JSX](https://reactjs.org/docs/introducing-jsx.html).

This language makes it easy to compose the DOM depending on the business logic, by using all the normal javascript control structures and language aids, but manipulating objects instead of strings.

What React does so far is help us manipulate templates and box components to be easily (re)usable.

## Enter Redux

### Why Redux?

The philosophy of Redux is "single source of truth".

You can view the application as a state machine.

A classical application is represented by a number of components collaborating in the sens of sharing information via parameters and services.
A few usual features:

- child components receive essential business arguments from parent components or from DI (e.g. access to services)
- child components emit events to parent components, who are responsible to handle them
- each component needs to be tested in an environment, or context

This is an example of such behavior:

![No Redux](http://www.plantuml.com/plantuml/proxy?src=https://raw.github.com/deroude/reacttraining/master/uml/no_redux.puml)

Redux brings in a different philosophy:

- The state of all application features (e.g. components) is maintained in a single, immutable, structure ("single source of truth") called __state__
- Since the state is immutable, it cannot be altered, it can only be replaced, which guarantees there is no ambiguity as to the order of operations.
- To move to the next state, we need to __dispatch__ an __action__, which is characterized by an action type and a set of arguments
- A __reducer__ is a [pure function](https://medium.com/javascript-scene/master-the-javascript-interview-what-is-a-pure-function-d1c076bec976)
  - Given the same input, will always return the same output
  - Produces no side effects

A call to an API, for example, is __not__ a pure function, because it fails both conditions: two calls to the same API may very well return a different response, even if we made them synchronous, which we don't; also, the very reason why we send a POST request for example is to produce side effect.

However, the condition applies strictly to the reducer function, this doesn't mean that Ajax calls cannot be made using Redux. For example, if the call to the API is one reducer and the response from the API is another reducer, then we are fine, both are pure functions. However, we need to connect them. For this, there are a number of implementations that come to the rescue: in this example we use `redux-thunk` which simply allows the reducer to return a function instead of a value (which still abides by the pure function law).

![Redux](http://www.plantuml.com/plantuml/proxy?cache=no&src=https://raw.github.com/deroude/reacttraining/master/uml/redux.puml)

### Writing Redux

While some Redux implementations are very opinionated (e.g. NgRx for Angular), React Redux is rather loose in its recommendations of code structure.

So, the current arrangement is based more on [related literature](https://hackernoon.com/my-journey-toward-a-maintainable-project-structure-for-react-redux-b05dfd999b5) than on concrete guidelines from the creators.

The main principles are:

- put everything related to a business feature in a single file (called __duck__), including:
  - action types (prefix them with the feature name: `LOADING: 'PROGRESS/LOADING'`)
  - initial state
  - reducers, in fact a single reducer function taking as arguments the current state and the action dispatched; the individual reducer operations should be branches of a `switch` on the action type
  - action constructors: the point is to hide as much of Redux as possible from the rest of the application; so, instead of dispatching the actual action object, it's more elegant to build the action by using an exposed function.
  - getters: again, the point is to hide Redux from the world; instead of always accessing the state object and navigating to the correct attribute, we can expose the attribute directly through getters.

But wait, we said there is ONLY ONE state -- yet all these "ducks" have their own state. To comply with the Redux principle, we need to `combine` them in one state:

```javascript
import { createStore, applyMiddleware, combineReducers } from 'redux'
import thunk from 'redux-thunk';

import myDuck1 from './myDuck1';
import myDuck2 from './myDuck2';

export default (initialState) =>
    createStore(combineReducers(
        {
            myDuck1,
            myDuck2
        }
    ), initialState, applyMiddleware(thunk));
```

And finally, the createStore(state) method will be used at the start of our application (the entry point):

```javascript
import { Provider as ReduxProvider } from "react-redux";
import createStore from './ducks';

const store = createStore(window.REDUX_DATA);

const jsx = (
    <ReduxProvider store={store}>
        <Router>
            <App />
        </Router>
    </ReduxProvider>
);
```

### Using Redux

Components can be divided into "dumb" and "smart", or "components" and "containers", where "dumb" components simply render the exact same way each time when they are invoked with the same parameters, whereas containers perform some data fetching before completing their rendering, which means their final composition may vary -- seems remarkably easy to compare with the pure function concept we discussed earlier.

With Redux, "smart" components will likely need to be connected to the application state, to dispatch actions and to receive updates from the state stream. To do that, React needs us to `connect` them:

```javascript
import { connect } from 'react-redux';
import { actions as myDuckActions, myDuckItemGetter } from '../ducks/myduck';

...

const mapStateToProps = (state) => {
    return {
        myDuckItem:myDuckItemGetter(state)
    };
};

const mapDispatchToProps = (dispatch) => {
    return {
        myDuckAction: () => dispatch(myDuckActions.action()),
    }
};

export default connect(mapStateToProps, mapDispatchToProps)(MyComponent);
```

What these do is:

- import the action constructors and the getters from the respective duck
- inject the state and the dispatch method -- this is in fact split into two steps
  - the first is to create a convenient pair of methods that expose to the Component the state items and the Redux actions; we call those `mapStateToProps` and `mapDispatchToProps`, because we commonly call `props` the parameters that every (dumb) component receives, such as title, text, or width.
  - the second step is where the injection takes place: our React Component no longer exports its own class -- instead, it exports the result of the React Redux function call (or closure) `connect`.

## Material UI

The thing React is best at is boxing UI functionality into reusable components. What more can we want?
Well, two things actually:

- Theming: React is not so good at working with styles -- for one thing, Create React App doesn't come with a CSS prepreprocessor, like LESS or SASS, and since without ejecting we have no access to Webpack (and Babel), we also cannot roll our own solution easily. So, we would like to have a way to encapsulate and reuse styles across components.
- Also, we'd like some basic components ready to go at the start of the development (layout grid, button, dialog, menu bar, drawer, progress bar) - the more, the merrier

This is where any one of the competing component frameworks come into play. It appears that the most popular right now is [Material UI](https://material-ui.com/getting-started/installation/).

We'll just add it to the dependency list. To complete the dependency summary, we need to import the font into the root stylesheet, `index.css`.

```css
@import url('https://fonts.googleapis.com/css?family=PT+Sans');
```

That makes sure the `PT Sans` familiy (or any other you choose) will be available to the entire project.

The next step is create the baseline, that will be extended by every component.
That's `withRoot.js`.

First, we [create a theme](https://material-ui.com/customization/themes/), by extending the main theme with custom features:

```javascript
const theme = createMuiTheme({
  palette: {
    primary: {
      light: grey[300],
      main: grey[700],
      dark: grey[900],
    },
    secondary: {
      light: green[300],
      main: green[500],
      dark: green[700],
    },
  },
  typography:{
    fontFamily:['PT Sans']
  }
});
```

Then we create the theme injector that will wrap all of our Components:

```javascript
function withRoot(Component) {
  function WithRoot(props) {
    return (
      <MuiThemeProvider theme={theme}>
        <CssBaseline />
        <Component {...props} />
      </MuiThemeProvider>
    );
  }
  return WithRoot;
}
```

And then we use it in the Components:

```javascript
import PropTypes from 'prop-types';
import { withStyles } from '@material-ui/core/styles';
import withRoot from '../withRoot';

...

MyComponent.propTypes = {
    classes: PropTypes.object.isRequired,
};

export default withRoot(withStyles(styles)(MyComponent));
```

`PropTypes` is just a way to check a type for required attributes (in our case `classes`) - a poor man's typing.

`withStyles` links a style sheet to the component, by adding the `classes` property.

`withRoot` adds the previously created baseline theme to the Component.

A few additional notes on Material UI:

- You need to import every component you want to use separately
- You need to import every icon you use separately -- you can find them [here](https://material.io/tools/icons/?style=baseline)
- Material components you want to use often:
  - Button
  - Typography
  - Card
  - Grid

repository: deroude/reacttraining

repo_name: deroude/reacttraining


text:
---
speaker: "Tirthankar Bhattacharyya and E.K. Narayanan (IISc Mathematics)"
title: "Shining a Hilbertian lamp on the polydisc"
date: "24 October, 2014"
time:  "2:15 – 4:30 pm (with a 15 minute break at 3:15)"
venue: "LH-1, Mathematics Department"
series: "Eigenfunctions Seminar"
---

Abstract: See [https://drive.google.com/file/d/0Bx6ccM3uL81GNHZqQUtic3g5TndEMmF3Y0JKSDl3LTBTeFU4/view?usp=sharing](https://drive.google.com/file/d/0Bx6ccM3uL81GNHZqQUtic3g5TndEMmF3Y0JKSDl3LTBTeFU4/view?usp=sharing).

repository: siddhartha-gadgil/DeptWeb

gha_language: HTML

repo_name: siddhartha-gadgil/DeptWeb


text:
# Registration test

Some outputs just to develop data loader for DTI
See [https://github.com/lindenmp/antsDTOrientationTests] for details.

## Registration output

Output files for a single HCP subject (100307) are stored here as nifti images

`100307ToTemplate_{V1,V2,V3}Deformed.nii.gz` - eigenvectors
`100307ToTemplate_{L1,L2,L3}Deformed.nii.gz` - eigenvalues

repository: cassianobecker/dnn

repo_name: cassianobecker/dnn


text:
### [CVE-2019-5467](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-5467)
![](https://img.shields.io/static/v1?label=Product&message=GitLab%20CE%2FEE&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Vulnerability&message=Cross-site%20Scripting%20(XSS)%20-%20Stored%20(CWE-79)&color=brighgreen)

### Description

An input validation and output encoding issue was discovered in the GitLab CE/EE wiki pages feature which could result in a persistent XSS. This vulnerability was addressed in 12.1.2, 12.0.4, and 11.11.6.

### POC

#### Reference
- https://hackerone.com/reports/526325

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

repository: trickest/cve

branch_name: refs/heads/main

repo_name: trickest/cve


text:
# Contributing

We welcome all contributions!
See [CONTRIBUTING.md](https://github.com/Uma-Tech/parrot/blob/develop/CONTRIBUTING.md)
if you want to contribute.
You can start with [issues that need some help](https://github.com/Uma-Tech/parrot/issues)
right now.


text:
# `autogoal.utils.ResourceManager`

> [📝](https://github.com/autogal/autogoal/blob/master/autogoal/utils/_resource.py#L9)
> `ResourceManager(self, time_limit=300, memory_limit=4294967296)`

Resource manager class.

##### Parameters

- `time_limit: int`: maximum amount of seconds a function can run for (default = `5 minutes`).
- `ram_limit: int`: maximum amount of memory bytes a function can use (default = `4 GB`).

##### Notes

- Only one function may be restricted at the same time.
  Upcoming updates will fix this matter.
- Memory restriction is issued upon the process's heap memory size and not
  over total address space in order to get a better estimation of the used memory.
### `get_used_memory`

> [📝](https://github.com/autogoal/autogoal/blob/master/autogoal/utils/_resource.py#L85)
> `get_used_memory(self)`

Returns the amount of memory being used by the current process.
### `run_restricted`

> [📝](https://github.com/autogoal/autogoal/blob/master/autogoal/utils/_resource.py#L100)
> `run_restricted(self, function, *args, **kwargs)`

Executes a given function with restricted amount of
CPU time and RAM memory usage.
### `set_memory_limit`

> [📝](https://github.com/autogoal/autogoal/blob/master/autogoal/utils/_resource.py#L32)
> `set_memory_limit(self, limit)`

Set the memory limit for future restricted functions.

If memory limit is higher or equal than the current OS limit
then it won't be changed.
### `set_time_limit`

> [📝](https://github.com/autogoal/autogoal/blob/master/autogoal/utils/_resource.py#L57)
> `set_time_limit(self, limit)`


text:
# WordPress Headless Starter Theme

![WordPress Headless Starter Theme](screenshot.png)

This lightweight theme is designed for using WordPress as  headless cms, it can be used with any cms framework.

## Installation

Upload your theme to `wp-content/themes/your-theme` and activate it.

In `wp-config.php` add this 2 lines.

```php
define('APP_ORIGIN', '*'); // this will helps you define Access-Control-Allow-Origin.
define('APP_FRONTEND', 'https://localhost:3000'); // this will helps you making the preview button in editor works.
```

## Requirements

- [PHP](http://php.net/) >= 7.3
- [WordPress](https://wordpress.org/) >= 5.0

## Directory structure

```
wp-content/themes/your-theme
├── app/
│   ├── api/                       # API folder where you can make custom API endpoints.
│   │   └── example.php            # Example API endpoint.
│   ├── core/                      # Some functions to adjust the backend
│   │   ├── admin.php
│   │   ├── assets.php
│   │   ├── core.php
│   │   ├── cors.php
│   │   ├── gutenberg.php
│   │   └── log.php
│   ├── inc/                       # Plugins Folder.
│   │   └── carbon-fields/         # Carbon Fields Folder.
│   ├── setup/                     # Register WordPress menus, post types etc.
│   │   ├── carbon-fields/
│   │   │   ├── post-meta.php
│   │   │   ├── term-meta.php
│   │   │   ├── theme-options.php
│   │   │   └── user-meta.php
│   │   ├── menus.php
│   │   ├── post-types.php
│   │   ├── taxonomies.php
│   │   └── theme-support.php
│   ├── carbon-fields.php           # Register Carbon Fields actions and filters.
│   └── hooks.php                   # Register your actions and filters here.
├── languages/                      # Language files.
├── functions.php                   # Bootstrap theme.
├── screenshot.png                  # Theme screenshot.
├── style.css                       # Theme stylesheet.
└── ...
```

## Carbon Fields

Carbon Fields are deactivated by default, since not eveyone use it.
if you want to activate it head to `function.php` and edit this line.

```diff
// (Optional) Register Carbon Fields.
- // require_once  'app/carbon-fields.php';
+ require_once  'app/carbon-fields.php';
```

## Credits

This theme stater is heavly inspired by:

- [wpemerge-theme by htmlburger](https://github.com/htmlburger/wpemerge-theme).
- [headless-wp-starter by Postlight](https://github.com/postlight/headless-wp-starter).


text:
---
id: getting-started
title: Quick Start Guide
sidebar_label: Quick start guide
---

This page provides high-level instructions for adding Web Monetization to your
 website.

To monetize your site, you must:
1. Set up a web monetized receiver (wallet) for receiving payments.
2. Get your wallet's payment pointer.
3. Create a special `<meta>` tag that tells [Web Monetization providers](/#providers)
how to pay you.
4. Add the `<meta>` tag to each page of your website that you want to monetize.

For a more detailed look at web monetizing your site, see the
[Web Monetization explainer](explainer.md#getting-started).

## 1. Set up a web monetized wallet

Choose a [wallet that supports Web Monetization](ilp-wallets.md) and set up an account.
The wallet must support the Interledger Protocol (ILP).

## 2. Get your payment pointer

Find your payment pointer within your wallet and copy it.

### Example payment pointer
```html
$wallet.example.com/alice
```

## 3. Create your meta tag

Create your `<meta>` tag by using the [Meta Tag Generator](/meta-tag) or by
following the example below.

The tag's `name` is always `monetization`. The `content` is your payment
pointer.

### Example meta tag
```html
<meta
  name="monetization"
  content="$wallet.example.com/alice">
```

## 4. Add the meta tag to your website

Copy your `<meta>` tag and add it to the `<head>` section of each page you want
to monetize.

> Web Monetization only works on secure pages served over HTTPS.

### Example HTML

```html
<!doctype html>
<html>
  <head>
    <title>Web Monetized Site</title>
    <meta
      name="monetization"
      content="$wallet.example.com/alice">
  </head>
</html>
```

Congratulations! Your website is now web monetized.

repository: WietseWind/webmonetization

repo_name: WietseWind/webmonetization