text:
[![Join the chat at https://gitter.im/gocd/gocd](https://badges.gitter.im/Join%20Chat.svg)](https://gitter.im/gocd/configrepo-plugins?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)

# GoCD JSON configuration plugin

[![Build Status](https://travis-ci.com/tomzo/gocd-json-config-plugin.svg?branch=master)](https://travis-ci.com/tomzo/gocd-json-config-plugin)

**GoCD pipeline configuration as code**

This is a [GoCD](https://www.gocd.org) server plugin which allows to keep **pipelines** and **environments** configuration
in version control systems supported by GoCD (git, svn, mercurial, etc.).
See [this document](https://docs.gocd.org/current/advanced_usage/pipelines_as_code.html)
to find out what GoCD's configuration repositories are.

### Resources:

 * You can find an example repository at https://github.com/tomzo/gocd-json-config-example.git
 * Original GoCD [issue](https://github.com/gocd/gocd/issues/1133) on GitHub

## Quickstart

Make sure you are running at least `16.8.0` GoCD server.

### Installation

If you're using a GoCD version *older than 17.8.0*, you need to install the plugin in the GoCD server.

You'll have to drop `.jar` to `plugins/external` [directory](https://docs.gocd.org/current/extension_points/plugin_user_guide.html) in your server installation.
Plugin jars can be downloaded from [releases page](https://github.com/tomzo/gocd-json-config-plugin/releases).

### Add configuration repository

There is no UI to add configuration repositories so you'll have to edit the config XML.
You will need to add `config-repo` section within `config-repos`.
If `config-repos` does not exist yet then you add it **above first `<pipelines />` and `<artifactStores/>`**.

To add all configurations from git repository `https://github.com/tomzo/gocd-json-config-example.git`
a section like this should be added:

```xml
...
<config-repos>
   <config-repo pluginId="json.config.plugin" id="repo1">
     <git url="https://github.com/tomzo/gocd-json-config-example.git" />
   </config-repo>
</config-repos>
...
<artifactStores />
<pipelines />
...
```

## Configuration files

Using this plugin you can store any number of pipeline or environment
configurations without a versioned repository like git.

By default **pipelines** should be stored in `*.gopipeline.json` files
and **environments** should be stored in `*.goenvironment.json` files.

The file name pattern can be changed on plugin configuration page.

## Format

The pipeline configuration files should be stored in format *similar* to
one exposed by [GoCD API](https://api.gocd.org/current#get-pipeline-config).

The format of environment configuration files is much simpler,
you can find examples of correct environments at the [bottom](#environment).

### Format version

Please note that it is now recommended to declare `format_version` in each `*.gopipeline.json` or `*.goenvironment.json` file.
Version `3` will be introduced in GoCD 18.7.0
Currently it is recommended to declare consistent version in all your files:
```
{
  "format_version" : 3
}
```

# Syntax checking

Since `0.3.2` plugin is an executable and supports basic syntax checking.

## Usage with java installed

You need to download the `jar` from releases page and place it somewhere convenient.
For example `/usr/lib/gocd-json-plugin/json-config-plugin.jar`.
Then to validate your `gopipeline.json` file run something like:
```
java -jar /usr/lib/gocd-json-plugin/json-config-plugin.jar syntax mypipe.gopipeline.json
```

## Usage with `gocd` command-line helper

This is a product in development, so its command syntax is not stable and there are no distributed binaries yet.

The `gocd` tool is built in [golang](https://golang.org/) so you will need to familiarize yourself with how to set up your [go workspace](https://golang.org/doc/code.html#Workspaces).

Build the `gocd` binary:

```bash
go get github.com/gocd-contrib/gocd-cli
cd ${GOPATH:-~/go}/src/github.com/gocd-contrib/gocd-cli
./build.sh
```

Follow the steps on [https://github.com/gocd-contrib/gocd-cli](https://github.com/gocd-contrib/gocd-cli) to install the plugin jar to the correct place.

Then:

```bash
./gocd configrepo syntax -i json.config.plugin /path/to/your-pipeline.gopipeline.json
```

## Usage with IDE and docker

[IDE](https://github.com/ai-traders/ide) is a bash script, a cli wrapper around docker to help with running development tasks in docker.
You can install the `ide` script so that it is available on the PATH with:
```
sudo bash -c "`curl -L https://raw.githubusercontent.com/ai-traders/ide/master/install.sh`"
```

Add `Idefile` in your project with following content
```
IDE_DOCKER_IMAGE=tomzo/gocd-json-ide:<plugin-version>
```

To validate files run:
```
ide gocd-json syntax mypipe.gopipeline.json
```

Personally, I recommend the following project structure:

 * `gocd/` directory for all your GoCD configuration files.
 * `gocd/Idefile` file pointing which docker image can be used to validate configuration.

Then when working with gocd pipelines config, you can run from the root of your project
```
cd gocd
ide      # will open interactive shell
watch gocd-json syntax mypipe.gopipeline.json
```

## Usage with docker only

```
docker run -ti --rm --volume $(pwd):/ide/work tomzo/gocd-json-ide:<plugin-version> bash
```
Then you have an interactive shell as above.

#### Implementation note

This plugin leverages JSON message format used internally for GoCD server
and plugin communication.

GoCD pipeline and environment configuration has very deep structure. So instead
of reading a very long schema, below you can find examples of all configuration elements.

It is exactly like documented [here](https://github.com/tomzo/documentation/blob/1133-configrepo-extension/developer/writing_go_plugins/configrepo/version_1_0/config_objects.md)

It is **close to** [official xml schema](https://docs.gocd.org/16.1.0/configuration/configuration_reference.html)
and also [official JSONs in pipeline configuration API](https://api.gocd.org/current/#get-pipeline-config)

## JSON Configuration objects

1. [Environment](#environment)
1. [Environment variables](#environment-variables)
1. [Pipeline](#pipeline)
    * [Locking](#pipeline-locking)
    * [Mingle](#mingle)
    * [Tracking tool](#tracking tool)
    * [Timer](#timer)
1. [Stage](#stage)
    * [Approval](#approval)
1. [Job](#job)
    * [Property](#property)
    * [Tab](#tab)
    * [Many instances](#run-many-instances)
1. [Tasks](#tasks)
    * [rake](#rake)
    * [ant](#ant)
    * [nant](#nant)
    * [exec](#exec)
    * [fetch](#fetch)
    * [pluggabletask](#plugin)
1. [Materials](#materials)
    * [dependency](#dependency)
    * [package](#package)
    * [git](#git)
    * [svn](#svn)
    * [perforce](#perforce)
    * [tfs](#tfs)
    * [hg](#hg)
    * [pluggable scm](#pluggable-scm)
    * [configrepo](#configrepo)

# Environment

Configures a [GoCD environment](https://docs.gocd.org/current/configuration/managing_environments.html)

```json
{
  "name": "dev",
  "environment_variables": [
    {
      "name": "key1",
      "value": "value1"
    }
  ],
  "agents": [
    "123"
  ],
  "pipelines": [
    "mypipeline1"
  ]
}
```

# Environment variables

Environment variables is a JSON array that can be declared in Environments, Pipelines, Stages and Jobs.

Any variable must contain `name` and `value` or `encrypted_value`.

```json
{
  "environment_variables": [
    {
      "name": "key1",
      "value": "value1"
    },
    {
      "name": "keyd",
      "encrypted_value": "v12@SDfwez"
    }
  ]
}
```

# Pipeline

```json
{
  "format_version" : 1,
  "group": "group1",
  "name": "pipe2",
  "label_template": "foo-1.0-${COUNT}",
  "enable_pipeline_locking" : false,
  "parameters": [
    {
      "name": "param",
      "value": "parameter"
    }
  ],
  "mingle": {
    "base_url": "http://mingle.example.com",
    "project_identifier": "my_project"
  },
  "tracking_tool": null,
  "timer": {
    "spec": "0 15 10 * * ? *"
  },
  "environment_variables": [],
  "materials": [
    ...
  ],
  "stages": [
    ...
  ]
}
```

#### Referencing an existing template in a config repo:

```json
{
  "format_version" : 1,
  "group": "group1",
  "name": "pipe-with-template",
  "label_template": "foo-1.0-${COUNT}",
  "enable_pipeline_locking" : false,
  "template": "template1",
  "parameters": [
    {
      "name": "param",
      "value": "parameter"
    }
  ],
  "materials": [
    ...
  ]
}
```

Please note:

 * Pipeline declares a group to which it belongs

### Pipeline locking

Expected since GoCD v17.12, you need to use `lock_behavior` rather than `enable_pipeline_locking`.
```
"lock_behavior" : "none"
```

`lock_behavior` can be one of:
 * `lockOnFailure` - same as `enable_pipeline_locking: true`
 * `unlockWhenFinished` -
 * `none` - same `enable_pipeline_locking: false`

### Mingle

```json
{
    "base_url": "https://mingle.example.com",
    "project_identifier": "foobar_widgets",
    "mql_grouping_conditions": "status > 'In Dev'"
}
```

### Tracking tool

```json
{
  "link": "http://your-trackingtool/yourproject/${ID}",
  "regex": "evo-(\\d+)"
}
```

### Timer

```json
{
    "spec": "0 0 22 ? * MON-FRI",
    "only_on_changes": true
}
```

# Stage

```json
{
  "name": "test",
  "fetch_materials": true,
  "never_cleanup_artifacts": false,
  "clean_working_directory": false,
  "approval" : null,
  "environment_variables": [
    {
      "name": "TEST_NUM",
      "value": "1"
    }
  ],
  "jobs": [
    ...
  ]
}
```

### Approval

```json
{
  "type": "manual",
  "users": [],
  "roles": [
    "manager"
  ]
}
```

# Job

```json
{
  "name": "test",
  "run_instance_count" : null,
  "environment_variables": [],
  "timeout": 180,
  "elastic_profile_id": "docker-big-image-1",
  "tabs": [
     {
       "name": "test",
       "path": "results.xml"
     }
   ],
   "resources": [
    "linux"
  ],
  "artifacts": [
    {
      "source": "src",
      "destination": "dest",
      "type": "test"
    },
    {
      "type": "external",
      "id": "docker-release-candidate",
      "store_id": "dockerhub",
      "configuration": [
        {
          "key": "Image",
          "value": "gocd/gocd-demo"
        },
        {
          "key": "Tag",
          "value": "${GO_PIPELINE_COUNTER}"
        },
        {
          "key": "some_secure_property",
          "encrypted_value": "!@ESsdD323#sdu"
        }
      ]
    }
  ],
  "properties": [
    {
      "name": "perf",
      "source": "test.xml",
      "xpath": "substring-before(//report/data/all/coverage[starts-with(@type,\u0027class\u0027)]/@value, \u0027%\u0027)"
    }
  ],
  "tasks": [
    ...
  ]
}
```

### Artifacts

There are 3 types of artifacts recognized by GoCD. `Build` and `Test` artifacts are stored on the GoCD server.
The source and the destination of the artifact that should be stored on the GoCD server must be specified.

#### Build

```json
{
  "source": "src",
  "destination": "dest",
  "type": "build"
}
```

#### Test

```json
{
  "source": "src",
  "destination": "dest",
  "type": "test"
}
```

#### External

Artifacts of type `external` are stored in an artifact store outside of GoCD.
The external artifact store's configuration must be created in the main GoCD config. Support for external artifact store config to be checked in as yaml is not available.
The external artifact store is referenced by the `store_id`. The build specific artifact details that the artifact plugin needs to publish the artifact is provided as `configuration`.

```json
{
  "type": "external",
  "id": "docker-release-candidate",
  "store_id": "dockerhub",
  "configuration": [
    {
      "key": "Image",
      "value": "gocd/gocd-demo"
    },
    {
      "key": "Tag",
      "value": "${GO_PIPELINE_COUNTER}"
    },
    {
      "key": "some_secure_property",
      "encrypted_value": "!@ESsdD323#sdu"
    }
  ]
}
```

### Property

```json
{
  "name": "coverage.class",
  "source": "target/emma/coverage.xml",
  "xpath": "substring-before(//report/data/all/coverage[starts-with(@type,'class')]/@value, '%')"
}
```

### Tab

```json
{
      "name": "cobertura",
      "path": "target/site/cobertura/index.html"
}
```

### Run many instances

Part of **job** object can be [number of job to runs](https://docs.gocd.org/current/advanced_usage/admin_spawn_multiple_jobs.html)
```json
"run_instance_count" : 6
```
Or to run on all agents
```json
"run_instance_count" : "all"
```
Default is `null` which runs just one job.

# Materials

All materials:

 * must have `type` - `git`, `svn`, `hg`, `p4`, `tfs`, `dependency`, `package`, `plugin`.
 * can have `name` and must have `name` when there is more than one material in pipeline

SCM-related materials have `destination` field.

### Filter - blacklist and whitelist

All scm materials can have filter object:

 * for **blacklisting**:
```json
"filter": {
  "ignore": [
    "externals",
    "tools"
  ]
}
```

* for **whitelisting** (since Go `>=16.7.0`):
```json
"filter": {
 "whitelist": [
   "moduleA"
 ]
}
```

## Git

```json
{
  "url": "http://my.git.repository.com",
  "branch": "feature12",
  "filter": {
    "ignore": [
      "externals",
      "tools"
    ]
  },
  "destination": "dir1",
  "auto_update": false,
  "name": "gitMaterial1",
  "type": "git",
  "shallow_clone": true
}
```

## Svn

```json
{
  "url": "http://svn",
  "username": "user1",
  "password": "pass1",
  "check_externals": true,
  "filter": {
    "ignore": [
      "tools",
      "lib"
    ]
  },
  "destination": "destDir1",
  "auto_update": false,
  "name": "svnMaterial1",
  "type": "svn"
}
```

Instead of plain `password` you may specify `encrypted_password` with encrypted content
which usually makes more sense considering that value is stored in SCM.

## Hg

```json
{
  "url": "repos/myhg",
  "filter": {
    "ignore": [
      "externals",
      "tools"
    ]
  },
  "destination": "dir1",
  "auto_update": false,
  "name": "hgMaterial1",
  "type": "hg"
}
```

## Perforce

```json
{
  "port": "<IP_ADDRESS>:1666",
  "username": "user1",
  "password": "pass1",
  "use_tickets": false,
  "view": "//depot/dev/src...          //anything/src/...",
  "filter": {
    "ignore": [
      "lib",
      "tools"
    ]
  },
  "destination": "dir1",
  "auto_update": false,
  "name": "p4materialName",
  "type": "p4"
}
```

Instead of plain `password` you may specify `encrypted_password` with encrypted content
which usually makes more sense considering that value is stored in SCM.

## Tfs

```json
{
  "url": "url3",
  "username": "user4",
  "domain": "example.com",
  "password": "pass",
  "project": "projectDir",
  "filter": {
    "ignore": [
      "tools",
      "externals"
    ]
  },
  "destination": "dir1",
  "auto_update": false,
  "name": "tfsMaterialName",
  "type": "tfs"
}
```

Instead of plain `password` you may specify `encrypted_password` with encrypted content
which usually makes more sense considering that value is stored in SCM.

## Dependency

```json
{
  "pipeline": "pipeline2",
  "stage": "build",
  "name": "pipe2",
  "type": "dependency"
}
```

## Package

```json
{
  "package_id": "apt-repo-id",
  "name": "myapt",
  "type": "package"
}
```

## Pluggable SCM

```json
{
  "scm_id": "someScmGitRepositoryId",
  "destination": "destinationDir",
  "filter": {
    "ignore": [
      "dir1",
      "dir2"
    ]
  },
  "name": "myPluggableGit",
  "type": "plugin"
}
```

Since GoCD `>= 19.2.0` defining new pluggable materials that are not defined
in the GoCD server is supported.

```json
{
  "plugin_configuration": {
    "id": "plugin_id",
    "version": "1"
  },
  "configuration": [
    {
      "key": "url",
      "value": "git@github.com:tomzo/gocd-json-config-plugin.git"
    }
  ],
  "destination": "destinationDir",
  "filter": {
    "ignore": [
      "dir1",
      "dir2"
    ]
  },
  "name": "myPluggableGit",
  "type": "plugin"
}
```

## Configrepo

This is a convenience for shorter and more consistent material declaration.
When configuration repository is the same as one of pipeline materials,
then you usually need to repeat definitions in XML and in JSON, for example:

```json
...
  "materials": [
    {
      "url": "https://github.com/tomzo/gocd-json-config-example.git",
      "branch" : "ci",
      "type": "git",
      "name" : "mygit"
    }
  ],
...
```

And in server XML:
```xml
<config-repos>
   <config-repo pluginId="json.config.plugin" id="repo1">
     <git url="https://github.com/tomzo/gocd-json-config-example.git" branch="ci" />
   </config-repo>
</config-repos>
```

Notice that url and branch is repeated. This is inconvenient in case when you move repository,
because it requires 2 updates, in code and in server XML.

Using  **`configrepo` material type**, above repetition can be avoided,
last example can be refactored into:

```json
...
  "materials": [
    {
      "type": "configrepo",
      "name" : "mygit"
    }
  ],
...
```

Server interprets `configrepo` material in this way:

> Clone the material configuration of the repository we are parsing **as is in XML** and replace **name, destination and filters (whitelist/blacklist)**,
then use the modified clone in place of `configrepo` material.

# Tasks

Every task object must have `type` field. Which can be `exec`, `ant`, `nant`, `rake`, `fetch`, `plugin`

Optionally any task can have `run_if` and `on_cancel`.

 * `run_if` is a string. Valid values are `passed`, `failed`, `any`
 * `on_cancel` is a task object. Same rules apply as to tasks described on this page.

### Exec

```json
{
    "type": "exec",
    "run_if": "passed",
    "on_cancel" : null,
    "command": "make",
    "arguments": [
      "-j3",
      "docs",
      "install"
    ],
    "working_directory": null
}
```

### Ant

```json
{
  "build_file": "mybuild.xml",
  "target": "compile",
  "type": "ant",
  "run_if": "any",
  "on_cancel" : null,
}
```

### Nant

```json
{
  "type": "nant",
  "run_if": "passed",
  "working_directory": "script/build/123",
  "build_file": null,
  "target": null,
  "nant_path": null
}
```

### Rake

```json
{
  "type": "rake",
  "run_if": "passed",
  "working_directory": "sample-project",
  "build_file": null,
  "target": null
}
```

### Fetch

#### Fetch artifact from the GoCD server

```json
{
   "type": "fetch",
   "artifact_origin": "gocd",
   "run_if": "any",
   "pipeline": "upstream",
   "stage": "upstream_stage",
   "job": "upstream_job",
   "is_source_a_file": false,
   "source": "result",
   "destination": "test"
 }
```

#### Fetch artifact from an external artifact store

```json
{
   "type": "fetch",
   "artifact_origin": "external",
   "run_if": "any",
   "pipeline": "upstream",
   "stage": "upstream_stage",
   "job": "upstream_job",
   "artifact_id": "upstream_external_artifactid",
   "configuration": [
     {
       "key": "DestOnAgent",
       "value": "foo"
     },
     {
       "key": "some_secure_property",
       "encrypted_value": "ssd#%fFS*!Esx"
     }
   ]
 }
```

### Plugin

```json
{
  "type": "plugin",
  "configuration": [
    {
      "key": "ConverterType",
      "value": "jsunit"
    },
    {
      "key": "password",
      "encrypted_value": "ssd#%fFS*!Esx"
    }
  ],
  "run_if": "passed",
  "plugin_configuration": {
    "id": "xunit.converter.task.plugin",
    "version": "1"
  },
  "on_cancel": null
}
```

# Contributing

Create issues and PRs if
 * something does not work as you expect it,
 * documentation is not good enough
 * you have questions about GoCD behavior with remote configuration

There has been a long effort to make it possible to store configuration in SCMs,
so obviously there will be some errors in lots of new code. Please file issues
here or ask on [gitter chat for config-repo plugins](https://gitter.im/gocd/configrepo-plugins).

## Versioning

We use semantic versioning.

If you are submitting a new feature then please run a major version bump by
```
./tasks.sh set_version 0.X.0
```

If you are submitting a fix, then do not change any versions as patch bump is made right after each release.

# License and Authors

License: Apache 2.0

Authors:
 * Tomasz Sętkowski<EMAIL_ADDRESS>

repository: nelsu/gocd-json-config-plugin

repo_name: nelsu/gocd-json-config-plugin


text:
## Notes about this fork

This is a fork of st, the original repo can be found here: [https://git.suckless.org/st/](https://git.suckless.org/st/)
The original st webpage is here: [https://st.suckless.org/](https://st.suckless.org/)

### Patches applied

* [Alpha](https://st.suckless.org/patches/alpha/) : This patch allows users to change the opacity of the background. Note that you need an X composite manager (e.g. compton, xcompmgr) to make this patch effective.
* [Scrollback](https://st.suckless.org/patches/scrollback/) : Scroll back through terminal output using Shift+{PageUp, PageDown} and Shift+MouseWheel.
* [Clipboard](https://st.suckless.org/patches/clipboard/) : This trivial patch sets CLIPBOARD on selection.
* [font2](https://st.suckless.org/patches/font2/) : This patch allows to add spare font besides default.
* [Fix Keyboard Input](https://st.suckless.org/patches/fix_keyboard_input/) : Add a few previously undefined keys.

##### Applying/Removing Patches
```
# Add custom patch
patch -Np1 -i patches/custom.diff
or
patch < patch.diff

# Remove st-alpha-201806-16-0.81 patch
patch -R patches/st-alpha-20180616-0.8.1.diff
```

## Requirements

In order to build st you need the Xlib header files.

## Installation

Edit config.mk to match your local setup (st is installed into
the /usr/local namespace by default).

Afterwards enter the following command to build and install st (if
necessary as root):

```bash
make clean install
```

## Running st

If you did not install st with make clean install, you must compile
the st terminfo entry with the following command:

```bash
tic -sx st.info
```

See the man page for additional details.

#### Keyboard
Action      | Key Combination
---         | ---
Copy        | `ctrl` + `shift` + `c`
Paste       | `ctrl` + `shift` + `v`
Zoom In     | `alt` + `shift` + `+`
Zoom Out    | `alt` + `shift` + `-`
Reset Zoom  | `alt` + `shift` + `0`
Scroll up   | `shift` + `page up`
Scroll down | `shift` + `page down`

#### Mouse
Scroll is implemented using [scroll](https://git.suckless.org/scroll/log.html)
Action | Modifier
---    | ---
Scroll |  `mouse wheel`

## Credits

* Forked from [https://st.suckless.org/](https://st.suckless.org/)
* Based on Aurélien APTEL<EMAIL_ADDRESS>bt source code.

license: MIT

repository: athostha/st

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: athostha/st


text:
# Soft Require

Checks to see if npm is installed and loads it, if not it throws a catchable error.

Soft require is a simple library that allows you to require an npm library that
may not be installed/available. This allows you to dynamically load npm libraries,
and catch the error. This module does two things:

1. It just wraps a require.resolve in a try catch, then returns the result of the require.
2. Enforces good practices (read: passes linting) for dynamically loading npm modules.

## Installation

From the command line, in the path of your project type in:

```bash
$ npm install --save safe-require
```

## In Your Code

To dynamically load npm libraries (code is included in repo as `example.js`):

```javascript
const softRequire = require('soft-require');

const libraries = ['chai', 'moasdf', 'mocha'];
const loaded = {};
const logger = console;

libraries.forEach((library) => {
  try {
    loaded[library] = softRequire(library);
  } catch (err) {
    logger.error(err.message);
  }
});

logger.info(`Loaded the following libraries successfully: ${Object.keys(loaded).join(', ')}`);
```

May your linting be successful and your libraries loaded dynamically.

## To Test

If you clone this repo, you can test with: `npm run test`

repository: holmok/soft-require

repo_name: holmok/soft-require


text:
# Helper Commands

- Python's binding.pry equivalent
```
import code; code.interact(local=locals())
```
- Create database migrations
```
python manage.py make_migrations
```
- Run database migrations
```
python manage.py migrate
```
- Django Shell Plus
```
python manage.py shell_plus
```
- Collect Static files
```
python manage.py collectstatic
```
- Running using sub directories [execute from repo root]
```
git subtree push --prefix task2/ heroku <branch>
```

repository: darth-dodo/meal-helper

gha_language: JavaScript

gha_license_id: MIT

repo_name: darth-dodo/meal-helper


text:
# Helm Operator (Flux) vs Helm

This document presents a comparison between [Helm 3](https://helm.sh/docs/) and [Helm Operator](https://docs.fluxcd.io/projects/helm-operator/en/latest/).

## Helm 3 features

The new version of Helm has numerous new features, but a few deserve highlighting here:

- Releases are stored in a new format (in Secrets created in the release's Namespace, not in ConfigMaps in the `kube-system` Namespace). See the example of such a Secret:

```
NAME                          TYPE
sh.helm.release.v1.redis.v1   helm.sh/release.v1
```

- There are no in-cluster components (such as Tiller)
- New version of [Helm charts](https://helm.sh/docs/topics/charts/)
- [Library charts](https://helm.sh/docs/topics/library_charts/) that are used primarily as a resource for other charts
- Experimental support for storing [Helm charts in OCI registries](https://helm.sh/docs/topics/registries/) is available for testing
- A [3-way strategic merge patch](https://helm.sh/docs/faq/#improved-upgrade-strategy-3-way-strategic-merge-patches) is now applied when upgrading Kubernetes resources
- Chart's supplied values can now be [validated](https://helm.sh/docs/faq/#validating-chart-values-with-jsonschema) against a JSON schema
- A number of small improvements have been made to make Helm more secure, usable, and robust

## Helm Operator features

Helm Operator is a [FluxCD](https://github.com/fluxcd/flux) extension that automates Helm charts in a GitOps manner.

See the features it provides:
- Declarative install, upgrade, and delete of the HelmRelease CR
- Pulling charts from any chart source:
    - Public or private Helm repositories over HTTP/S
    - Public or private Git repositories over HTTPS or SSH
    - Any other public or private chart source using one of the available Helm downloader plugins
- Allowing Helm values to be specified:
    - In-line in the HelmRelease resource
    - In external sources, such as ConfigMap and Secret resources, or a local URL
- Automated purging on release install failures
- Automated (optional) rollback on upgrade failures
- Automated image upgrades (Flux)
- Automated (configurable) chart dependency updates for Helm charts from Git sources on install or upgrade (Flux)
- Detection and recovery from Helm storage mutations (for example, a manual Helm release that conflicts with the declared configuration for the release)
- Parallel and scalable processing of different HelmRelease resources using workers
- Support for both Helm 2 and 3

## Pros and cons

In the following tabs, you can find pros and cons of the above solutions.

  Helm 3

:heavy_plus_sign: Is a more lightweight solution

:heavy_plus_sign: Provides new types of charts

:heavy_plus_sign: Does not need any in-cluster application

:heavy_plus_sign: Can be extended with the Helm Operator

:heavy_plus_sign: Does not need any CR to work

:heavy_minus_sign: Does not provide automated processes

:heavy_minus_sign: Does not provide parallel executions

  Helm Operator

:heavy_plus_sign: Can automate many things and improve customer experience

:heavy_plus_sign: Provides scalable parallel processing

:heavy_plus_sign: User can still use vanilla Helm 3

:heavy_plus_sign: Can download a chart from any repository

:heavy_plus_sign: Can be extended with Flux

:heavy_minus_sign: Maintenance

:heavy_minus_sign: Increased resources consumption

:heavy_minus_sign: Helm Operator Pod has super admin permissions like Tiller (will be changed)

:heavy_minus_sign: New controller along with its CR

:heavy_minus_sign: It requires more implementation in Helm Broker than the Helm 3 approach

:heavy_minus_sign: Another dependency of Helm Broker, may require a feature flag

## Implementation

Read the sections below for more information about implementation details in Helm Broker.

### Helm 3

Helm 3 provides support for `v2` charts, so it shouldn't be a problem to implement it in the Helm Broker, even without adjusting the addons themselves.

To download the Helm 3 binary, use the following command:

```
curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
```

#### Migration

Helm 3 provides [CLI migration](https://github.com/helm/helm-2to3) along with the corresponding [documentation](https://helm.sh/docs/topics/v2_v3_migration/).

### Helm Operator

In order to use the Helm Operator approach, we may need to provide the following dependencies to our cluster:

- [Helm Operator](https://github.com/fluxcd/helm-operator/tree/v1.1.0/chart/helm-operator)
- [HelmRelease CR](https://raw.githubusercontent.com/fluxcd/helm-operator/1.1.0/deploy/crds.yaml)
- **Optional** [FluxCD](https://github.com/fluxcd/helm-operator/tree/master/chart/helm-operator) along with [memcached](https://github.com/memcached/memcached)

>**NOTE:** When working with FluxCD, use [FluxCTL](https://github.com/fluxcd/flux/releases/tag/1.19.0).

With this solution, the Helm Broker would need to create a HelmRelease CR in the provisioning process. It wouldn't need the Helm client anymore.

In order not to download the same charts two times, both by the Helm Broker and by the Helm Operator, the logic of downloading addons would need to be replaced by some other logic which could read only the `index.yaml` file and to create a proper response from its entries on the `/v2/catalog` endpoint.

#### Flux

Helm Operator provides a lot of GitOps features, but most of them can be used only when FluxCD is configured and installed on the cluster.

Using Flux, you can automate the process of delivering the applications' latest changes after their docker images are built. For example, the Helm Broker could mark the HelmRelease created within instance provisioning with such a label:
```
fluxcd.io/automated: "true"
```

There are also other labels which you can use to configure the automation process.

## Summary

In my opinion, implementing the Helm Operator's support in Helm Broker would require a lot of effort to adjust the current implementation, but automated processes and other features look interesting and I wouldn't rule them out to implement in the future.

It seems the best choice is to stay with plain Helm 3.

### Links

Explore the following links to expand your knowledge about above things:

- [Example app deploy with Helm 3](https://www.civo.com/learn/guide-to-helm-3-with-an-express-js-microservice)
- [Example app automation with Helm Operator and Flux](https://www.civo.com/learn/gitops-using-helm3-and-flux-for-an-node-js-and-express-js-microservice)
- [Explanation of the Helm 3 features](https://thenewstack.io/helm-3-is-almost-boring-and-thats-a-great-sign-of-maturity/)
- [Deep Dive: Flux the GitOps Operator for Kubernetes](https://www.youtube.com/watch?v=Fs_Oz-RzWWI)
- [Flagger - Kubernetes operator that automates the promotion of canary deployments](https://docs.flagger.app/)

repository: kyma-project/helm-broker

gha_language: Go

repo_name: kyma-project/helm-broker


text:
# clairvoyance

Some GraphQL APIs have disabled introspection. For example, [Apollo Server disables introspection automatically if the `NODE_ENV` environment variable is set to `production`](https://www.apollographql.com/docs/tutorial/schema/#explore-your-schema).

Clairvoyance allows us to get GraphQL API schema when introspection is disabled. It produces schema in JSON format suitable for other tools like [GraphQL Voyager](https://github.com/APIs-guru/graphql-voyager), [InQL](https://github.com/doyensec/inql) or [graphql-path-enum](https://gitlab.com/dee-see/graphql-path-enum).

## Installation

```
$ git clone https://github.com/nikitastupin/clairvoyance.git
$ cd clairvoyance
$ pip3 install -r requirements.txt
```

## Usage
### From Python interpreter
```
$ python3 -m clairvoyance --help
```

```
$ python3 -m clairvoyance -vv -o /path/to/schema.json -w /path/to/wordlist.txt https://swapi-graphql.netlify.app/.netlify/functions/index
```
### From Docker Image
```
$ docker run --rm nikitastupin/clairvoyance --help
```
```
# Assuming the wordlist.txt file is found in $PWD
$ docker run --rm -v $(pwd):/tmp/ nikitastupin/clairvoyance -vv -o /tmp/schema.json -w /tmp/wordlist.txt https://swapi-graphql.netlify.app/.netlify/functions/index
```

You can refer to 2nd half of [GraphQL APIs from bug hunter's perspective by Nikita Stupin](https://youtu.be/nPB8o0cSnvM) talk for detailed description.

### Which wordlist should I use?

There are at least two approaches:

- Use general English words (e.g. [google-10000-english](https://github.com/first20hours/google-10000-english)).
- Create target specific wordlist by extracting all valid GraphQL names from application HTTP traffic, from mobile application static files, etc. Regex for GraphQL name is [`[_A-Za-z][_0-9A-Za-z]*`](http://spec.graphql.org/June2018/#sec-Names).

## Support

In case of question or issue with clairvoyance please refer to [wiki](https://github.com/nikitastupin/clairvoyance/wiki) or [issues](https://github.com/nikitastupin/clairvoyance/issues). If this doesn't solve your problem feel free to open a [new issue](https://github.com/nikitastupin/clairvoyance/issues/new).

## Contributing

Pull requests are welcome! For major changes, please open an issue first to discuss what you would like to change. For more information about tests, internal project structure and so on refer to [Development](https://github.com/nikitastupin/clairvoyance/wiki/Development) wiki page.

branch_name: refs/heads/main


text:
---
abstract: This talk is a deep dive on authentication in REST Framework. We'll review
  the pros/cons of the 4 built-in options, discuss popular 3rd party packages, and
  implement a working solution from scratch with a custom user model, tokens, user
  registration, social auth, and more.
accepted: true
category: talk
date: 2018-10-16 11:30:00 -0500
difficulty: Intermediate
layout: session-details
permalink: /talk/finally-understand-authentication-in/
presenters:
- bio: 'William Vincent is a freelance software developer and the author of two books:
    [Django for Beginners](https://djangoforbeginners.com/) and [REST APIs with Django](https://restapiswithdjango.com/).
    He came to coding later in life (30s!) after working as an early employee at Quizlet.
    Since then he has worked at multiple early-stage startups in the Boston area and
    taught computer science at Williams College. He writes regularly at wsvincent.com.'
  company: ''
  github: ''
  name: William S. Vincent
  photo_url: '/static/img/speakers/william-s-vincent.jpg'
  twitter: wsv3000
  website: https://wsvincent.com/
published: true
room: 'Salon F-H'
sitemap: false
slides_url: ''
summary: ''
title: 'Finally Understand Authentication in Django REST Framework '
track: t1
video_url: ''
---

Traditional Django handles user authentication for us. REST Framework? Not so much. The abundance of choice is overwhelming and typically THE biggest obstacle for newcomers.

This talk is a deep dive on authentication in Django REST Framework. We'll start with an overview of HTTP and REST APIs before demonstrating how to implement the 4 built-in auth modes and their respective pros/cons. Special attention will be paid to common gotchas such as, Why do I need "both" TokenAuth and SessionAuth? What are JWTs?

Next we'll implement a real-world REST auth setup that includes user registration, password reset/confirm, social auth, and endpoints for sign up, log in, and log out. The third-party packages `django-rest-auth` and `django-allauth` will be used .

By the end of the talk attendees will understand the basics of REST authentication, the tradeoffs involved, and walk away with a working implementation to jumpstart their future projects.

gha_license_id: NOASSERTION


text:
#Week 4 : Minichat

##Presentation :
We had to create a basic __Minichat__ using Jquery.

##What's inside :
__index.html__ : I used 2 div, a textarea and a button.
__main.css__ : Only a few flex declarations to position everything.
__main.js__ : I used a click and a keypress(return) event to add p to the display div.
I also added a timeout to simulate the answer (taking from an array).

##How ?
Mostly JQuery + DOM


text:
# HacoPs
Hahndorf's awesome collection of PowerShell scripts.

Just a a bunch of random PowerShell scripts I wrote over time.

Nothing fancy here.

## Update-LECertificate.ps1

Meta script which uses some other PowerShell scripts and modules to update all Let's Encrypt certificates on a Windows Server.

## Set-NetworkProfileCategory.ps1

 In 'Network and Sharing Center' your networks are shown as 'Public', "Private' or 'Domain'
    You can change that with this script in all supported versions of Windows.

## New-DemoFtpSite.ps1

Shows how to set up IIS with a FTP site that uses IIS Manager Users
and a special account to run the FTP service.

## Invoke-SQL.ps1

Single file script to run a SQL command against a SQL Server

## Set-PathVariable.ps1

Correct way to add to the path environment variable on Windows systems. Blog post

## Disable-ServerDesktop.ps1

Changes Windows Server 2016 Full Installation to behave more like Server Core Installation

## Import-StackExchangeData.ps1

Imports Stack Exchange questions and answers from GDPR export into a SQL-Server database.

## Get-SysMonStats.ps1

Showing stats for Sysinternals Sysmon data Blog post

## ConvertFrom-PostmanCollection.ps1

Takes an exported Postman collection Json file and converts the requests to RFC 2616 http files. This can help you during your migration from Postman to tools like VS Code REST Client.

repository: hahndorf/hacops

gha_language: PowerShell

repo_name: hahndorf/hacops


text:
---
layout: post
title: switch to interactive backend with ipython -pylab
date: 2010-08-21 00:33
categories: [python]
slug: switch-to-interactive-backend-with
---

 objective:

  when running ipython without pylab or executing scripts you want to use an image matplotlib backend like Agg

  just when calling ipython -pylab you want to use an interactive backend like GTKAgg or TKAgg

you need first to setup as default backend on .matplotlib/matplotlibrc

 Agg

:

 backend      : Agg

then setup you ipython to switch to interactive, in ipython file Shell.py, in the class MatplotlibShellBase, at about line 516, add:

 matplotlib.use('GTKAgg')

after the first import of matplotlib

repository: zonca/zonca-blog

gha_language: Jupyter Notebook

repo_name: zonca/zonca-blog


text:
<img src="http://moveit.ros.org/assets/images/moveit2_logo_black.png" alt="MoveIt Logo" width="200"/>

The MoveIt Motion Planning Framework for ROS 2

We are currently working on the upcoming Beta version of MoveIt 2.
See the [MoveIt's website homepage](https://moveit.ros.org) for release dates and [this document](https://docs.google.com/spreadsheets/d/1aPb3hNP213iPHQIYgcnCYh9cGFUlZmi_06E_9iTSsOI/edit?usp=sharing) for our immediate migration progress.

Implementation instructions for the ROS 2 migration process can be found in our [Migration Guidelines](doc/MIGRATION_GUIDE.md).

### Build from Source

> Note: Currently, only the moveit\_core packages are being compiled.

These instructions assume you are running on Ubuntu 18.04.

1. [Install ROS2 Eloquent](https://index.ros.org/doc/ros2/Installation/Linux-Install-Debians/) (Make sure to set `export CHOOSE_ROS_DISTRO=Eloquent` and to source `/opt/ros/eloquent/setup.bash`)

1. [Install ROS2 Build Tools](https://index.ros.org/doc/ros2/Installation/Linux-Development-Setup/#install-development-tools-and-ros-tools)

1. Create a colcon workspace:

        export COLCON_WS=~/ws_ros2/
        mkdir -p $COLCON_WS/src
        cd $COLCON_WS/src

1. Download the repository and install any dependencies:

        git clone git@github.com:ros-planning/moveit2.git
        vcs import < moveit2/moveit2.repos
        rosdep install -r --from-path . --ignore-src --rosdistro eloquent -y

1. Configure and build the workspace:

        cd $COLCON_WS
        colcon build --event-handlers desktop_notification- status- --cmake-args -DCMAKE_BUILD_TYPE=Release

1. Source the workspace:

        source $COLCON_WS/install/local_setup.bash

## Roadmap
The MoveIt Motion Planning Framework **for ROS 2.0**

- [Milestones](#milestones)
- [Overview of MoveIt!](http://moveit.ros.org)
- [Installation Instructions](http://moveit.ros.org/install/)
- [Documentation](http://moveit.ros.org/documentation/)
- [Get Involved](http://moveit.ros.org/documentation/contributing/)
- [Migration Guidelines](doc/MIGRATION_GUIDE.md)

## Continuous Integration Status

[![Build Status](https://travis-ci.org/ros-planning/moveit2.svg?branch=master)](https://travis-ci.org/ros-planning/moveit2)

## Docker Containers

TODO [Create ROS2 Docker containers for MoveIt!](https://github.com/ros-planning/moveit2/issues/15)

## ROS Buildfarm

Debian releases of MoveIt2 will not be available during the alpha development stage. Check back May 2019.


text:
# polonium-bot
a low-key discord bot built in python :smile:

## current commands
keyword | description
--------|---------
.help | prints a list of commands and their descriptions
.hello | say hello to polonium!
.roll xdn | where x is the number of dice, and n is the sides of the dice (1d6 for example)
.rollad xdn | roll with advantage
.rollda xdn | roll with disadvantage
.woop | sends a random image of wooper
.miku | sends a random image of hatsune miku
.gme | ask polonium their opinion on gamestop stock
.rblx | ask polonium their opinion on roblox stock
.ar | add a custom response. format: .ar \<command name\> \<command text\>
.er | edit a custom resopnse. format: .er \<command name\> \<new command text\>
.dr | delete a custom response. format: .dr \<command name\>

more coming soon!

## using polonium

clone polonium

in the command prompt, change the directory to where polonium.py is. run `python -m pip install -r requirements.txt` to install requirements.

sign into the discord developer portal, and create a new application. go to the bot tab, and click 'add bot'. copy the token from that page.
go to the OAuth2 tab, select "bot" from the scopes pane, and "administrator" from the bot permissions pane. open that link in a new tab to add polonium to a server.

run polonium.py in the command prompt.

the first time the bot is run, it will prompt you to enter the token that you copied earlier and a prefix char (like ! or . or & -- the character that goes in front of each command). It might give you an error along the lines of `'NoneType' object has no attribute 'strip()'` -- just run polonium.py again.

to change the token or prefix char after the first time it's run, delete the file named '.env' and run the bot again
***
[syrtis on twitter](https://twitter.com/syrtis_)

repository: syrtis-m/polonium-bot

repo_name: syrtis-m/polonium-bot


text:
# Business Group Document Management

![guld](gap://media/image/guld/guld-logo-set-without-background/6_guld_ gold_logo_no_name.png)

Author: [Ira Miller](gap://life/isysd) <[public@iramiller.com](mailto:public@iramiller.com)> [iramiller.com](https://iramiller.com)

### Problem

Business groups face a number of challenges at the juncture of IT and legal. If proper steps are not taken to capture and store every step of contract execution, the consequences can be loss of business, bloated operations, negligence, fraud, or even embezzlement.

### Solution

The lifecycle of a contract is request, writing, discussion, execution, and finally storage. By utilizing [git](https://en.wikipedia.org/wiki/Git), a revision control file system, for all legal documents, each of these steps can be recorded perfectly, including meta-data like author(s), signer(s), timestamps, and even supporting identification for counter-parties, such as corporate email server signatures. Additionally, the shared cloud-storage functionality of git will improve workflows, reducing confusion over document version, and email chains.

Basically, the group can have a private dropbox, where every change to every document is perfectly recorded, even if it was made by a third party.

### Technical Details

[Git](https://git-scm.com), well known through hosting service [github](http://github.com/), is used by every major company and institution in the world, from the US Department of Defense to Google. It is free, open source, and supported for every computer language and operating system.

Though trustworthy companies like github offer enterprise hosting services, it is trivial for an enterprise IT department to run their own [git server](https://git-scm.com/book/en/v2/Git-on-the-Server-Setting-Up-the-Server). The author would recommend [gitolite](http://gitolite.org/) to simplify management of a large number of users.

##### User Experience

Seamless desktop integration is possible with git, so that a local directory can be synchronized with the group. After setup, this should not require any action on the part of the user, making the solution suitable for anyone from a new secretary to a senior partner.

Anyone who has used [Dropbox](https://www.dropbox.com) or [Google Drive](http://drive.google.com) to share a local folder will be able to use this cloud drive.

##### Contract lifecycle

The contract lifecycle with our git cloud server looks like each person opening and saving the file in order, until the final person prints and physically signs the paper version. Because each time the file is opened and saved, the digital signature of the user is recorded, no further action is strictly necessary to indicate review and approval of the contract. As a visual signal, typing in your name would be appropriate.

![Lifecycle Flowchart](gap://media/image/isysd/business-group/Contract-lifecycle.jpg)

##### Users and Teams

Users can be organized into teams with group or individual permissions. [Gitolite](http://gitolite.org/) allows this sort of configuration in a clear and secure manner.

In the context of a business group, it is recommended to create one or more repository (shared folder) per company, and reflect corporate structure in the user permissions. For those familiar with [Fork/PR workflow](https://gist.github.com/Chaser324/ce0505fbed06b947d962), the goal is to have the managers and business executives to merge changes into the organization's master records from topic-based, working forks.

##### Security

Though git servers can identify users by open standards like [SSH keys](https://www.ssh.com/ssh/protocol/), the author also recommends having each user generate a [PGP key](http://openpgp.org/) to use for signing all file changes. This leaves a stronger trail of ownership, since PGP signatures are stored in the git database, while SSH signatures are discarded after server authentication. Each user device can be configured to perform these signatures in the background upon file save.

PGP can also be used to encrypt files, for extra security. This could be useful for corporate secrets that should not be known by employees, including IT personnel. In fact, such encryption is the only way to keep a secret from IT personnel.

### Implementation steps

To put this plan into action, take the following steps.

1. Set up a gitolite server for the group, preferably with backups.
2. Install git, a git UI on all workstations.
3. Generate SSH and PGP keys for each user and install on respective workstations.
4. Create git repositories, users, and groups to map to corporate structure.
5. Train employees on use of their new cloud storage system.

repository: riomyers/panama-glass

repo_name: riomyers/panama-glass


text:
---
layout: post
title:  "Thunks 2"
date:   2017-01-16
tags: [javascript]
---
Watched some more JS lectures by Kyle Simpson.

Assume that our task at hand is to request multiple files in parallel, but output them in a particular order. Given:

{% highlight javascript %}
function frokneeAjax(url, cb) {
  var sampleResponses = {
    "file1": "Yo mama got the wooden leg with real feet",
    "file2": "Yo mama's glasses so thick, when she looks at maps she can see people waving at her",
    "file1": "Yo mama's an extra on the Simpsons"
  }

  var randomDelay = Math.floor((Math.random() * 10000));

  console.log("Making Ajax request...");

  setTimeout(function() {
    cb(sampleResponses[url]);
  }, randomDelay);
};

function output(text) {
  console.log(text);
};

function getFile(file) {
  // Write this thunk
};
{% endhighlight %}

gha_language: HTML


text:
# Changelog

See Github releases for newer release info.

### 1.2.4 (June 2018)

-   Fix proxy config related crash on remote instances
    Fixes [JENKINS-52039](https://issues.jenkins-ci.org/browse/JENKINS-52039)
-   Upgraded minimal required Jenkins version to 2.98

### 1.2.3 (June 2018)

-   Supports using the Jenkins proxy configuration
    Fixes [JENKINS-51478](https://issues.jenkins-ci.org/browse/JENKINS-51478)

### 1.2.2 (Januari 2018)

-   The underlying "Publish Over" library has been updated in 0.21
    Fixes [JENKINS-48926](https://issues.jenkins-ci.org/browse/JENKINS-48926)

### 1.2.1 (September 2017)

-   Fix not overwritting large files
    Fixes [JENKINS-46533](https://issues.jenkins-ci.org/browse/JENKINS-46533?src=confmacro)
-   Add field description to the step Snippet Generator

### 1.2.0 (July 2017)

-   Add build pipeline DSL support
    Fixes JENKINS-43230
-   Fixed an encoding issue with directory creation
    Fixes JENKINS-45309
-   Autorename attribute typo fixed
    Fixes [JENKINS-40196](https://github.com/jenkinsci/publish-over-dropbox-plugin/commit/1cffda729f60f82cd52e1e60443b1b1f00580f73 "Request field typo, fixes JENKINS-40196")
-   Improved some error messages

### 1.1.2 (Dec 2016)

-   Fix malformed chunk upload request
    Fixes [JENKINS-40196](https://issues.jenkins-ci.org/browse/JENKINS-40196)

### 1.1.1 (Nov 2016)

-   Large uploads are chunked in uploads of 4 MB each
    Fixes [JENKINS-39093](https://issues.jenkins-ci.org/browse/JENKINS-39093)
-   The plugin uses Dropbox V2 API
    Fixes [JENKINS-36407](https://issues.jenkins-ci.org/browse/JENKINS-36407)
-   Switch to a more future-proof Dropbox Client ID
-   Update parent plugin to version 2.6
    Addresses [INFRA-588](https://issues.jenkins-ci.org/browse/INFRA-588)

### 1.0.5 (Nov 8 2015)

-   Fixes [JENKINS-31112](https://issues.jenkins-ci.org/browse/JENKINS-31112)

### 1.0.3 (Sep 21 2015)

First function release

### 1.0.2 (Sep 21 2015)

Failed non-functioning release

### 1.0.1 (Sep 20 2015)

Failed non-functioning release

### 1.0.0 (Sep 19 2015)

Failed non-functioning release


text:
# wp user application-password

Creates, updates, deletes, lists and retrieves application passwords.

### EXAMPLES

    # List user application passwords and only show app name and password hash
    $ wp user application-password list 123 --fields=name,password
    +--------+------------------------------------+
    | name   | password                           |
    +--------+------------------------------------+
    | myapp  | $P$BVGeou1CUot114YohIemgpwxQCzb8O/ |
    +--------+------------------------------------+

    # Get a specific application password and only show app name and created timestamp
    $ wp user application-password get<PHONE_NUMBER>d-c1d7-4f79-9dd5-4586f734d69e --fields=name,created
    +--------+------------+
    | name   | created    |
    +--------+------------+
    | myapp  |<PHONE_NUMBER> |
    +--------+------------+

    # Create user application password
    $ wp user application-password create 123 myapp
    Success: Created application password.
    Password: ZG1bxdxdzjTwhsY8vK8l1C65

    # Only print the password without any chrome
    $ wp user application-password create 123 myapp --porcelain
    ZG1bxdxdzjTwhsY8vK8l1C65

    # Update an existing application password
    $ wp user application-password update<PHONE_NUMBER>d-c1d7-4f79-9dd5-4586f734d69e --name=newappname
    Success: Updated application password.

    # Check if an application password for a given application exists
    $ wp user application-password exists 123 myapp
    $ echo $?
    1

    # Bash script for checking whether an application password exists and creating one if not
    if ! wp user application-password exists 123 myapp; then
        PASSWORD=$(wp user application-password create 123 myapp --porcelain)
    fi

repository: wp-cli/handbook

gha_language: PHP

repo_name: wp-cli/handbook


text:
# react-framer-motion-demo

A basic demo of how to use Framer Motion.

This repo is also for demonstrating automated release notes using Conventional Commits.

## Install

_Requirements: NodeJS, NPM_

1. Clone repo locally.
2. Execute `npm install` to load in all dependencies.
3. Execute `npm run start` to view app locally.

## Instructions for implementing Automated Release Notes

#### 1. (If not already created) Initialize new NPM config:
Execute: `npm init`

#### 2. Install and configure packages:
Execute: `npm i -D husky @commitlint/{config-conventional,cli,prompt} commitizen cz-conventional-changelog standard-version`

#### 3. Add a new file in the root of your project called *commitlint.config.js*, with this content:
```
// commitlint.config.js
module.exports = {extends: ['@commitlint/config-conventional']};
```

#### 4. Add these two lines to the `scripts` portion of your *package.json*:
```
"commit": "./node_modules/.bin/git-cz",
"release": "standard-version"
```

#### 5. Append husky config at end of *package.json*:
```
  "husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
    }
  },
```

#### 6. Append commitizen config at end of *package.json*, to use Conventional Commits rules:
```
  "config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    }
  },
```

#### 7. Finally, append `standard-version` config at end of *package.json*:
_This controls which headers are visible/hidden from generated CHANGELOG.md_
```
  "standard-version": {
    "types": [
      { "type": "chore", "section": "Others", "hidden": false },
      { "type": "revert", "section": "Reverts", "hidden": false },
      { "type": "fix", "section": "Bug Fixes", "hidden": false },
      { "type": "feat", "section": "Features", "hidden": false },
      { "type": "docs", "section": "Docs", "hidden": false },
      { "type": "style", "section": "Styling", "hidden": false },
      { "type": "refactor", "section": "Code Refactoring", "hidden": false },
      { "type": "perf", "section": "Performance Improvements", "hidden": false },
      { "type": "test", "section": "Tests", "hidden": false },
      { "type": "build", "section": "Build System", "hidden": false },
      { "type": "ci", "section": "CI", "hidden": false }
    ]
  }
```

#### 8. [VERIFY] With all those packages and configurations installed you're ready to go! Let's go through the commands and make sure everything works.

- Test failed commit message

First let's ensure commit linting is functional. Make a change in your code, then committing with a (now invalid message format), like: "saving changes". You should see an error.

- Commit proper message with tool

Now, let's do a proper commit by using our new command line tool: `npm run commit`

#### 9. [FINISH] Generate initial release notes
Alright, commit linting is working, you've got a fresh new commit in your repo's history waiting to be effortlessly printed onto release notes using the new command, `npm run release`.
 - Since this is the first release using this tool, append the command with `-- --first-release`, so it looks like `npm run release -- --first-release`.
 - If you want to try out the commands first before having any changes committed, attach `--dry-run` onto the command, it will look like: `npm run release -- --first-release --dry-run`.
 - Upon completion, `standard-version` even gives you the Git command to copy+paste for pushing your shiny new CHANGELOG.md, bumped version numbers, and tagged release.


text:
<!--
#
# Licensed to the Apache Software Foundation (ASF) under one or more
# contributor license agreements.  See the NOTICE file distributed with
# this work for additional information regarding copyright ownership.
# The ASF licenses this file to You under the Apache License, Version 2.0
# (the "License"); you may not use this file except in compliance with
# the License.  You may obtain a copy of the License at
#
#     http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.
#
-->

# Concepts

In this section you will learn about using two components of the IBM Cloud Functions (ICF) programming model called `triggers` and `rules` which are used to associate event data with your `actions`.

## Triggers

Triggers are a named channel for a class of events. The following are examples of triggers:

* A trigger of location update events
* A trigger of document uploads to a website
* A trigger of incoming emails

Triggers can be fired, or activated, by using a dictionary of key-value pairs. Sometimes this dictionary is referred to as the normalized, internal event. However, these normalized events are often a representation of raw data coming from external events generated outside the serverless platform.  As with actions, each firing of a trigger results in an activation ID.

Triggers can be explicitly fired by a user or by an external event source. A feed is a convenient way to configure an external event source to fire trigger events that can be consumed by ICF. Examples of feeds include:

* CouchDB data change feed that fires a trigger event each time a document in a database is added or modified
* A Git feed that fires a trigger event for every commit to a Git repository

Instances of triggers can also be fired with parameters that can be passed on to one or more actions they can be connected to using rules.

---

## Rules

A rule associates one trigger with one action. Every firing of the trigger causes the corresponding action to be invoked with the trigger event as input.

With the appropriate set of rules, it's possible for a single trigger event to invoke multiple actions, or for an action to be invoked as a response to events from multiple triggers.

For example, consider a system with the following actions:

* `classifyImage` action that detects the objects in an image and classifies them
* `thumbnailImage` action that creates a thumbnail version of an image

Also, suppose that there are two event sources that are firing the following triggers:

* `newTweet` trigger that is fired when a new tweet is posted
* `imageUpload` trigger that is fired when an image is uploaded to a website

You can set up rules so that a single trigger event invokes multiple actions, and have multiple triggers invoke the same action:

* `newTweet -> classifyImage` rule
* `imageUpload -> classifyImage` rule
* `imageUpload -> thumbnailImage` rule

The three rules establish the following behavior:

* Images in both tweets and uploaded images are classified
* Uploaded images are classified
* A thumbnail version is generated

{% hint style="info" %}
Triggers and rules enable the implementation of the [Observer pattern](https://en.wikipedia.org/wiki/Observer_pattern). Triggers relate state changes (events) from the subject(event source) to a list of observers (actions) when connected by a rule.
{% endhint %}

{% hint style="success" %}
**Remember**: Rules allow you to connect a trigger to an action. That's all you need to know for now. Next you’ll learn more about using these new concepts.
{% endhint %}


text:
#OpenExam

[OpenExam](http://www.openexam.org) is quiz software built on Ruby on Rails with a focus on student/ teacher collaboration.

#Organization support
OpenExam supports unique organizations with subdomain support. Each organization is given its own subdomain and is siloed off from other organizations. For example, test.openexam.org is a completely separate instance of the application from class1.openexam.org.

When testing your data on local host, do not use `localhost:3000` or `test.localhost:3000` (as local host does not support subdomains). Instead use `lvh.me:3000` or `test.lvh.me:3000`.

#OpenExam workflow
OpenExam workflow is separated into admin and students. Each organization has at least one admin who has the ability to create quizzes. Once a quiz is created, students within that organization can submit their own questions for the quiz. The admin can approve or reject each question before publishing the quiz for the organization members to take.

The admin(s) also have the ability to see full stats for each student and each quiz.

#Installation

Once you clone the repository, you must update two files in the config folder.

In the config folder, two files must be edited and have their names changed. `database.example.yml` and `postmark.example.yml` must be edited with your personal infomration (see below) and renamed to `database.yml` and `postmark.yml`.

After you update those files, run `ruby script/bootstrap.rb` to get clean database with test data.

#Setting up Postmark

You need to create /config/postmark.yml file to configure mailer. Submit the following code with your personal postmark information.

```development:

postmark_api_key: "your-key"

production:

postmark_api_key: "your-key"

postmark_sender<EMAIL_ADDRESS>
postmark_recipients:

<EMAIL_ADDRESS>
<EMAIL_ADDRESS>```

repository: harchs/open-exam

repo_name: harchs/open-exam


text:
# system_metrics_collector

DEPRECATION NOTICE

This experimental package is now deprecated - there is no plan to do further development or to maintain what has been built

![License](https://img.shields.io/github/license/ros-tooling/system_metrics_collector)
[![GitHub Action Status](https://github.com/ros-tooling/system_metrics_collector/workflows/Test%20system_metrics_collector/badge.svg)](https://github.com/ros-tooling/system_metrics_collector/actions?query=workflow%3A%22Test+system_metrics_collector%22)
[![End-to-end Testing (Nightly)](https://github.com/ros-tooling/system_metrics_collector/workflows/End-to-end%20Testing%20(Nightly)/badge.svg)](https://github.com/ros-tooling/system_metrics_collector/actions?query=workflow%3A%22End-to-end+Testing+%28Nightly%29%22)

## MetricsMessage

This message is used to publish the statistics of measured data points, for example system CPU percentage,
system free memory percentage, message age, etc.

## System Metrics Collector

The goal of this package is to provide lightweight, real-time system metrics to enable
system debugging and diagnosis of ROS2 systems (currently Linux only). It automatically collects
and aggregates CPU % used and memory % used of both system and ROS2 processes.
Data is aggregated in order to provide constant time average, min, max, sample count,
and standard deviation values for each collected metric.

Please see the [package README](system_metrics_collector/README.md) for more details and usage examples.

## Building from Source

To build from source you'll need to create a new workspace, clone and checkout the latest release branch of
this repository, install all the dependencies, and compile. If you need the latest development features
you can clone from the `master` branch instead of the latest release branch. While we guarantee the release
branches are stable, __the `master` should be considered to have an unstable build__ due to ongoing development.git diff

- Create a ROS2 workspace and a source directory

```sh
mkdir -p ~/ros2-workspace/src
```

- Clone the package into the source directory
```sh
cd ~/ros2-workspace/src
git clone git@github.com:ros-tooling/system_metrics_collector.git
```

- Install dependencies
```sh
cd ~/ros2-workspace
sudo apt-get update && rosdep update
rosdep install --from-paths src --ignore-src -r -y
```

_Note: If building the master branch instead of a release branch you may need to also checkout and build the master branches of the packages this package depends on._

- Build the packages
```sh
cd ~/ros2-workspace && colcon build
```

- Configure ROS2 library Path
```sh
source ~/ros2-workspace/install/local_setup.bash
```

- Run the unit tests
```sh
colcon test && colcon test-result --all
```

## License
The source code is released under an Apache 2.0.

Maintainer: ROS Tooling Working Group<EMAIL_ADDRESS>


text:
---
uid: v2index
title: V1/V2 Quickstart
---

Examine Documentation
===

## What is Examine?

<img align="right" src="https://github.com/Shazwazza/Examine/raw/master/assets/logo-round-small.png?raw=true"> Examine allows you to index and search data easily and wraps the Lucene.Net indexing/searching engine. Lucene is _super_ fast and allows for very fast searching even on very large amounts of data. Examine is very extensible and allows you to configure as many indexes as you like and each may be configured individually. Out of the box Examine gives you a Lucene based index implementation as well as a Fluent API that can be used to search for your data.

Examine is installed via Nuget: [https://www.nuget.org/packages/Examine](https://www.nuget.org/packages/Examine)

## [Conceptual Documentation](xref:v2indexing)
Conceptual documentation is available.

_**Tip**: There are many unit tests in the source code that can be used as Examples of how to do things. There is also a test web project that has plenty of examples of how to configure indexes and search them._

* [Indexing](xref:v2indexing)
* [Configuration](xref:v2configuration)
* [Searching](xref:v2searching)
* [Sorting](xref:v2sorting)

## Minimum requirements

| Examine Version | .NET |
| --------------- | ---- |
| V2 | .NET Standard 2.0 |
| V1 | .NET Framework 4.5.2 |

## Quick Start

#### Examine V2

**Tip**: `IExamineManager` is the gateway to working with examine. It is registered in DI as a singleton and can be injected into your services._

1. Install

    ```powershell
    > dotnet add package Examine --version 2.1.0
    ```

1. Configure Services and create an index

    ```cs

    // Adds Examine Core services
    services.AddExamine();

    // Create a Lucene based index
    services.AddExamineLuceneIndex("MyIndex");
    ```

1. Populate the index

    ```cs
    // Add a "ValueSet" (document) to the index
    // which can contain any data you want.
    myIndex.IndexItem(new ValueSet(
        Guid.NewGuid().ToString(),  //Give the doc an ID of your choice
        "MyCategory",               //Each doc has a "Category"
        new Dictionary<string, object>()
        {
            {"Name", "Frank" },
            {"Address", "Beverly Hills, 90210" }
        }));
    ```

1. Search the index

    ```cs
    // Create a query
    var results = myIndex.Searcher.CreateQuery()
        .Field("Address", "Hills")        // Look for any "Hills" addresses
        .Execute();                       // Execute the search
    ```

#### Examine V1

**Tip**: `IExamineManager` is the gateway to working with examine. It can be registered in DI as a singleton or can be accessed via `ExamineManager.Instance`._

1. Install

    ```powershell
    PM> Install-Package Examine -Version 1.2.2
    ```

1. Create an index

    ```cs
    public void CreateIndexes(IExamineManager examineManager)
    {
        //Create and add a new index to the manager
        var myIndex = examineManager.AddIndex(
            new LuceneIndex(            // Create a Lucene based index
                "MyIndex",              // Named MyIndex
                new SimpleFSDirectory(  // In a location of your choice
                    new DirectoryInfo("C:\\TestIndexes"))));
    }
    ```

1. Populate the index

    ```cs
    // Add a "ValueSet" (document) to the index
    // which can contain any data you want.
    myIndex.IndexItem(new ValueSet(
        Guid.NewGuid().ToString(),  //Give the doc an ID of your choice
        "MyCategory",               //Each doc has a "Category"
        new Dictionary<string, object>()
        {
            {"Name", "Frank" },
            {"Address", "Beverly Hills, 90210" }
        }));
    ```

1. Search the index

    ```cs
    var searcher = myIndex.GetSearcher(); // Get a searcher
    var results = searcher.CreateQuery()  // Create a query
        .Field("Address", "Hills")        // Look for any "Hills" addresses
        .Execute();                       // Execute the search
    ```

license: MS-PL

repository: Shazwazza/Examine

gha_language: C#

repo_name: Shazwazza/Examine


text:
# Docker on fedora

## Unresolved issues

### Docker, firewalld, and `bridge` mode

#### Problem

In `/var/log/firewalld`, you encounter:
```
2017-10-02 18:22:24 WARNING: COMMAND_FAILED: '/usr/sbin/iptables -w2 -t filter -C DOCKER ! -i docker0 -o docker0 -p tcp -d <IP_ADDRESS> --dport 80 -j ACCEPT' failed:
```

#### Solution

* https://github.com/moby/moby/issues/16137#issuecomment-271615192
* https://github.com/firewalld/firewalld/issues/195

```
nmcli connection modify docker0 connection.zone trusted
systemctl stop NetworkManager.service
firewall-cmd --permanent --zone=trusted --change-interface=docker0
systemctl start NetworkManager.service
nmcli connection modify docker0 connection.zone trusted
systemctl restart docker.service
```

However, this does *not* solve the problem!

repository: aanno/linux-config

repo_name: aanno/linux-config


text:
# ASTo - Apparatus Software Tool
ASTo is security analysis tool for IoT networks. It is developed to support the Apparatus security framework. ASTo is based on
[electron](http://electron.atom.io/) and
[cytoscape.js](http://js.cytoscape.org/). The icons are provided by Google's [Material Design](https://material.io/icons/).

## SectroCloud - Cloud Security Analysis Module
SectroCloud is a module extending ASTo with cloud computing and security requirements engineering concepts. The module was developed to provide tool-support for cloud developers when applying the Secure Cloud Environment Framework(SCEF).

Configuring the properties of a cloud service
![](https://raw.githubusercontent.com/NOMNUDS/apparatus/master/assets/ASTo-Interface-Property-Edit.png)

Examining the properties of a cloud service
![](https://raw.githubusercontent.com/NOMNUDS/apparatus/master/assets/ASTo-Interface-Property-Relationship.png)

Cloud environment model
![](https://raw.githubusercontent.com/NOMNUDS/apparatus/master/assets/VisionOverview.png)

## To Use

To clone and run this repository you'll need [Git](https://git-scm.com) and [Node.js](https://nodejs.org/en/download/) installed on your computer. To download and install the app, type the following in your terminal:

```bash
# Clone this repository
git clone https://github.com/NOMNUDS/apparatus.git
# Go into the repository
cd apparatus
# Install dependencies
npm install
# to run the app
npm start
```

Because the app is still in prototype stage, it is best to keep up to date with the most recent commits. To do so, before starting the app, type:

```bash
# inside the apparatus directory

# update to latest
git pull
```

The first window (home screen) will ask you to choose which modeling phase would you like to perform analysis in. After you select a phase, a native dialog window will be displayed and ask you choose a file to load. By default, you can only choose `.js` or `.json` files.

You will find some example graphs in the `graphs` folder.

## Thanks

[@Or3stis](https://github.com/Or3stis) for the development and support of ASTo.

#### License [MIT](LICENSE.md)

repository: NOMNUDS/apparatus

repo_name: NOMNUDS/apparatus


text:
Hello, this repo is for signature extraction by the usage of neural
networks.
The main objective of this project is to provide a function that takes
in pdf files and extracts all the signatures as well the text in them
using neural networks and OCR techniques.

# Getting Started
To get started, install all the dependencies via Python pip manager.
`pip install -r requirements.txt`
This will take care of the packages required for proper working of the `extractor` class except the installation of PyTorch.

You also have to install [PyTesseract-OCR Engine](https://github.com/tesseract-ocr/tesseract). Follow the instructions on their repo based on your system requirements and you should be fine. Pip only installs a wrapper to pytesseract binary and it does not work without the binary installed on your system.

If you have GPU capability on your system, do not forget to avail it by properly editing `extractor.__load_model()` method in `extractor.py` file i.e. by setting `device = torch.device('cuda')`.
# Usage
First download the pre-trained Siamese Convolutional Neural Network by running `python DownloadModel.py`.
The pretrained weights and code for Siamese CNN's have been taken from [OfflineSignatureVerification](https://github.com/Aftaab99/OfflineSignatureVerification) repo.

Afterwards, use the `extractor` class to perform all the necessary functions. Proper documentation has been provided for all the functions. A simple use case has also been  provided in `main.py` file.

# References
[1] Thanks to Aftaab99 for amazing work on Siamese Neural Networks for [Offline Signature Verfication](https://github.com/Aftaab99/OfflineSignatureVerification).
[2] Thanks to rbaguilla for their [repo](https://github.com/rbaguila/document-layout-analysis) stipulating the detection of lines, words and paragraphs in a scanned docuemnt.

gha_language: Python


text:
[comment]: # " File: readme.md"
[comment]: # "  Copyright (c) 2017-2021 Splunk Inc."
[comment]: # ""
[comment]: # "  Licensed under Apache 2.0 (https://www.apache.org/licenses/LICENSE-2.0.txt)"
[comment]: # ""
### Service Account

This app requires a pre-configured service account to operate. Please follow the procedure outlined
at [this link](https://support.google.com/a/answer/7378726?hl=en) to create a service account.
The following APIs will need to be enabled:

-   AdminSDK
-   GMail API

At the end of the creation process, the admin console should ask you to save the config as a JSON
file. Copy the contents of the JSON file in the clipboard and paste it as the value of the
**key_json** asset configuration parameter.

### Scopes

Once the service account has been created and APIs enabled, the next step is to configure scopes on
these APIs to allow the App to access them. Every action requires different scopes to operate, these
are listed in the action documentation.
To enable scopes please complete the following steps:

-   Go to your G Suite domain's [Admin console.](http://admin.google.com/)
-   Select **Security** from the list of controls. If you don't see **Security** listed, select
    **More controls** from the gray bar at the bottom of the page, then select **Security** from the
    list of controls. If you can't see the controls, make sure you're signed in as an administrator
    for the domain.
-   Select **Show more** and then **Advanced settings** from the list of options.
-   Select **Manage API client access** in the **Authentication** section.
-   In the **Client Name** field enter the service account's **Client ID** . You can find your
    service account's client ID on the [Service accounts
    page](https://console.developers.google.com/permissions/serviceaccounts) or in the service
    account JSON file (key named **client_id** ).
-   In the **One or More API Scopes** field enter the list of scopes that you wish to grant access
    to the App. For example, to enable all the scopes required by this app enter:
    https://mail.google.com/, https://www.googleapis.com/auth/admin.directory.user,
    https://www.googleapis.com/auth/gmail.readonly
-   Click **Authorize** .

### On-Poll

**Configuration:**

-   label - To fetch the emails from the given folder name (default - all folders).
    **Note:-** Reply email in the email thread would not be ingested if you provide a specific label
    in the configuration (eg. Inbox). It will ingest the reply email only if you leave the label
    configuration parameter empty.
-   ingest_manner - To select the oldest first or newest first preference for ingestion (default -
    oldest first).
-   first_run_max_emails - Maximum containers to poll for the first scheduled polling (default -
    1000).
-   max_containers - Maximum containers to poll after the first scheduled poll completes (default -
    100).
-   extract_attachments - Extract all the attachments included in emails.
-   download_eml_attachments - Downloads the EML file attached with the mail.
-   extract_urls - Extracts the URLs present in the emails.
-   extract_ips - Extracts the IP addresses present in the emails.
-   extract_domains - Extract the domain names present in the emails.
-   extract_hashes - Extract the hashes present in the emails (MD5).

repository: phantomcyber/phantom-apps

branch_name: refs/heads/next

repo_name: phantomcyber/phantom-apps


text:
LucyCMS
===================================

LucyCMS is a tiny and powerful Rails 3 CMS.  This CMS is a plugin for your application, not the other way around.  This allow's you to have one codebase for both your application and CMS.

It is based on [Comfortable Mexican Sofa](https://github.com/twg/comfortable-mexican-sofa) by Oleg Khabarov at [The Working Group Inc](http://www.twg.ca)

Installation
------------
Add gem definition to your Gemfile:

    gem 'lucy_cms'

Then from the Rails project's root run:

    bundle install
    rails g cms
    rake db:migrate

Usage
-----
After finishing installation you should be able to navigate to http://yoursite/cms-admin

First you must setup the site.  LucyCMS will ask you for a title for the site, the hostname, and if you want to authenticate via a local database or LDAP.  If you choose LDAP, some further settings are needed.

After you set up your site, you must create one Admin User.  After this user is created, LucyCMS will require you to login from here on out.  Relogin as the user you just created and you can create more users.

Before creating pages and populating them with content you need to create a layout. A layout is the template of your pages; it defines some reusable content (like header and footer, for example) and places where the content goes. A very simple layout can look like this:

    <html>
      <body>
        <h1>{{ cms:page:header:string }}</h1>
        {{ cms:page:content:text }}
      </body>
    </html>

Once you have a layout, you may start creating pages and populating content. It's that easy.

Many options can be found and changed in the cms initializer: /config/initializers/lucy_cms.rb

CMS Tags
--------
There are a number of cms tags that define where the content goes and how it's populated. **Page** and **Field** tags are used during layout creation. **Snippet**, **Helper** and **Partial** tags can be peppered pretty much anywhere. Tag is structured like so:

    {{ cms:page:content:text }}
        \    \     \      \
         \    \     \      ‾ tag format or extra attributes
          \    \     ‾‾‾‾‾‾‾ label/slug/path for the tag,
           \    ‾‾‾‾‾‾‾‾‾‾‾‾ tag type (page, field, snippet, helper, partial)
            ‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾‾ cms tag identifier

Here's a number of tag variations:

    # Page tags are pieces of text content that will get rendered on the page. Format defines how form field
    # gets rendered in the page editing/creation section of the admin area.

    {{ cms:page:some_label:text }}
    {{ cms:page:some_label }}             # shorthand for above. 'text' is default format for pages
    {{ cms:page:some_label:string }}      # in admin area text field is displayed instead of textarea
    {{ cms:page:some_label:datetime }}    # similarly, datetime widget in the admin area
    {{ cms:page:some_label:integer }}     # a number field
    {{ cms:page:some_label:rich_text }}   # TinyMCE wysiwyg editor will be used to edit this content

    # Field tags are pieces of text content that are NOT rendered on the page. They can be accessed via
    # your application's layout / helpers / partials etc. Useful for populating this like <meta> tags.
    # Field formats are exactly the same as for Page tags.

    {{ cms:field:some_label:string }}
    {{ cms:field:some_label }}            # same as above. 'string' is default format for fields

    # Snippet tags are bits or reusable content that can be used anywhere. Imagine creating content like
    # a sharing widget, or business address that you want to randomly use across your site.

    {{ cms:snippet:some_label }}

    # Helper is a wrapper for your regular helpers. Normally you cannot have IRB in CMS content, so there are
    # tags that allow calling helpers and partials.

    {{ cms:helper:method_name }}          # same as <%= method_name() %>
    {{ cms:helper:method_name:x:y:z }}    # same as <%= method_name('x', 'y', 'z') %>

    # Partial tags are wrappers just like above helper ones.

    {{ cms:partial:path/to/partial }}     # same as <%= render :partial => 'path/to/partial' %>
    {{ cms:partial:path/to/partial:a:b }} # same as <%= render :partial => 'path/to/partial',
                                          #   :locals => { :param_1 => 'a', :param_1 => 'b' } %>

Uploads
-------
Uploads is where LucyCMS differs heavily from it's original code base at [Comfortable Mexican Sofa](https://github.com/twg/comfortable-mexican-sofa)

By default all uploads go into the public/common/ directory (although this can be changed in the /config/initializers/LucyCMS.rb file).  From the uploads tab, you can now create subfolders and upload your content.  This way you can add the common directory to your .gitignore file and your CMS content will not be affected by any canges in your code.

Integrating CMS with your app
-----------------------------
LucyCMS is a plugin, so it allows you to easily access content it manages. Here's some things you can do.

You can use CMS pages as regular views:

    def show
      @dinosaur = Dinosaur.find(params[:id])
      # CMS page probably should have either helper or partial tag to display @dinosaur details
      render :cms_page => '/dinosaur
    end

Actually, you don't need to explicitly render a CMS page like that. LucyCMS will try to rescue a TemplateNotFound by providing a matching CMS page.

You can access **Page** or **Field** tag content directly from your application (layouts/helpers/partials) via `cms_page_content` method. This is how you can pull things like meta tags into your application layout.

    # if @cms_page is available (meaning LucyCMS is doing the rendering)
    cms_page_content(:page_or_field_label)

    # anywhere else
    cms_page_content(:page_or_field_label, CmsPage.find_by_slug(...))

Similarly you can access **Snippet** content:

    cms_snippet_content(:snippet_slug)

Extending Admin Area
--------------------

If you wish, you can re-use LucyCMS's admin area for things you need to administer in your application. To do this, first you will need to make your admin controllers to inherit from CmsAdmin::BaseController. This way, your admin views will be using LucyCMS's admin layout and it's Authentication.

    class Admin::CategoriesController < CmsAdmin::BaseController
      # your code goes here
    end

Working with seeds
------------------
LucyCMS has seeds, functionality that helps manage content during development phase. It's very different from Rails seeds as LucyCMS's seeds are loaded with each page load. The database is completely bypassed when seeds are active. This way, you can source-control content before going live, disabling seeds and dumping everything into the database.

First, you will need to set a path where fixture files will be found (inside LucyCMS's initializer):

    if Rails.env.development? || Rails.env.test?
      LucyCMS.config.seed_data_path = File.expand_path('db/cms_seeds', Rails.root)
    end

If you ran `rails g cms`, you should find an example set of seeds in /db/cms\_seeds directory. Please note that seeds are nested in the folder that is the hostname of your site. Each file is an YAML representation of a database entry for that layout/page/snippet.

There's a rake task that makes moving seeds into database (and vice-versa) easy:

    # from seeds into database
    rake LucyCMS:import:all FROM=your-site.local TO=your-site.com SEED_PATH=/path/to/seeds

    # from database to seeds
    rake LucyCMS:export:all FROM=your-site.com TO=your-site.local SEED_PATH=/path/to/seeds

Active Components
-----------------
LucyCMS utilizes the following:

* **[https://github.com/rails/rails](https://github.com/rails/rails)** - Ruby on Rails 3.*, of course
* **[https://github.com/thoughtbot/paperclip](https://github.com/thoughtbot/paperclip)** - Paperclip to handle file uploads
* **[https://github.com/twg/active_link_to](https://github.com/twg/active_link_to)** - Easy method to handle logic behind 'active' links

* * *

LucyCMS is released under the MIT licence
ComfortableMexicanSofa is released under the [MIT license](https://github.com/twg/comfortable-mexican-sofa/raw/master/LICENSE)


text:
# RegistrationSample_pod

[![CI Status](http://img.shields.io/travis/yamini-510/RegistrationSample_pod.svg?style=flat)](https://travis-ci.org/yamini-510/RegistrationSample_pod)
[![Version](https://img.shields.io/cocoapods/v/RegistrationSample_pod.svg?style=flat)](http://cocoapods.org/pods/RegistrationSample_pod)
[![License](https://img.shields.io/cocoapods/l/RegistrationSample_pod.svg?style=flat)](http://cocoapods.org/pods/RegistrationSample_pod)
[![Platform](https://img.shields.io/cocoapods/p/RegistrationSample_pod.svg?style=flat)](http://cocoapods.org/pods/RegistrationSample_pod)

## Example

To run the example project, clone the repo, and run `pod install` from the Example directory first.

## Requirements

## Installation

RegistrationSample_pod is available through [CocoaPods](http://cocoapods.org). To install
it, simply add the following line to your Podfile:

```ruby
pod "RegistrationSample_pod"
```

## Author

yamini-510<EMAIL_ADDRESS>
## License

RegistrationSample_pod is available under the MIT license. See the LICENSE file for more info.


text:
# Sphaerophragmium fimbriatum var. millettiae (Vienn.-Bourg.) Monoson, 1974 VARIETY

#### Status
SYNONYM

#### According to
The Catalogue of Life, 3rd January 2011

#### Published in
Mycologia 66(5): 799 (1974)

#### Original name
Sphaerophragmium millettiae Vienn.-Bourg., 1952

### Remarks
null

repository: mdoering/backbone

path: /life/Fungi/Basidiomycota/Pucciniomycetes/Pucciniales/Raveneliaceae/Sphaerophragmium/Sphaerophragmium millettiae/ Syn. Sphaerophragmium fimbriatum millettiae/README.md

repo_name: mdoering/backbone