text:
# Croak [![Build Status](https://secure.travis-ci.org/AdesisNetlife/croak.svg?branch=master)][9] [![Dependency Status](https://gemnasium.com/AdesisNetlife/croak.svg)][10] [![NPM version](https://badge.fury.io/js/croak.svg)][11] [![Roadchange](https://roadchange.com/AdesisNetlife/croak/badge.svg)][12]

> Grunt made easy for large projects. It's like One Ring to rule them all, but for Grunt

**Disclaimer**:
Croak is still an initial version, but it's ready-to-use in relaxed environments

## About

<img align="right" height="280" src="http://oi44.tinypic.com/f3azc7.jpg" style="float: right" />

[Grunt][1] is an awesome task runner and build automation tool largely adopted for [node.js][7]

Croak is just a simple, but featured wrapper for Grunt that aims to help you to manage
and orchestrate Grunt tasks configuration (aka Gruntfile) in large and distributed projects,
helping you to avoid redundancy, saving time and reducing dramatically changes impact
during the project life-cycle and development workflow

### Features

- Allows you to centralize your Gruntfile in one place and use it from many places
- Easily manages and orchestrates different configuration for multiple projects
- Avoid redundant Grunt configuration over multiple repositories
- Abstracts and provides more control for Grunt tasks configuration
- Support to use and discover global node packages as Grunt configuration package
- Extends or overwrites global Gruntfile from local configuration
- Provides the same Grunt API and very similar CLI (things won’t change too much)
- Customizes Grunt execution options from a config file (future `.gruntrc`)
- You don’t need to have Grunt NPM task locally installed in order to run tasks

## Installation

It is recommended that you install Croak as global package:
```shell
$ npm install croak -g
```

Then, create the configuration file:
```
$ croak init -g
```

The above command will create a `.croakrc` file in your user home directory, as global configuration.

Still confused? Please, take some minutes to read the detailed documentation below

## Table of Contents

- [Why we created Croak?](#why-we-created-croak)
  - [When do I NOT need it?](#when-do-i-not-probably-need-it-)
  - [When do I need it?](#when-do-i-need-it)
- [How it works](#how-it-works)
  - [Example use case scenario](#example-use-case-scenario)
  - [Can abstraction be dangerous?](#can-abstraction-be-dangerous)
- [Current stage](#current-stage)
  - [Grunt support](#grunt-support)
- [Using Croak](#using-croak)
  - [Configuration file](#configuration-file)
    - [Global config](#global-config)
    - [Local config](#local-config)
    - [Available config options](#available-configuration-options)
      - [Global options](#global-options)
      - [Croak-specific](#croak-specific)
      - [Grunt-specific](#grunt-specific)
  - [Switching to Croak](#switching-to-croak)
    - [Adapting your existing Gruntfile](#adapting-your-existing-gruntfile)
    - [Use Croak from an existing Gruntfile](#use-croak-from-an-existing-gruntfile)
  - [Croakfile](#croakfile)
  - [Command-line interface](#command-line-interface)
    - [Running tasks](#running-grunt-tasks)
    - [Configuration](#configuration)
  - [Programmatic API](#programmatic-api)
- [FAQ](#faq)
- [Development](#development)
- [Contributing](#contributing)
- [To Do/Wish list](#to-dowish-list)
- [Contributors](#Contributors)
- [License](#license)

<!--
 [Caveats](#caveats)
-->

## Why we created Croak?

Croak arises from the need to create a specific solution to abstract all the automation configuration stuff. It allows you to delegate responsibilities properly in your project to the developers, without losing the desired level of control and centralization.

Because a design principle, node.js (and consequently Grunt) packages and its dependencies are locally installed, and that is fantastic. However, this is not always the best choice for some scenarios.
As you probably already know, dependencies globalization in node.js can be considered an anti-pattern, but globalization can be an ideal choice if you are in a big and distributed project.

When a project have a considerable number of repositories, by inertia you probably tend to
use the local packages and configuration across each different repository, but these configurations are usually equal
or very similar for each different repository.

The above project scenario is really hard to maintain when you need to apply
changes massively in your project, like automation, building or deployment configuration changes that is completely usual during the project evolution

Croak is created to supply this need. It aims to provide a specific solution to easily centralize and orchestrate Grunt configuration, so that you can rapidly apply massive changes in your project.

Croak has basically two main goals:

- Reduces the Grunt configuration changes impact during your project life-cycle
- Gives configuration control and provides abstraction to developers, without hurting their feelings

### When do I NOT (probably) need it?

- When you have only one or two repositories in your project
- When you have an ultra specific grunt config on each project repository
- When you or your team don’t want to spend time updating/synchronizing build configuration
- When you don’t need to centralize and (consequently) don’t need to take the control
- When you have a lot of free time and you enjoy doing redundant and not very interesting tasks
- When developers of your project... (at least one):
  - are ultra skilled and responsible guys
  - have a lot of time to maintain their own automation tasks configuration
  - need to take full control of the automation tasks configuration

### When do I need it?

- When you want to centralize and take control of the project building and automation configuration
- When you want to reduce the configuration change time and impact in your project
- When your project have a considerable number of repositories (more than 3)
- When your project configuration is equal or very similar in different repositories
- When you want to keep clean each repository of Grunt tasks
- When you do NOT want to spend time doing redundant and not very funny stuff
- When you do not want to spend much time providing support to developers about configuration stuff
- Or whatever is not on the 'When do I not need' list...

## How it works

In a few words, Croak allows you to have a multiple `Gruntfile` in global locations and runs them using a simple project identifier (like a linker). It also allows you to define pre-configured options to pass to Grunt in a simple configuration file

Moreover, Croak allows you to extend or overwrite Gruntfile configurations, so you can provide a way to customize tasks configuration from local configuration (see the [Croakfile](#croakfile) section)

### Example scenario

A representative scenario could be, for example, that your project has a relevant
number of repositories. Each repository needs its automation configuration
for development, testing or building stuff.

Usually, this configuration tends to grow when your repository has a certain amount of different tasks and it also tends to be very similar or redundant in different repositories in your project

For example you could need the same tasks in your project to run tests, generate documentation,
statically analyze the code, generate a coverage report or measure the code complexibility

Continuous changes and improvements are a permanent feature in any software project, and Croak just helps with that

You can see a complete example project structure using Croak [here][6]

### Can abstraction be dangerous?

Abstraction is not always the best choice and some people can hate it.
Basically, an abstraction in software development tries to reduce notably the complexity,
underlines details and gives more control

With Croak you can provide an ideal level of abstraction to developers without losing  control and,
additionally, give them freedom if they want to customize or extend Grunt configuration allowing them to
adapt it to their needs

If you want to make less impact to the developers, take a look to the [Croak Grunt faker][14]

## Current stage

Croak is an initial ready-to-use version, though it’s under active development process and important changes can be done in a near future version

#### Grunt support

Croak supports Grunt `~0.4.0`

## Using Croak

### Configuration file

Croak uses disk files to store persistently the configuration. The Croak configuration file must be called `.croakrc`

Croak supports two types of configuration files

#### Global config

A global file can store your project configuration and this configuration will be used in each Croak execution

It will be located in the user home directories by default.

If you want to define a global cross-user shared configuration, you can define `CROAKRC` environment variable in order
to specify a custom global file location, instead of the current user home directory

#### Local config

Local file can be located in any path, but it’s recommended that you create it in your project or repository root folder

Usually, a local file should have only one project configured.
Any local configuration has priority and will overwrite global configuration (for example, if you configure the same project in both files)

Croak implements a similar file discovery algorithm like the one Grunt uses to discover the Gruntfile

### Available configuration options

#### Global config

| Name           | Type      | Default     | Description                                    |
| -------------- | --------- | ----------- | ---------------------------------------------- |
| $default       | `string`  | undefined   | Project to use by default when no project is defined. Useful to use in local configuration and avoiding to pass the `--project` flag via CLI |

#### Per-project config

##### Croak-specific

| Name              | Type      | Default     | Description                                    |
| ----------------- | --------- | ----------- | ---------------------------------------------- |
| package           | `string`  | undefined   | Node package which contains the Gruntfile. It will be resolved as local and global package. This is a recommended alternative to the `gruntfile` option |
| extend         | `boolean` | false       | Enable extend existing tasks from Croakfile |
| overwrite      | `boolean` | false       | Enable overwrite existing tasks from Croakfile |
| register_tasks | `boolean` | false       | Enable register/create new tasks from Croakfile |
<!--
| cwd            | `string`  | ${PWD}      | Working directory to pass to Grunfile. Default to ${PWD} or local `.croakrc` path. Don't use this option unless you know what you are doing |
-->

##### Grunt-specific

The following options will be (probably) available in Grunt in future versions, inside a file called `.gruntrc`, however, Croak already supports it

| Name           | Type      | Default     | Description                                    |
| -------------- | --------- | ----------- | ---------------------------------------------- |
| gruntfile      | `string`  | undefined   | Path to your Gruntfile. It can be a relative path. You should define this option in all of your projects. If you define the `package` option, Gruntfile path will be relative to the `package` root directory. By default, Croak tries to find it in the package root folder or inside the `grunt` directory. You only need to use this option with `package` if your Gruntfile exist in a custom directory |
| base           | `string`  | undefined   | Specify an alternate base path. By default, all file paths are relative to the Gruntfile |
| no_color       | `boolean` | false       | Disable colored output |
| debug          | `boolean` | false       | Enable debugging mode for tasks that support it |
| stack          | `boolean` | false       | Print a stack trace when exiting with a warning or fatal error |
| force          | `boolean` | false       | A way to force your way past warnings. Don’t use this option, fix your code |
| tasks          | `string`  | undefined   | Additional directory paths to scan for task and "extra" files |
| npm            | `string`  | undefined   | Npm-installed grunt plugins to scan for task and "extra" files |
| no_write       | `boolean` | false       | Disable writing files (dry run) |
| verbose        | `boolean` | false       | Verbose mode. A lot more information output |

You can use any of the config options also as a command line flag. See the Grunt CLI [documentation][1]

##### Example file configuration

A multi-project `.croakrc` configuration file

```ini
$default = my-project

[super-project]
extend = true
gruntfile = ${HOME}/projects/super-project/build/Gruntfile.coffee
debug = true
stack = true

[my-project]
extend = true
overwrite = true
register_tasks = true
; resolve an node package in the system locally and globally installed
; then Croak will try to discover the Gruntfile inside the package directory
package = my-project-builder
; grunt-specific
base = ${HOME}/projects/my-project/my-package/
no_color = false
no_write = false
debug = false
verbose = false
force = true
stack = true
tasks = ../custom-tasks/
npm = mytask
```

You can use any existing environment variables in config values, using the `${VARIABLE_NAME}` notation

##### Notes about cross-OS variables

In order to use the same config values across diferent OS, Croak will transparently translate
common environment variables to the specific running OS

For example, if your use `${HOME}`, Croak will translate it into `%USERPROFILE%` under Windows and viceversa.
The same case is applied for `${PWD}`, `${TMPDIR}`, `%HOMEDRIVE%`, translating this last one into `/` under Unix-like OS

##### Built-in Croak variables

Additionally, Croak introduces support for an easy way to use relative paths from Croak-specific files locations,
like the `.croakrc` config file path

| Variable       | Value |
| -------------- | ------------------------------------------------- |
| CROAKRC_PATH   | Absolute path to the `.croakrc` local file. If it doesn’t exist, $PWD will be used instead |
<!--
| GRUNTFILE_PATH | Absolute path to the used `Gruntfile`. If it doesn’t exist, ${PWD} will be used instead |
| CROAKFILE_PATH | Absolute path to the used `Croakfile`. If it doesn’t exist, ${PWD} will be used instead |
-->

## Switching to Croak

### Adapting your existing Gruntfile

Croak will automatically expose the croak object in Gruntfile, so you can use this
configuration like template values in your tasks config

This is really useful because, in much cases, you need to use absolute paths in your Gruntfiles

**Croak grunt object**

The following properties will be available as Croak task in Grunt.
You can use it as Grunt templating in tasks configuration. If you don't use the `base` option, you should use one of the
following options to configure your tasks in order to use absolute paths

| Option         |  Description |
| -------------- | ------------------------------------------------- |
| **cwd**        | Absolute path to the current user working directory from where Croak was called  |
| **root**       | Absolute path to the existing `Croakfile` or `.croakrc` directory. If both files don’t exists, cwd will be used instead |
| **config**     | Absolute path to the local .croakrc file directory. If it doesn’t exist, it will be null |
| **base**       | Configured base path. If the base options doesn’t exist, cwd will be used |
| **gruntfile**  | Absolute path to the current used Gruntfile |
| **croakfile**  | Absolute path to the current used Croakfile, if it exists |
| **version**    | Current Croak version |
| **npm**        | Grunt npm load packages |
| **tasks**      | Grunt tasks load path |
| **options**    | Croak current config options object |

The above properties will be also available from `grunt.croak` object

**Example Gruntfile**

```js
module.exports = function (grunt) {
  if (grunt.croak) {
    grunt.log.writeln('Running Grunt from Croak (v.' + grunt.croak.version + ')');
  }

  grunt.initConfig({
    clean: {
      options: {
        force: true
      },
      views: '<%= croak.cwd %>/tmpl/'
      tmp: '<%= croak.root %>/.tmp/'
    },
    jshint: {
      options: {
        jshintrc: '.jshintrc'
      },
      all: [
        '<%= croak.base %>/src/scripts/{,*/}*.js'
        '<%= croak.config %>/demo/{,*/}*.js'
        '!<%= croak.root %>/src/scripts/vendor/*.js'
      ]
    },
    connect: {
      server: {
        options: {
          port: 9001,
          base: '<%= croak.root %>'
        }
      }
    }
  });
};
```

#### Use Croak from an existing Gruntfile

**The Croak Grunt task is still in progress**

<!--
If you already have `Gruntfile.js` in each local repository of your project and you don’t want to switch
radically to Croak, you can use the `grunt-croak` task to have a smaller configuration impact
with the same result

##### Install the task

```
$ npm install grunt-croak --save-dev
```

##### Add it in your Gruntfile

```
grunt.loadNpmTasks('grunt-croak')

grunt.initConfig({
  croak: {
    my_project: {
      options: {
        gruntfile: 'path/to/Gruntfile.js',
        verbose: true
      }
    }
  }
})
```

For more information, see the [grunt-croak][2] documentation
-->

### Croakfile

Like Grunt, Croak has its own specific tasks configuration file.

The Croakfile has the same API as Grunt and it can also be a JavaScript or CoffeeScript file. The module should export a `function`, like in Grunt

The idea behind the Croakfile is to provide an isolated configuration file without conflicting with Gruntfile
for specifically extend or overwrite Grunt tasks configuration from local config to global config

If the Croak project configuration allows `extend` or `overwrite` Grunt config, you can use the Croakfile to
customize and overwrite globally configured tasks to adapt it to your needs

```js
module.exports = function (croak) {

  croak.log.ok('Version:', croak.version)
  croak.log.ok('Grunt version:', croak.grunt.version)

  croak.extendConfig({
    log: {
      foo: {},
      bar: 'hello croak'
    },
    read: {
      files: [
        '<%= croak.root %>/file.json'
        __dirname + '/another-file.json'
      ]
    }
  })

  // you can also register new tasks if 'register_tasks' option is enabled
  croak.registerMultiTask('log', 'Log stuff.', function() {
    grunt.log.writeln(this.target + ': ' + this.data)
  })

  croak.registerMultiTask('read', 'Read file.', function() {
    grunt.log.writeln(this.target + ': ' + this.data)
  })

  croak.registerTask('default', ['log'])

}
```

#### Croakfile API

The Croakfile API inherits from Grunt API.
You can do the same thing in a Gruntfile. Please, see the [Gruntfile documentation][13] for more information

Additionally, Croak provides the next useful and Grunt missing API

##### croak.extendConfig(config)
Alias to grunt.initConfig(), but just for a more semantic usage from Croakfiles

##### croak.task.exists()
Check if a tasks were already registered and exist

##### croak.grunt
Exposes the native Grunt API module object.
If you use directly the Grunt API, for example, to register new tasks or remove config, Croak will not control if you can do it.
Use it under your own reponsibility

### Command-line interface

Croak provides a straightforward CLI that allows you to do almost everything (including all that you can do with Grunt CLI).

Aditionally, if you are convervatory and you want to use Croak keeping the same native Grunt CLI interface,
take a look to the [Croak Grunt faker][14]

```
  Usage: croak [options] [command]

  Commands:

    help
      Output the usage information
    version
      Output the version information
    init [options] [name]
      Create new projects in .croakrc
    config [options] <action> [key] [value]
      Read/write/update/remove croak config
    run [options] [task]
      Run Grunt tasks
    add [options] [name]
      Add new projects in .croakrc

  Options:

    -h, --help     output usage information
    -V, --version  output the version number

  Usage examples:

    $ croak init [name]
    $ croak add [name]
    $ croak config [create|list|get|set|remove]
    $ croak run task
    $ croak grunt task

  Command specific help:

    $ croak <command> --help

  Grunt help:

    $ croak grunt --help

```

#### Running Grunt tasks

```
$ croak run task -p my-project
```
You need to pass the `-p` flag if there’s not a `.croakrc` local config file

You can configure the default project to use from a local config file, like this:
```ini
$default = my-project
```
Then you can simply run:
```
$ croak run task
```

You can also run subtasks:
```
$ croak run task:subtask
```

or multiple tasks:
```
$ croak run task anothertask
```

#### Configuration

Show the current existing config
```
$ croak config list
```

Create a config file (add `-g` flag to create it globally)
```
$ croak config create
```

You can CRUD config values easily from CLI
```
$ croak config [get|set|remove] <key> [value] [-g]
```

### Programmatic API

You can use Croak as node.js module to integrate it in your application

> **Disclaimer**:
> Croak API can change radically in a near future.
> Retrocompatibility is not guaranteed for minor `0.x.x` beta releases

#### Installation

Install Croak as local package
```
$ npm install croak [--save] [--save-dev]
```

Then require the module
```js
var croak = require('croak')
```

#### Croak API
The `croak` module exposes the following members

##### version
Current Croak module version

##### gruntVersion
The current Grunt version (which is using Croak)

##### grunt
Expose the Grunt module object. See [Grunt API][8] for more information

##### config
Exposes the Croak [config](#croak-config-api) module API

##### load([ configPath ])
Discover configuration files, then it will read, parse and load projects configuration

##### loadProject([ configPath ])
Load config and returns the default configured project, it it exists

##### get([ key ])
Alias to [config#get](#configget-key-)

##### set(key [, value, isLocalConfig])
Alias to [config#set](#configsetkey--value-islocalconfig)

##### init([ options, projectObj ])
This method will configure Croak with the passed options config object
and aditionally you can pass the project config object
(that you should get it previously via [croak.config.get()](#config-get--key-))

After it, Croak will try to discover Croakfiles, and then configure and run Grunt

##### initGrunt([ options ])
Configure Grunt with the passed options and run it

#### Croak Config API

The Croak config object is exposed via the `croak` module

```js
var config = require('croak').config
```

##### config.load([ filePath ])
This method tries to discover configuration files, then it will read, parse and load them
It will **throw an Error exception** if cannot read or parse configuration files

##### config.save([ filePath ])
Saves existing loaded configuration in disk

It will **throw an Error exception** if cannot write data

##### config.raw()
Returns an `object` with both global and local properties with
the config data as raw string (ini format)

##### config.get([ key ])
Retrieves an existing config value querying by its key. If not argument is passed, it will return the whole config

```js
croakConfig.get('my-project') // { gruntfile: './path/to/Gruntfile.js' ... }
croakConfig.get('my-project.gruntfile') // './path/to/Gruntfile.js'
```

##### config.getDefault()
Returns the default configured project config object. If it is not configured,
it will return the first existing project, first by looking into local config, and then in the global one

##### config.set(key [, value, isLocalConfig])
Setter method for config values. You can set a new project, or a specific project config value with a primitive type

```js
croakConfig.set('my-project', { gruntfile: '../Gruntile.js' })
croakConfig.set('my-project.gruntfile', '../new/path/to/Gruntile.js')
```

##### config.setLocal(key [, value])

##### config.remove(key)
Removes a config value

```js
croakConfig.remove('my-project') // removes the whole project
croakConfig.remove('my-project.gruntfile') // removes a specific key
```

##### config.value(key [, value, isLocalConfig])
Alias accessor method for `set()` and `get()`

```js
croakConfig.value('my-project') // I'm getting a value
croakConfig.value('my-project.gruntfile', '../Gruntfile.js') // I'm setting a value
```

##### config.globalFile()
Returns the absolute path to the global configuration file in the system

##### config.localFile([ filePath ])
Returns the absolute path to the local configuration file

Croak implements a simple algorithm like Grunt or NPM in order to discover the configuration
file in the current and in higher directories.

Optionally, you can explicitly define a configuration path file to use passing the `filePath` argument

##### config.clean()
Clean loaded config from cache. To apply it persistently in the disk, you must call it [config#save()](#save-filepath-)

##### config.hasData()
Returns `true` if the configuration was loaded and exists

##### config.exists([ key ])
Check if a given property key exists in the current config

```js
config.exists('project') // true
config.exists('nonexisting.gruntfile') // false
```

##### config.path()
Returns an `object` with absolute paths to both global and local config files

```js
config.path()
// { local: '/home/user/.croakrc', local: '/home/user/projects/awesome/.croakrc' }
```

##### config.dirname()
The same as config#path(), but this one only will return the absolute path directory
where the config file is located

## FAQ

**Do I need to have Grunt already installed?**

No, Croak will do it for you. And also
`grunt-cli` will be replaced by Croak CLI

**Can I use the Grunt CLI?**

Of course, it’s available using the `grunt` command

```
$ croak grunt --help
```

**Do I need to have a Gruntfile in my repository?**

No. An already existing Gruntfile is not required.

You only need to specify the global Gruntfile you want to use
and, optionally, you can use a Croakfile to overwrite or extend global configuration

**Can I use both Croak and Grunt at the same time?**

Yes. You must specify a global Gruntfile and also have your own repository Gruntfile.

You can run both like this:

```
$ croak run task -p project
```
```
$ croak grunt localtask
```

## Development

Only node.js is required for development

1. Clone/fork this repository
```
$ git clone git@github.com:adesisnetlife/croak.git && cd croak
```

2. Install package dependencies
```
$ npm install
```

3. Run tests
```
$ npm test
```

4. Coding zen mode
```
$ grunt dev [--force]
```

## Contributing

Croak is completely written in LiveScript language.
Take a look to the language [documentation][3] if you are new with it.
Please, follow the LiveScript language conventions defined in the [coding style guide][4]

You must add new test cases for any feature or refactor you do,
also keep in mind to follow the same design/code patterns that already exist

## To Do/Wish list

- Create an example use case project
- Switch from promptly to inquirer (more featured and pretty CLI, like yeoman)
- More test cases scenarios and destructive/evil testing
- Croak API improvements: add callbacks and event listeners for a better Grunt execution control
- Error CLI test cases
- Better messages for the CLI and verbose mode
- Better usage of the native grunt API (use grunt.option())
- Simplified and better documentation (create a wiki?)
- Support for multiple Gruntfile in the same project, or distributed Grunt tasks?
- Support for Gruntfile instead of Croakfile? Rationale: easier to understand

Do you miss something? Please, feel free to open an issue or make a PR!

## Contributors

- [Tomás Aparicio](https://github.com/h2non)

## License

Copyright (c) 2013 Adesis Netlife S.L and contributors

Released under the [MIT][5] license

![Bitdeli Badge](https://d2weczhvl823v0.cloudfront.net/AdesisNetlife/croak/trend.png)

[1]: http://gruntjs.com
[2]: https://github.com/h2non/grunt-croak
[3]: http://livescript.net
[4]: https://github.com/gkz/LiveScript-style-guide
[5]: https://github.com/adesisnetlive/croak/blob/master/LICENSE
[6]: https://gist.github.com/h2non/7787640
[7]: http://nodejs.org
[8]: http://gruntjs.com/api/grunt
[9]: http://travis-ci.org/AdesisNetlife/croak
[10]: https://gemnasium.com/AdesisNetlife/croak
[11]: http://badge.fury.io/js/croak
[12]: http://roadchange.com/AdesisNetlife/croak
[13]: http://gruntjs.com/sample-gruntfile
[14]: https://github.com/h2non/croak-grunt-faker

repository: AdesisNetlife/croak

gha_language: LiveScript

repo_name: AdesisNetlife/croak


text:
# Community Maps

## Adding your own map

Steps for adding your own map:
1. Fork this project
2. Create a folder for your map in `CommunityMaps`
    1. Directory name must match `"mapName":` in your map.json.
    2. Replace spaces with `_`
       1. see example `Initializing_Errant_Form`
3. Add the .json file to said directory
   1. see example in `Initializing_Errant_Form/e1-m.lttmm.json`
4. Add screenshots of your map to said directory. Best case:
    1. One screenshot of the initial revealed portion of the map
       1. see example in `Initializing_Errant_Form/start.jpg`
    2. One screenshot of the fully revealed map
       1. see example in `Initializing_Errant_Form/revealed.jpg`
5. Add your map to the end of the list below.
6. Check your map, list, screenshots and entry in the list for errors
7. Create a pull request
   1. Not adding your entry to the end of the list will result in me closing your pull request without further comment
   2. Not providing screenshots of your map will result in me closing your pull request without further comment
   3. Not replacing spaces in your directory name with `_` will result in me closing your pull request without further comment
   4.

license: MIT

repository: Trungel/ltt-mapmaker

branch_name: refs/heads/master

extension: md

gha_language: Vue

gha_license_id: MIT

license_type: permissive

repo_name: Trungel/ltt-mapmaker


text:
# Meta
[meta]: #meta
- Name: Buildpack Configuration for Distribution
- Start Date: July 22, 2019
- Status: Implemented
- CNB Pull Request: [rfcs#15](https://github.com/buildpacks/rfcs/pull/15)
- CNB Issue: (leave blank)
- Supersedes: N/A

# Summary
[summary]: #summary

This is a proposal to change the schema of `buildpack.toml` to separate the
concerns of defining a buildpack and managing configuration of buildpacks.

# Motivation
[motivation]: #motivation

In the approval of the [Distribution Spec](https://github.com/buildpacks/rfcs/blob/main/text/0007-spec-distribution.md),
we landed on a [compromise that no one was really happy with](https://github.com/buildpacks/rfcs/pull/11#issuecomment-510483638).
We now propose a new `buildpack.toml` schema that will, hopefully, satisfy all parties.

The Distribution Spec defines a `buildpack.toml` schema containing an array of `[[buildpacks]]` that may include references to buildpacks in a registry or a path to a buildpack in the same repo. For example:

```toml
[[buildpacks]]
id = "io.buildpacks.nodejs"
name = "Node.js Buildpack"
version = "0.0.9"
[[buildpacks.order]]
group = [
   { id = "io.buildpacks.node", version = "0.0.5" },
   { id = "io.buildpacks.npm", version = "0.0.7" },
]

[[buildpacks]]
id = "io.buildpacks.npm"
name = "NPM Buildpack"
version = "0.0.7"
path = "./npm-cnb/"

[[buildpacks]]
id = "io.buildpacks.node"
name = "Node Engine Buildpack"
version = "0.0.5"
path = "./node-cnb/"
```

The entries in the `[buildpack.order.group]` must use an `id` and `version` that point to an entry in this file, or a buildpack in a registry. This creates the following problems:

- The array of buildpacks hints at order, but it cannot be used to create a group(s) that are run against an app/service repo. The list of buildpacks only defines the configuration for a loose collection of buildpacks and cannot be resolved into a group/order.
- The `buildpack.toml` cannot be used "to run a buildpack" without additional information (i.e. it doesn't describe a single buildpack). This is problematic for platforms that want to run the buildpack (and its `buildpack.toml`) directly without pre-packaging (such as with `pack build --buildpack`).
- Information must be repeated in order to define the `io.buildpacks.nodejs` metabuildpack (i.e. if I update the version of the node-engine buildpack I must change it in several different places).
- It's unclear how this schema supports `buildpack.toml` files in subdirectories (i.e. decoupled from the top level `buildpack.toml`). For example, when `path` is used, can the directory it points to contain a `buildpack.toml`? If so, does that `buildpack.toml` override the `id`, `version`, etc in the top-level `buildpack.toml`? And if so, which buildpack in the `[[buildpacks]]` array is used to override?

# What it is
[what-it-is]: #what-it-is

Terminology:

* **buildpackage**: the distributable artifact that represents a buildpack. It may be one of the formats described in the distribution spec.
* **metabuildpack**: a buildpack that defines an order, but does not contain it's own `bin/detect` or `bin/build`. It also does not define its own list of `stacks` (it inherits the union of stacks from its constituent buildpacks).

The target personas for this change include buildpack author, buildpack user, and platform implementor. Buildpack authors will be concerned with the `buildpack.toml` schema changes. Buildpack users will be concerned with what buildpacks they can use from a `buildpack.toml` (i.e. when passing options to `pack build --buildpack`). And platform implementors will be concerned with how a `buildpack.toml` is published.

We propose the following changes to `buildpack.toml`:

- Add a required top level `[buildpack]` table that describes buildpack configuration.
- Remove the `[[buildpacks]]` array of tables.
- Add support for `[[order]]` array, which defines the ordering of buildpack.
- Add a `[metadata]` table that is unstructured.
- Add a `[[stacks]]` array of tables that is required for buildpacks that do not define a `[[order]]` (i.e. non-metabuildpacks). The `stacks` table contains an `id` with the name of a stack.

In order for a repository to be run by a platform, included in a builder, or packaged into a buildpackage; it must contain a `buildpack.toml` with the `buildpack.id` and `buildpack.version` keys. For example:

```toml
[buildpack]
id = "<string>"
version = "<string>"
```

The top level `[[order]]` table has a schema similar to the `[[buildpack.order]]` described in the Distribution Spec. The `group` key may contain an `id` and `version` like this:

```toml
[[order]]
group = [
   { id = "io.buildpacks.node", version = "0.0.5" },
   { id = "io.buildpacks.npm", version = "0.0.7" },
]
```

The `id` and `version` pair will be resolved to a buildpack by the platform.

## Optional Build Plan Groups
To simplify `buildpack.toml`, this RFC will also be extending the [Contractual Build Plan RFC](https://github.com/buildpacks/rfcs/blob/main/text/0005-contractual-build-plan.md) to include the ability to add additional groupings of `provides` and `requires` inside of a `[[or]]` Array.

```toml
[[or]]
[[or.requires]]
name = "nodejs"
[or.requires.metadata]
version = "LTS"
[[or.provides]]
name = "node.js"
```

The `[[or]]` Array is optional, but the top-level `[[requires]]` and `[[provides]]` must be provided first if the Build Plan is being used.

For a given buildpack group, a sequence of trials is generated by selecting a single potential Build Plan from each buildpack in a left-to-right, depth-first order. The group fails to detect if all trials fail to detect.

This supports the use case described in the discussion of the [Distribution Spec](https://github.com/buildpacks/rfcs/pull/12#issuecomment-504781945), by providing a single buildpack that can generate two different build plan groupings.

# How it Works
[how-it-works]: #how-it-works

The following examples describe how the new elements can be used in practice.

## Example: Basic buildpack

The `buildpack.toml` file contain the configuration for a single buildpack:

```toml
[buildpack]
id = "com.example.node"
name = "Node.js Buildpack"
version = "0.0.9"

[[stacks]]
id = "io.buildpacks.stacks.bionic"
```

As long as this repository also contains a valid `bin/detect` and `bin/build`, it can produce a valid buildpack.

## Example: Node.js buildpack with multiple `buildpack.toml` files

This proposal does not include support for a monorepo buildpack (i.e. a repository that contains source code for multiple distinct buildpacks).

# Drawbacks
[drawbacks]: #drawbacks

- Requires a single buildpack per `buildpack.toml`, which may not be preferable in certain monorepo situations. With hope that the support for separate `buildpack.toml` files referenced with `path` will mitigate this.
- This proposal does not do a good job of supporting the use case where a `buildpack.toml` must define multiple buildpacks that have no connection to each other. We propose the `[[profiles]]` pattern alternative described below to accomodate this case.

# Alternatives
[alternatives]: #alternatives

The 1:1 pattern is important to ensure that no odd inferences are defined in the spec (like treating the first buildpack in the `[[buildpacks]]` array as special). This allows a `buildpack.toml` to stand on its own such that it can be used without any outside configuration (like a `package.toml`) if the platform allows it.

However, there are alternatives we could implement, but they favor one concern over another.

## Using only a `[[buildpacks]]` array of tables

This is essentially what is described in the Distribution Spec.

## Add a `[[profiles]]` array of tables

A top-level `[[profiles]]` array of table would allow for zero or many named "profiles" that can override the configuration defined in the `buildpack.toml`. The `profiles` table would have the same schema as the `buildpack.toml` itself (minus the `profiles`).

For example:

```toml
[buildpack]
id = "com.example.myapm.node"
name = "APM Buildpack for Node"
version = "0.0.7"

[[profiles]]
  name = "java"

  [buildpack]
  id = "com.example.myapm.java"
  name = "APM Buildpack for Java"
```

This example, a platform may package the `buildpack.toml` with no other inputs and the result would be a `com.example.myapm.node` buildpackage. But if the platform accepted a `--profile java` option, the `buildpack.id` and `buildpack.name` would be overridden, and a `com.example.myapm.java` buildpackage would be produced.

In the use case where multiple *independent* buildpacks need to be defined in the same `buildpack.toml`, a profile can be used to override the main buildpack. For example:

```toml
[buildpack]
id = "com.example.npm-node"
name = "NPM Node.js Buildpack"
version = "0.0.7"
[[buildpack.order]]
group = [
   { id = "io.buildpacks.node", version = "0.0.5" },
   { id = "io.buildpacks.npm", version = "0.0.9" },
]

[[buildpack.dependencies]]
id = "io.buildpacks.node"
name = "Node Engine Buildpack"
version = "0.0.5"

[[buildpack.dependencies]]
id = "io.buildpacks.npm"
name = "NPM Buildpack"
version = "0.0.9"

[[buildpack.dependencies]]
id = "io.buildpacks.yarn"
name = "Yarn Buildpack"
version = "0.0.8"

[[profiles]]
  name = "yarn"

  [buildpack]
  id = "com.example.yarn-node"
  name = "Yarn Node.js Buildpack"
  [[buildpack.order]]
  group = [
     { id = "io.buildpacks.node", version = "0.0.5" },
     { id = "io.buildpacks.yarn", version = "0.0.8" },
  ]
```

In this way, the `buildpack.toml` can be used directly (without specifiying a `-profile`) and the `com.example.npm-node` is run. But if the `--profile yarn` option is passed to a platform, the `com.example.yarn-node` is run.

# Prior Art
[prior-art]: #prior-art

- The `buildpack.toml` definition in [Distribution Spec](https://github.com/buildpacks/rfcs/blob/main/text/0007-spec-distribution.md)

# Unresolved Questions
[unresolved-questions]: #unresolved-questions

- How is an unresolved reference in a buildpack's `order` handled?
- Can a buildpackage be incomplete (i.e. missing some buildpacks referenced in the `buildpack.toml`)?

repository: buildpacks/rfcs

branch_name: refs/heads/main

gha_language: Shell

repo_name: buildpacks/rfcs


text:
session
======

Session is a session middleware for [water](https://github.com/meilihao/water).

## Backend Supports

Currently session support some backends below:

* [ssdb](https://github.com/meilihao/water-contrib/tree/master/session/ssdb) - ssdb server as a session store

## Installation

    go get github.com/meilihao/water-contrib/session

## Simple Example

see [ssdb_test.go](https://github.com/meilihao/water-contrib/blob/master/session/ssdb/ssdb_test.go)

## Getting Help

- [API Reference](https://gowalker.org/github.com/meilihao/water-contrib/session)

## License

This project is under BSD License. See the [LICENSE](LICENSE) file for the full license text.

repository: meilihao/water-contrib

gha_language: Go

repo_name: meilihao/water-contrib


text:
---
description: Image anchor. Specifies the anchor point (hotspot) of a repeatable texture, wall border, or decal image.
solution: Experience Manager
title: Anchor
feature: Dynamic Media Classic,SDK/API
role: Developer,User
exl-id: 1336330e-86e5-418d-bea3-0c09368e3528
---
# Anchor{#anchor}

Image anchor. Specifies the anchor point (hotspot) of a repeatable texture, wall border, or decal image.

 A repeatable texture is applied to a vignette object so that the texture anchor point is located at the object's texture origin point. A decal image is applied to a vignette object so that the decal anchor point is located at the object's decal origin point. For wall borders, only the x value is used; the y value is ignored.

## Properties {#section-bc4bc8b897c64535b88681e57d72942f}

Two integer numbers, separated by a comma. Pixel offset relative to the top, left corner of the image. Ignored if `catalog::Alignment=3` and by solid color and cabinet materials.

## Default {#section-b7ccc419a356415294706cd295ae96c9}

If the field is empty or not present, the top-left corner (0,0) of the image for repeatable texture materials is used, or the center of the image in case of decal materials.

## See also {#section-3fb2ce2f6b7240a4b6f4858022a0a01d}

[catalog::Alignment](../../../../../ir-api/material-cat/image-rendering-api-ref/c-ir-material-catalog/c-ir-material-data-reference/r-ir-alignment.md#reference-e52152e8dc244d0aa13b40c615d0f399) , [anchor=](../../../../../ir-api/http-protocol/image-rendering-api-ref/c-ir-http-protocol-ref/c-ir-http-protocol-command-reference/r-ir-http-anchor.md#reference-d53923d785c9442997dc7f2199524c26)


text:
# HaikuGen

Generates haikus using Markov chains, tweets one daily.
A select few texts are read in, and used to generate Markov chains.

Markov chains are generated using Markovify.
Frameworks used: TextBlob (built atop NLTK for Python)

In order to use:
Create file credentials.py, set your bot's API Credentials, and run twitbot.py

repository: hailthedawn/HaikuGen

gha_language: Python

repo_name: hailthedawn/HaikuGen


text:
# rsocket-swift
rsocket-swift is an implementation of the RSocket protocol in Swift.
It's an **alpha** version and still under active development.
**Do not use it in a production environment!**

## Strategy
The initial goals for rsocket-swift implementation will be to implement the following features

### Transport
[ ] WebSocket

### Interaction Model
[ ] Request/Response

## Dependencies

- SwiftNIO - Async IO library on iOS
- Combine - Rreactive-streams implementation
- Swift-concurrency - Concurrency support in Swift

repository: iychche/rsocket-swift

gha_language: Swift

repo_name: iychche/rsocket-swift


text:
# Testing

Be a tester, do not be a checker. Automate everything you can if it can be done in reasonable time.

## Static analysis

Automatic eyes on your code; mostly cheap and helpful.

### Cyclomatic complexity

assigns a number to a method resembling the complexity.

This number can be used to identify complex methods which need a refactoring. The number is calculated using the control flow graph, and represents the number of linearly independent paths (for two following `if-else` constructs, the number would be three; two for the first `if-else`, and one to cover the possibly missed block of the second `if-else`).

### Cognitive complexity

tries to enhance cyclomatic complexity to better resemble understandability.

The definition of cognitive complexity is no longer a mathematical model: It tries to calculate the perceived complexity of used structures. It follows simple rules:

- ignore structures with multiple combined statements (syntax sugar like `?`)
- increment for each break in the linear flow
- increment for nested structures

To implement this rules the model uses four different types of increments and detailed specification for common structures (for example, multiple Boolean conditions combined with the same operator increase the score only by one). The increments are defined base on human judgement of the understandability of the structures-

Using this notion, complex & nested algorithms are assigned a much higher number than easy `switch-case` structures. The number allows to compare entirely different methods, and promises to allow sensible comparisons on class / application level.

## Mock Design

Avoid using mocks which specify how they are called [as this locks the details of the implementation with the test](https://martinfowler.com/articles/mocksArentStubs.html). Instead use Stubs (answers specific to the test without reacting to input parameters).

```c-sharp
// pseudocode;
var emailServiceStub = new Mock<IEmailService>();
// whenever the SendEmail(string email, string text) method is called, this stub returns true
emailServiceStub.On(p => p.SendEmail, true);

var serviceUnderTest = new Notifier(emailServiceStub.Stub);
```

Use fluent assertions for easier reading of tests.

```c-sharp
// library: FluentAssertions
var text = "Lorem ipsum";
test.Should().StartWith("Lorem");
```

Name the test methods using one of the following templates:

```c-sharp
SendEmail_WhenNoEmailProvided_ThenThrowException();
GivenNoEmail_WhenSendEmailIsCalled_ThenThrowException();
```

Structure the tests with act, arrange, assert

```c-sharp
// Arrange
var emailService = new EmailService();

// Act
var result =<EMAIL_ADDRESS>"hello world");

// Arrange
result.Should().BeTrue();
```

repository: famoser/docs

repo_name: famoser/docs


text:
---
layout: default
title: Promotion
parent: 🛠 Resources
nav_order: 3
---

# Promotional Resources

OctoFi is a community driven project that relies on grassroots promotion from a passionate community of octonauts. Here's everything a young tentie needs to spread their tentacles far and wide.

First of all, save the poster to your device, and then scroll down for much more.

![](/assets/images/octobrrr.jpg)

## \#OCTObrrr

**Month-long OctoFest**

Celebrate the OCTOber arrival of app.octo.fi

```
Dear #DeFi,

You're invited to celebrate the month-long $OCTO'Fest with @octofinance

🐙 Octo.fi

#OCTObrrr
```

[Click To Tweet](https://twitter.com/intent/tweet?text=Dear%20%23DeFi%2C%0A%0AYou%27re%20invited%20to%20celebrate%20the%20month-long%20%24OCTO%27Fest%20with%20%40octofinance%0A%0A%F0%9F%90%99%20Octo.fi%0A%0A%23OCTObrrr){: .btn .btn-purple }

---

## \#DYOR

**Do Your Octopus Research**

Tentacle Analysis or Fundamentacles?

[docs.octo.fi](https://docs.octo.fi)

```
Tentacle Analysis or Fundamentacles?

Do Your Octopus Research #DYOR

Celebrate $OCTO'Fest with @octofinance

🐙 docs.octo.fi

#OCTObrrr
```

[Click To Tweet](https://twitter.com/intent/tweet?text=Tentacle%20Analysis%20or%20Fundamentacles%3F%0D%0A%0D%0ADo%20Your%20Octopus%20Research%20%23DYOR%0D%0A%0D%0ACelebrate%20%24OCTO%27Fest%20with%20%40octofinance%0D%0A%0D%0A%F0%9F%90%99%20docs.octo.fi%0D%0A%0D%0A%23OCTObrrr){: .btn .btn-purple }

## \#BTFD

**Buy Tentacles For DeFi**

Decentralized Finance <s>Oracles</s> Tentacles.

[octo.fi](https://octo.fi)

```
Decentralized Finance  ̵ ̵O̵r̵a̵c̵l̵e̵s̵ ̵ Tentacles are on the menu.

Buy Tentacles For DeFi #BTFD

Celebrate $OCTO'Fest with @octofinance

🐙 Octo.fi

#OCTObrrr
```

[Click To Tweet](https://twitter.com/intent/tweet?text=Decentralized%20Finance%20%20%CC%B5%20%CC%B5O%CC%B5r%CC%B5a%CC%B5c%CC%B5l%CC%B5e%CC%B5s%CC%B5%20%CC%B5%20Tentacles%20are%20on%20the%20menu.%0D%0A%0D%0ABuy%20Tentacles%20For%20DeFi%20%23BTFD%0D%0A%0D%0ACelebrate%20%24OCTO%27Fest%20with%20%40octofinance%0D%0A%0D%0A%F0%9F%90%99%20Octo.fi%0D%0A%0D%0A%23OCTObrrr){: .btn .btn-purple }

*Don't worry, that's how <s>oracles</s> should look (above) in order to render on Twitter.*

## \#HODL

**Hold Octopus, Don't Let-go.**

Vote in DAOctopus Community Governance.

[dao.octo.fi](https://dao.octo.fi)

```
If you're a #DeFi Octonaut, don't forget to vote in our DAOctopus community governance made possible by @SnapshotLabs 🙌

Hold Octopus, Don't Let-go. #HODL

Celebrate $OCTO'Fest with @octofinance

🐙 dao.octo.fi

#OCTObrrr
```

[Click To Tweet](https://twitter.com/intent/tweet?text=If%20you%27re%20a%20%23DeFi%20Octonaut%2C%20don%27t%20forget%20to%20vote%20in%20our%20DAOctopus%20community%20governance%20made%20possible%20by%20%40SnapshotLabs%20%F0%9F%99%8C%0D%0A%0D%0AHold%20Octopus%2C%20Don%27t%20Let-go.%20%23HODL%0D%0A%0D%0ACelebrate%20%24OCTO%27Fest%20with%20%40octofinance%0D%0A%0D%0A%F0%9F%90%99%20dao.octo.fi%0D%0A%0D%0A%23OCTObrrr){: .btn .btn-purple }

### Happy \#OCTObrrr!!!


text:
![](https://raw.githubusercontent.com/iamkeeler/UXTOOLTIME/master/UXTOOLTIMELOGO.png)

# Change Log (last three updates)

-  5.17.18
    +  Initial Commit

# Description
Hello There! We got tired of writing the same base Android and iOS system level things in Framer so we made a snippet library. Usually we prefer to work mainly in the code side and have short cuts for the things we always use helped speed our flow up. Now we just wanted to share with you all.

# Examples
- COMING SOON

# How to use it?
1. [Download the snippets.](https://github.com/iamkeeler/UXTOOLTIME-Framer/raw/master/Android-Components.zip)
2. Copy the Snippets over to your Framer Snippets Folder (Easist way to get here is to open Framer. Open the snippets menu and click "Show Snippets Folder...")
3. Use the Snippets.
4. Make magic happen!

# Who We Are
1. Ryan Huettl - This one is mainly this guy
2. Monika Perkerwicz
3. Chris Ernt
4. Gary Keeler

---

# [DOWNLOAD ANDROID SNIPPETS](https://github.com/iamkeeler/UXTOOLTIME-Framer/raw/master/Android-Components.zip"Just download it already ;)")

repository: iamkeeler/UXTOOLTIME-Framer

repo_name: iamkeeler/UXTOOLTIME-Framer


text:
# Healthcare.AI Product Suite User Personas

###### Last updated April 13, 2021

*Note: These personas are focused on Level 1: Analytics Integration of the Healthcare.AI Framework.*

:::

##### Buyer

[Healthcare Executive](/content/personas/healthcare-executive?referrer=healthcare-ai) (CIO, CMIO, Chief Analytics Officer) who is already convinced of the value of AI but has struggled to adopt or scale it successfully.

:::

:::

##### Primary Users

- [Clinical/Quality Data Analyst](/content/personas/clinical-quality-data-analyst?referrer=healthcare-ai) analyzes AI-powered graphs and charts and takes findings to leaders.

- [BI Developer](/content/personas/bi-developer?referrer=healthcare-ai) integrates Healthcare.AI into existing analytics using Healthcare.AI APIs.

:::

:::

##### Secondary Users

- Decision makers use Healthcare.AI to drive strategy, including [Chief Quality Officer](/content/personas/chief-quality-officer?referrer=healthcare-ai), [Chief Medical Officer](/content/personas/healthcare-executive?referrer=healthcare-ai), [Chief Nursing Officer](/content/personas/healthcare-executive?referrer=healthcare-ai), etc.

- Improvement leaders use Healthcare.AI to better understand their data, e.g., [Lead Physician](/content/personas/lead-physician?referrer=healthcare-ai), [Program Director](/content/personas/program-director?referrer=healthcare-ai), etc.

:::

branch_name: refs/heads/dev

gha_language: TypeScript


text:
[![setup automated](https://img.shields.io/badge/Gitpod-ready_to_code-blue?logo=gitpod)](https://gitpod.io/from-referrer/)

# Bashplate

Bashplate generates bash boilerplate code for option parsing and validation.

Currently deployed here: https://bashplate.wolfgang-werner.net

Why? Each time (long enough to forget all the details after writing the last one) I need to write a shell script:
* 🧐 "I want this to be reuseable, so I'll use proper options & help messages"
* 🤔 "Hmmm, was it getopt or getopts? Which was the GNU and which the POSIX one? Shouldn't I use argbash?"
* 😤 "So how does the option spec need to look like? Why is that colon at the start again? Does the following option take an argument?" and so on.
* 😩 "How to I test if an argument was set? Reliably and portably?"

Now, I either:
* Copy an old script and fiddle around in it - bad, since there is stuff to remove, I could break things and I still need to think
* Read up on option parsing - bad, as it takes time and I have to decide between getopt, getopts and argbash
* Just skip parameterizing the script and hard code everything - bad, obviously

So basically, I try to hack myself into writing better scripts.

If you can relate, give it a spin.

## Requirements

* POSIX compliance flavor, as I want to run in stripped down Docker containers
* GNU flavor with long opts support, as I like short opts for one offs when typing, long opts in scripts for readability.
* Minimum / No dependencies
* Easy to put on the web, so I cannot lose it & don't have to install anything.

## Development

Contributions welcome.

* `yarn install` - Project setup
* `yarn dev` - Compiles and hot-reloads for development
* `yarn build` - Compiles and minifies for production
* `yarn lint` - Lints code style issues (& fixes them where possible)

Pushing to master deploys to https://bashplate.wolfgang-werner.net and https://bashplate.now.sh (until vercel decides to turn off now.sh).

repository: wwerner/bashplate

repo_name: wwerner/bashplate


text:
Find the Right Word
-------------------

> You have 2 second to rebuild to correct words (2 in the list has been randomly shuffled).
>
> Send the answer back using `https://ringzer0team.com/challenges/126/[string]`.

The words are non-static and refresh with each request. Below is an example of
the payload's format.

```text
----- BEGIN WORDS -----
cuddliest,sumaarim,topsiders,postnuptial,viscountesses,scribes,kaeakyr
----- END WORDS -----
```


text:
# RxBillingService

RxJava 2 extension for Android [In-App Billing](https://developer.android.com/google/play/billing/index.html) [version 3](https://developer.android.com/google/play/billing/api.html) .

Currently is only tested for `inapp` products, not `subs`

## Features:

- No configuration: no [IInAppBillingService.aidl](https://github.com/miguelbcr/RxBillingService/blob/master/rx_billing_service/src/main/aidl/com/android/vending/billing/IInAppBillingService.aidl) , no billing permission in `Manifest.xml`, no `activity` or `fragment` lifecycle.
- Works in activities and fragments.
- Reactive calls, so you don't need `onActivityResult()` anymore.
- You will get the proper object ( [Purchase](https://github.com/miguelbcr/RxBillingService/blob/master/rx_billing_service/src/main/java/com/miguelbcr/io/rx_billing_service/entities/Purchase.java) , [SkuDetails](https://github.com/miguelbcr/RxBillingService/blob/master/rx_billing_service/src/main/java/com/miguelbcr/io/rx_billing_service/entities/SkuDetails.java), `Boolean`) or [RxBillingServiceException](https://github.com/miguelbcr/RxBillingService/blob/master/rx_billing_service/src/main/java/com/miguelbcr/io/rx_billing_service/RxBillingServiceException.java) if something went wrong.

## Setup
Add the JitPack repository in your build.gradle (top level module):
```gradle
allprojects {
    repositories {
        jcenter()
        maven { url "https://jitpack.io" }
    }
}
```

And add next dependencies in the build.gradle of the module:
```gradle
dependencies {
    compile "com.github.miguelbcr:RxBillingService:0.0.3"
    compile 'io.reactivex.rxjava2:rxandroid:2.0.0'
}
```

## Usage
Before attempting to use RxBillingService, you need to call `RxBillingService.register()` in your Android `Application` class, supplying as parameter the current instance.

```java
public class SampleApp extends Application {

    @Override public void onCreate() {
        super.onCreate();
        RxBillingService.register(this);
    }
}
```

**Limitations:** Your fragments need to extend from `android.support.v4.app.Fragment` instead of `android.app.Fragment`.

In order to avoid recreate the `activity` or `fragment` by rotating the screen during the transaction, which will result a malfunction, you will have to add this to your `activity` in the `Manifest.xml`:

```
android:configChanges="layoutDirection|orientation|screenLayout|screenSize"
```

or you could define the screen orientation to your `activity` in the `Manifest.xml` by adding, for instance:

```
android:screenOrientation="portrait"
```

## Methods available
### Checking whether the billing service is available

Sginature:
```java
Single<Boolean> isBillingSupported(ProductType productType)
```

Example:
```java
RxBillingService.getInstance(this, BuildConfig.DEBUG)
        .isBillingSupported(ProductType.IN_APP)
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(supported -> {
          // Do your stuffs
        }, throwable -> {
          if (throwable instanceof RxBillingServiceException) {
            // You can handle the response code defined in RxBillingServiceError
          }
        });
```

### Getting product details

Sginature:
```java
Single<List<SkuDetails>> getSkuDetails(ProductType productType, List<String> productIds)
```

Example:
```java
RxBillingService.getInstance(this, BuildConfig.DEBUG)
        .getSkuDetails(ProductType.IN_APP, Arrays.asList("my-sku", "my-product_id"))
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(skuDetailsList -> {
          // Do your stuffs
        }, throwable -> {
          if (throwable instanceof RxBillingServiceException) {
            // You can handle the response code defined in RxBillingServiceError
          }
        });
```

### Purchasing a product

Sginature:
```java
Single<Purchase> purchase(ProductType productType, String productId, String developerPayload)
```

Example:
```java
    final String developerPayload = String.valueOf(System.currentTimeMillis());

    RxBillingService.getInstance(this, BuildConfig.DEBUG)
        .purchase(ProductType.IN_APP, "my-sku", developerPayload)
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(purchase -> {
          // Do your stuffs
        }, throwable -> {
          if (throwable instanceof RxBillingServiceException) {
            // You can handle the response code defined in RxBillingServiceError
          }
        });
```

### Consuming a purchase

Sginature:
```java
Single<Boolean> consumePurchase(String purchaseToken)
```

Example:
```java
    final String token = purchase.token();
    ...
    RxBillingService.getInstance(this, BuildConfig.DEBUG)
        .consumePurchase(token)
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(success -> {
          // Do your stuffs
        }, throwable -> {
          if (throwable instanceof RxBillingServiceException) {
            // You can handle the response code defined in RxBillingServiceError
          }
        });
```

### Purchasing and consuming a product at once

Sginature:
```java
Single<Purchase> purchaseAndConsume(ProductType productType, String productId, String developerPayload)
```

Example:
```java
    final String developerPayload = String.valueOf(System.currentTimeMillis());

    RxBillingService.getInstance(this, BuildConfig.DEBUG)
        .purchaseAndConsume(ProductType.IN_APP, "my-sku", developerPayload)
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(purchase -> {
          // Do your stuffs
        }, throwable -> {
          if (throwable instanceof RxBillingServiceException) {
            // You can handle the response code defined in RxBillingServiceError
          }
        });
```

### Getting your purchases

Sginature:
```java
Single<List<Purchase>> getPurchases(final ProductType productType)
```

Example:
```java
    RxBillingService.getInstance(this, BuildConfig.DEBUG)
        .getPurchases(ProductType.IN_APP)
        .subscribeOn(Schedulers.io())
        .observeOn(AndroidSchedulers.mainThread())
        .subscribe(purchaseList -> {
          // Do your stuffs
        }, throwable -> {
          if (throwable instanceof RxBillingServiceException) {
            // You can handle the response code defined in RxBillingServiceError
          }
        });
```

## Error handling

If an error happens during the transaction you can check the exception thrown in the `subscribe()`.

You can handle [Google Play errors](https://developer.android.com/google/play/billing/billing_reference.html#billing-codes) by checking if the Throwable instance is a [RxBillingServiceException](https://github.com/miguelbcr/RxBillingService/blob/master/rx_billing_service/src/main/java/com/miguelbcr/io/rx_billing_service/RxBillingServiceException.java) object and getting the code defined in [RxBillingServiceError](https://github.com/miguelbcr/RxBillingService/blob/master/rx_billing_service/src/main/java/com/miguelbcr/io/rx_billing_service/RxBillingServiceError.java) :

```java
    ...
    .subscribe(purchase -> {
      // Do your stuffs
    }, throwable -> {
      if (throwable instanceof RxBillingServiceException) {
        RxBillingServiceException billingException = (RxBillingServiceException) throwable;
        if (billingException.getCode() == RxBillingServiceError.ITEM_ALREADY_OWNED) {
            // Notify the user
        }
      }
    });
```

## Credits
* [RxActivityResult](https://github.com/VictorAlbertos/RxActivityResult): A reactive-tiny-badass-vindictive library to break with the OnActivityResult implementation as it breaks the observables chain.

## Author

**Miguel García**

* <https://es.linkedin.com/in/miguelbcr>
* <https://github.com/miguelbcr>

## Another author's libraries using RxJava:
* [RxPaparazzo](https://github.com/miguelbcr/RxPaparazzo): RxJava extension for Android to take images using camera and gallery.
* [RxGpsService](https://github.com/miguelbcr/RxGpsService): An Android service to retrieve GPS locations and route stats using RxJava
* [OkAdapters](https://github.com/miguelbcr/OkAdapters): Wrappers for Android adapters to simply its api at a minimum


text:
# Tour of the PREreview Codebase

## Key concepts

Preprint

An academic paper prior to formal review and publishing.

Review

PREreview's mission is to lower the barrier to entry for academic review of preprints.
  Reviews can be requested and submitted via the website.

## Key libraries

* [React](https://reactjs.org/) The UI framework for the PREreview website.
* [Express.js](https://expressjs.com/) The web framework for the PREreview API; also supplies data to the website.

## Key services
* [Redis](https://redis.io/) Holds cached results for some operations.
* [CouchDB](https://couchdb.apache.org/) Primary "source of truth" for PREreview users, reviews, and other application state.

## External services
PREreview uses well-known preprint servers to find metadata and content for preprints, including:

- arXiv
- bioArxiv
- Crossref
- OpenAire
- Google Scholar
- DOI.org

Additionally, PREreview relies on [ORCid](https://orcid.org/) for user authentication.

# API
Documentation about the API is published as part of the application; https://outbreaksci.prereview.org/api/ .
This can be edited in `../src/components/api.js`.

# Database Structure

We divide PREreview data among CouchDB collections.
The design docs for these are stored in `../src/ddocs/`; see [CouchDB documentation](https://docs.couchdb.org/en/stable/ddocs/index.html) for more info on design docs.
Database queries are consolidated in `../src/db/db.js`.

## `rapid-prereview-docs`
Stores information about preprints retrieved from authoritative services.

## `rapid-prereview-users`
Stores information about users who have provided profile information for the site.

## `rapid-prereview-index`
Stores a partial copy of information from other collections for full-text indexing.

repository: ChaituVR/rapid-prereview

repo_name: ChaituVR/rapid-prereview


text:
#### Summary

1. Set up Github authentication to register your rocket.
1. Set up messaging/push notifications to request a "relay" token
1. Continued messaging set up to receive a launch token, and trigger a HTTP cloud function to generate the launch token.
1. Set up firestore to send the launch code and listen for the check status.

## Participant Set Up Steps

The participants edit files within the App to hook up Firebase services. It is run with webpack-dev-server so HMR should automatically apply changes.

Links to where code needs to be inserted are provided within the UI, along with resources pointing to Firebase guide snippets and API docs.

```
git clone git@github.com:HHogg/firebase-rtm.git
cd firebase-rtm
npm install
npm start
open http://localhost:4000
```

## Presenter Set Up Steps

The presenter has presents a UI that shows the progress of all the participants.

#### Prerequisites

* You have a Firebase account
* You have firebase cli set up
* You have a Github account.

#### 1) Github

Set up a Github application, that your participants will authenticate against.

#### 2) Firebase Set Up

* Go to the [Firebase console](https://console.firebase.google.com/) and create a new project. Toggle on Github Authentication and follow the set up of exchanging the tokens and auth callback URL.

* Click on the 'Web Setup' button and copy the config object for that project.

#### 2) Application Set Up

```
git clone git@github.com:HHogg/firebase-rtm.git
cd firebase-rtm
nvm use
npm install
cd functions
npm install
cd ../
```

* Swap out the project name inside `.firebaserc`
* Swap out the Firebase config inside `./src/initialiseFirebase.js`

#### 3) Cloud Function Set Up

Set a secret to be used for hashing the launch tokens.

```
firebase functions:config:set launch.secret=SECRET_CODE_HERE
```

#### 4) Deploy Everything

```
npm run deploy:functions
npm run deploy:firestore
```

#### 5) Run the application

```
npm run start
open http://localhost:4000/mc
```

repository: HHogg/firebase-rtm

repo_name: HHogg/firebase-rtm


text:
# github-oauth-backend

A simple OAuth authorisation code flow proxy for the Source Academy—GitHub integration.

The server receives the access code from the frontend, which it exchanges with GitHub for an auth token. The auth token is then returned to the frontend.

## Node modules used

- Express
- ESM
- dotenv
- node-fetch

repository: source-academy/github-oauth-backend

repo_name: source-academy/github-oauth-backend


text:
---
title: Camera Model Summary
layout: post
image: 2018-12-09-camera-model-summary/camera-model-summary-1.jpg
---

During my study of raytracing and browsing on Shadertoy, I have seen lots of different ways of implementing camera models for final rendering. Here is my summary for most of the solutions.

# Camera Model in _Raytracing in One Weekend_
The previous post [Raytracing - Camera and Multisampling Antialiasing](http://viclw17.github.io/2018/07/17/raytracing-camera-and-msaa/) documented the **simplest** camera setup for raytracing rendering. This camera model has fixed world position at origin, fixed image plane (or near clipping plane) size and position at (0,0,-1), pointing to the negative Z axis.

```c
#include "ray.h"
class camera {
public:
    camera() {
        lower_left_corner = vec3(-2.0,-1.0,-1.0);
        horizontal = vec3(4.0,0.0,0.0); // horizontal range
        vertical = vec3(0.0,2.0,0.0);   // vertical range
        origin = vec3(0.0,0.0,0.0);
    }

    ray get_ray(float u, float v){return ray(origin, lower_left_corner + u*horizontal + v* vertical - origin);}

    vec3 lower_left_corner;
    vec3 horizontal;
    vec3 vertical;
    vec3 origin;
};
```

Now let's expand the features of the camera model to include **free positioning** and **depth of field(DOF)**. This time instead of fixed values, we are going to redefine the camera model with
1. camera world position ```lookfrom```,
2. camera look-at position ```lookat```
3. camera space up-vector ```vup```
4. camera vertical field of view(FOV) ```vfov```,
5. image plane width/height ratio ```aspect```,
6. camera lense size ```aperture```,
7. image plane to camera distance ```focus_dist```.

By doing this we can still derive the final image plane size/position yet have better control on customizing camera parameters.

## Camera Positioning
>This section is corresponding to Chapter 10 "Positionable Camera" of [Ray Tracing in One Weekend](http://in1weekend.blogspot.com/2016/01/ray-tracing-in-one-weekend.html).

If the open angle of camera lense is ```theta```, then ```half_height = tan(theta/2)```. ```theta``` is given by the **vertical field of view(FOV)** of the camera ```vfov```, however in the unit of radian for convenience of calculation. So convertion ```theta = vfov*M_PI / 180``` is needed where ```M_PI``` is value $\pi$ from ```<math.h>``` standard library.

Then if still keep the rest of camera settings the same, we can derive all the needed coordinates for image plane like this:

```c
lower_left_corner(-half_width, -half_height,-1.0);
horizontal(2*half_width, 0.0, 0.0); // horizontal range
vertical(0.0, 2*half_height, 0.0);  // vertical range
origin = (0,0,0);
```
In world space, the set of vectors ${e1 = (1, 0, 0), e2 = (0, 1, 0), e3 = (0, 0, 1)}$ (the standard basis) forms an [orthonormal basis](https://en.wikipedia.org/wiki/Orthonormal_basis). All vectors (x, y, z) in world space can be expressed as a sum of the basis vectors scaled ${\displaystyle (x,y,z)=xe_{1}+ye_{2}+ze_{3}}$.

Hence the previous derivation if put mathematically should be:

- lower_left_corner= origin - half_width * $e1$ - half_height * $e2$ - $e3$
- horizontal = 2 * half_width * $e1$
- vertical = 2  *half_height * $e2$

But if we want to transform camera to position ```lookfrom``` pointing to position ```lookat```, we have to build a new orthonormal basis for camera space with the set of vetors $u,v,w$. They are defined as following:

```c
w = unit_vector(lookfrom - lookat) // similar to the Z axis
u = unit_vector(cross(vup, w)) // similar to the X axis
v = cross(w, u) // similar to the Y axis
```

Conventionally, camera space up-vector ```vup``` is using (0，1，0).

Use the new basis $u,v,w$ to accordingly replace the old basis $e1,e2,e3$, we get the expanded camera model with new functionality of free positioning:

```c
#include <math.h> // M_PI
#include "ray.h"
class camera {
public:
    camera(vec3 lookfrom, vec3 lookat, vec3 vup, float vfov, float aspect) {
        vec3 u, v, w;

        float theta = vfov*M_PI/180;
        float half_height = tan(theta/2);
        float half_width = aspect * half_height;
        origin = lookfrom;

        w = unit_vector(lookfrom - lookat);
        u = unit_vector(cross(vup, w));
        v = cross(w, u);

        lower_left_corner = origin - half_width*u - half_height*v -w;
        horizontal = 2*half_width*u;
        vertical = 2*half_height*v;
    }
    ray get_ray(float s, float t) {return ray(origin, lower_left_corner + s*horizontal + t*vertical - origin);}

    vec3 lower_left_corner;
    vec3 horizontal;
    vec3 vertical;
    vec3 origin;
};
```

## Camera Depth of Field
>This section is corresponding to Chapter 11 "Defocus Blur" of [Ray Tracing in One Weekend](http://in1weekend.blogspot.com/2016/01/ray-tracing-in-one-weekend.html).

Image from - Wikipedia

>In optics, an aperture is a hole or an opening through which light travels. More specifically, the **aperture** and **focal length** of an optical system determine the cone angle of a bundle of rays that come to a focus in the image plane.

Image from - Wikipedia

Before, the focus length (or focus distance ```focus_dist```) was defaulted at -1 on Z/w axises with image plane located at (0,0,-1). Now we are going to apply the customizable value ```focus_dist```, and the coordinates for defining the image plane become:

```c
lower_left_corner = origin - half_width*focus_dist*u - half_height*focus_dist*v - focus_dist*w;
horizontal = 2 * half_width*focus_dist*u;
vertical = 2 * half_height*focus_dist*v;
```

For the implementation of aperture, simply **add a random value onto ray origin**. The intensity of the randomness is controlled by lense radius ```lens_radius``` which is half of ```aperture``` value. So the implementation of the final camera model is:

```c
#include "camera.h"
vec3 random_in_unit_disk() {...}

ray camera::get_ray(float s, float t) {
    vec3 rd = lens_radius * random_in_unit_disk(); // get random value
    vec3 offset = u * rd.x() + v * rd.y(); // calculate random offset vector
    // randomize ray casting
    return ray(origin + offset, lower_left_corner + s*horizontal + t*vertical - origin - offset);
}
```
And the corresponding final camera model full defination is:
```c
class camera {
public:
    camera(vec3 lookfrom, vec3 lookat, vec3 vup, float vfov, float aspect, float aperture, float focus_dist)
    {
        lens_radius = aperture / 2;

        float theta = vfov * M_PI / 180;
        float half_height = tan(theta / 2);
        float half_width = aspect * half_height;
        origin = lookfrom;

        w = unit_vector(lookfrom - lookat);
        u = unit_vector(cross(vup, w));
        v = cross(w, u);

        lower_left_corner = origin - half_width*focus_dist*u - half_height*focus_dist*v - focus_dist*w;
        horizontal = 2 * half_width * focus_dist * u;
        vertical = 2 * half_height * focus_dist * v;
    }

    ray get_ray(float s, float t);

    vec3 origin;
    vec3 lower_left_corner;
    vec3 horizontal;
    vec3 vertical;
    vec3 u, v, w;
    float lens_radius;
};
```

TBC

gha_language: HTML


text:
# Coding Quiz

Homework four of the OSU coding bootcamp.

## Description

In this Project i created a coding quiz that tests the players knowledge of web development concepts. After the timer or the player completes answering all the questions they are displayed their final score and are prompted to enter their initials
to be put into the highscores.
Link to live project: https://kekons4.github.io/codingquiz

## Screenshots

![screenshot_one](/Assets/screenshots/screenshot_one.png)

##### screenshot of the homepage.

![screenshot_two](/Assets/screenshots/screenshot_two.png)

##### screenshot of question with timer above.

![screenshot_three](/Assets/screenshots/screenshot_three.png)

##### screenshot of results page, where player can enter initials.

![screenshot_four](/Assets/screenshots/screenshot_four.png)

##### screenshot of highscore page which displays all highscores of previous players.

## Installation

Clone the repository at https://github.com/kekons4/codingquiz.git add load it on
code editor of your choice. Vscode is the prefered editor.

## Credits

Keon Pourboghrat https://github.com/kekons4

## License

MIT License
![test](https://img.shields.io/apm/l/test)


text:
# StringGrabber
Grabs a RegEx string from a large number of documents and ouputs them into a CSV file.

## Synopsis

This simple Ruby script will take any files you place in the “input” file, extracts any emails it finds, places them in a new CSV file, and removes the original files. How it works is still a bit clumsy, so feel free to submit a pull request and make it better!

Enjoy!

## Dependencies
- Requires Ruby 2.2.3 (update/install Ruby using HomeBrew: https://brew.sh)
- A Regular Expression string of your choosing (get a RegEx here: http://regexr.com)

## Code Explanation

```
|-Dir
|--input	<- Here’s where you put your files
|--readme.md	<- This is, um, the file you’re reading.
|--replace.rb	<- Your ruby script.
|--output.csv 	<— And the new file where all your search terms are collected.
```

To run the Ruby file in Terminal (on Mac):
```
~You: ruby replace.rb
```

## Reg Ex and Searching

You don’t have to search for emails, you can search for any Regular Expression. Find new ones on regexr.com or another Reg Ex generator.

## Motivation

If you’ve ever wanted to extract emails from a large number of files of various types, you can probably appreciate the simplicity of this one.

## Contributors

Joe Hanko — github.com/joehanko

## License

MIT License

Copyright (c) 2017 Joe

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. 

repository: joehanko/StringGrabber

repo_name: joehanko/StringGrabber


text:
# react-cloud-state

A minimal state management library for [React](https://reactjs.org/tutorial/tutorial.html).

# Important Notice

Repo has been moved to [lib](https://github.com/Jamyth/libs/tree/master/packages/react-cloud-state)

# Licenses

MIT licensed. Copyright (c) Jamyth Luk 2020.

repository: Jamyth/react-cloud-state

repo_name: Jamyth/react-cloud-state


text:
# Sample Petstore Python 3 application

Here's a Python 3.2 [Swagger](http://swagger.wordnik.com/) client with unit
tests for the Petstore sample application. See the interactive Swagger
documentation at http://petstore.swagger.wordnik.com/ for more information on
this demonstration API.

The client contained in ```petstore``` was generated using this
```swagger-codegen``` project, with the following command:

    ./bin/runscala.sh com.wordnik.swagger.codegen.BasicPython3Generator http://petstore.swagger.wordnik.com/api/resources.json special-key

To run the tests, issue a command like the following:

    python3.2 tests/BaseApiTest.py

repository: esfand/swagger-codegen

repo_name: esfand/swagger-codegen


text:
---
layout: post
title: Wrapping Up
lang: en
description: Wrapping up the tutorial and going over the next steps.
date: 2018-03-30 00:00:00
ref: wrapping-up
code: sst_full
comments_id: comments-for-wrapping-up/100
---

Congratulations on completing the guide!

### App in Prod

We've covered how to build and deploy our backend serverless API and our frontend serverless app. And not only does it work well on the desktop.

![App update live screenshot](/assets/app-update-live.png)

It's mobile optimized as well!

### Manage in Prod

One final thing! You can also manage your app in production with the [SST Console]({{ site.docs_url }}/console ).

Run the following in your project root.

```bash
$ npx sst console --stage prod
```

This'll allow you to connect your SST Console to your prod stage.

```txt
SST Console: https://console.sst.dev/notes/prod/stacks
```

It'll show you all the resources in production.

![SST Console prod stacks tab](/assets/part2/sst-console-prod-stacks-tab.png)

All your users.

![SST Console prod Cognito tab](/assets/part2/sst-console-prod-cognito-tab.png)

The notes your users have created.

![SST Console prod DynamoDB tab](/assets/part2/sst-console-prod-dynamodb-tab.png)

You can even see the request logs in production.

![SST Console prod functions tab](/assets/part2/sst-console-prod-functions-tab.png)

---

We hope what you've learned here can be adapted to fit the use case you have in mind. We are going to be covering a few other topics in the future while we keep this guide up to date.

We'd love to hear from you about your experience following this guide. Please [**fill out our survey**]({{ site.survey_url }}) or send us any comments or feedback you might have, via [email](mailto:{{ site.email }}). And [please star our repo on GitHub]({{ site.sst_github_repo }}), it really helps spread the word.

Star our GitHub repo

Also, we'd love to feature what you've built with SST, please [send us a URL and brief description](mailto:{{ site.email }}).

Thank you and we hope you found this guide helpful!

gha_language: SCSS


text:
##Description:

Anti-caching headers have the ability to tell the browser,
computer and proxies what information they may or may not store on the intermediate media

##Mitigation:

These headers are also known as the: Cache-control: no-store,no-cache and provide
protection of sensitive information when implemented in the application or web-server.

Rightly configured anti caching headers will look like the following as a response

	Expires: Tue, 03 Jul 2001 06:00:00 GMT
	Last-Modified: {now} GMT
	Cache-Control: no-store, no-cache, must-revalidate, max-age=0
	Cache-Control: post-check=0, pre-check=0
	Pragma: no-cache


text:
**Note:** This is the App setup section in [Setup Ruby On Rails on
Mac OS X 10.11 El Capitan](https://gorails.com/setup/osx/10.11-el-capitan)

## Table of contents

- [Create new app](#create-new-app)
- [Setup Capistrano](#setup-capistrano)
- [Setup Pow](#setup-pow)
  - [Accessing virtual hosts from other computers](#Accessing-virtual-hosts-from-other-computers)
- [Initialize Git](#initialize-git)
- [Initialize specific gems](#initialize-specific-gems)
- [Additional notes](#additional-notes)

## Create new app

```shell
#### NOTE: change APPNAME
# Note you will need to change config/database.yml's username to be the same as your OSX user account. (for example, mine is 'greg')
rails new APPNAME --database postgresql --skip-test --skip-turbolinks

# Move into the application directory
cd APPNAME

# If you setup the database with a username/password, add the username/password to the config/database.yml file

# Create the database
rake db:create
```

### Different version setup

```
# make directory for new rails app
mkdir app
cd app

# install the correct Ruby version
rbenv install 2.3.1
rbenv local 2.3.1
ruby -v

# specify ruby version
echo 2.3.1 > .ruby-version

# initialize bundler (creates Gemfile)
bundler init

# specify rails version in Gemfile
gem "rails", "4.2.5"

# create rails app using specified version
bundle exec rails new .
```

If you received an error that said `Access denied for user 'root'@'localhost' (using password: NO)` then you need to update your config/database.yml file to match the database username and password.

## Setup Capistrano

> **NOTE:** Make sure you do the following steps on your development machine inside your Rails app

```ruby
# Add to Gemfile

# Capistrano for automatic deployment
gem 'capistrano', '~> 3.7', '>= 3.7.1'
gem 'capistrano-rails', '~> 1.2'
gem 'capistrano-passenger', '~> 0.2.0'
gem 'capistrano-rbenv', '~> 2.1'
```

```shell
bundle
cap install STAGES=staging,production
```

```ruby
# Replace Capfile with the following:

require "capistrano/setup"
require "capistrano/deploy"
require 'capistrano/rails'
require 'capistrano/passenger'
require 'capistrano/rbenv'
require "capistrano/scm/git"
install_plugin Capistrano::SCM::Git

set :rbenv_type, :user
set :rbenv_ruby, '2.4.0'

# Load custom tasks from `lib/capistrano/tasks` if you have any defined
Dir.glob("lib/capistrano/tasks/*.rake").each { |r| import r }

```

```ruby
###### NOTE: Change APPNAME and change greganswer if necessary
# config/deploy.rb

app_name = 'APPNAME'

set :application, app_name
set :repo_url, "git@github.com:greganswer/#{app_name}.git"

set :deploy_to, "/home/deploy/#{app_name}"

append :linked_files, "config/database.yml", "config/secrets.yml"
append :linked_dirs, "log", "tmp/pids", "tmp/cache", "tmp/sockets", "vendor/bundle", "public/system", "public/uploads"
```

```ruby

###### NOTE: Replace IPADDRESS with your server's IP address!
# config/deploy/production.rb
# config/deploy/staging.rb
server 'IPADDRESS', user: 'deploy', roles: %w{app db web}
```

## Setup Pow

[Pow](http://pow.cx/) is a is a zero-config Rack server for Mac OS X. It allows you to directly map folders to a local URL.

**Example:**
```shell
/root/path/code/projectname -> http://projectname.dev/
```

**Setup:**
```shell
curl get.pow.cx | sh
echo 'export PATH="$HOME/.rbenv/shims:$HOME/.rbenv/bin:$PATH"' >> ~/.powconfig && touch ~/.pow/restart.txt
```

**Additional commands:**

```shell
# Restart the server
touch ~/.pow/restart.txt

# Configure
ln -s /path/to/myapp ~/.pow

# Remove a Link:
cd ~/Library/Application Support/Pow/Hosts
rm link_name
```

#### Accessing virtual hosts from other computers

Construct your xip.io domain by appending your application's name to your LAN IP address followed by .xip.io. For example, if your development computer's LAN IP address is <IP_ADDRESS>, you can visit myapp.dev from another computer on your local network using the URL:

```
http://myapp.<IP_ADDRESS>.xip.io/
```

## Initialize Git

```shell
git init && git add .gitignore && git commit -m 'Intialize Repository'
git add . && git commit -m 'Initialize Rails'
```

1. Setup Remote repository at https://github.com/new
1. Enter project name
1. Enter discription
1. Select public or private
1. Click *Create repository*
1. copy the code from *…or push an existing repository from the command line* and paste in the command line

## Initialize specific gems

```shell
rails generate cucumber:install && rails generate rspec:install
```

## Additional notes

- If in terminal and `rails c` fails, run `ln -s /usr/local/opt/readline/lib/libreadline.dylib /usr/local/opt/readline/lib/libreadline.6.dylib`
`

license: Unlicense

repository: greganswer/devnotes

gha_language: JavaScript

gha_license_id: Unlicense

repo_name: greganswer/devnotes


text:
# UnbreakEn
Enchantment that will save your instrument.

This modification adds only one enchantment. It will not allow your tool to break when its durability reaches zero. However, you can not use this tool or hit someone. Attention, not applicable to armor.

repository: MJaroslav/UnbreakEn

gha_language: Java

repo_name: MJaroslav/UnbreakEn


text:
# Changelog

All notable changes to `laravel-mail-log-channel` will be documented in this file.

## 2.0.1 - 2020-02-21

- support multiple `to` configuration formats

## 2.0.0 - 2020-01-29

- add support for Laravel 6 and 7 (thanks to @jbeales https://github.com/designmynight/laravel-log-mailer/pull/7)
- remove extra configuration and view files
- improve exception layout in mails

## 1.0.2 - 2018-09-09

- fix logging levels

## 1.0.1 - 2018-09-05

- fix dependancy

## 1.0.0 - 2018-09-04

- initial release

gha_language: PHP


text:
# A simple maven deployer for Travis jobs

Required properties (defined in Travis):
- DEPLOYER_URL: contains 4 files: (ex: https://raw.githubusercontent.com/Gilandel/deployer/master)
  - pushingkey.enc: the private key used to push modified files after releasing
  - pubring.gpg: the public key used to validate the jar signature
  - secring.gpg.enc: the private key used to sign jar
  - settings.xml: the maven user settings, where public repository is defined
- ENCPRYPTED_KEY: the encryption key
- ENCPRYPTED_IV: the encryption initialization vector
- GIT_EMAIL: Email used during the git push after releasing
- GIT_USER: User name used during the git push after releasing
- OSSRH_JIRA_USERNAME: OSS Repository Hosting user's name injected into settings.xml to stage the artifacts
- OSSRH_JIRA_PASSWORD: OSS Repository Hosting password injected into settings.xml to stage the artifacts
- DEBUG: if set to true, inject '-e -X' parameters into Maven commands (optional parameter)

## Prepare the encryption keys and signatures

For SSH key generation, follow [GITHUB tutorial](https://help.github.com/articles/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent/)

Create gpg key:
```
gpg --gen-key
```

Add a revocation certificate:
```
gpg --output revoke.asc --gen-revoke<EMAIL_ADDRESS>```

Check if pair private/public is generated:
```
gpg --list-key
-------------------------------
pub   4096R/XXXXXXXX 2017-03-17
uid                  Firstname Lastname (my comment<EMAIL_ADDRESS>sub   4096R/YYYYYYYY 2017-03-17
```

Export keys (for both use pub key identifier):
```
gpg --output secring.gpg --export-secret-key XXXXXXXX
gpg --output pubring.gpg --export XXXXXXXX
```

Export keys in ASCII (for both use pub key identifier):
```
gpg --export -a XXXXXXXX > pubring.asc
gpg --export-secret-keys -a XXXXXXXX > secring.asc
```

Encode GITHUB keys:
```
openssl aes-256-cbc -in "~/.ssh/id_rsa" -out "pushingkey.enc" -p -e
```

Keep the result (ENCPRYPTED_KEY=key, ENCPRYPTED_IV=iv):
```
salt=XXXXXXXXXXXXXXXX
key=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
iv =XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
```

Encode the second file:
```
openssl aes-256-cbc -K $ENCPRYPTED_KEY -iv $ENCPRYPTED_IV -in "./secring.gpg" -out "secring.gpg.enc" -p -e
```

Do not forgot to distribute your public gpg signing key (pubring.gpg or pubring.asc) on one of these keys servers for example:
- [keyserver.ubuntu.com](http://keyserver.ubuntu.com),
- [pgp.mit.edu](http://pgp.mit.edu),
- [keyserver.pgp.com](http://keyserver.pgp.com).

## How to deploy to Maven Central

In your Travis file `.travis.yml`, add the following lines (example: [utils-assertor .travis.yml](https://github.com/Gilandel/utils-assertor/blob/master/.travis.yml)):
```yaml
after_success:
  # Stage artifacts
  - curl $DEPLOYER_URL/deploy.sh | bash
```

Don't forget to add distributionManagement, licenses... parts in your pom.xml, example: [utils project pom](https://github.com/Gilandel/utils/blob/master/pom.xml).

The logic is based on two branches, master (the develop branch) and release (the branch to release).

At each push on master branch, a snapshot will be deploy to OSSRH [https://oss.sonatype.org/content/repositories/snapshots](https://oss.sonatype.org/content/repositories/snapshots).

At each merge on release branch, a release is launched and pushed to [https://oss.sonatype.org/service/local/staging/deploy/maven2/](https://oss.sonatype.org/service/local/staging/deploy/maven2/) (the master branch is automatically merged post release).

After the first stage is completed and checked by the oss team, the release will be deployed to central maven repository (around 2 hours after).

## Codacity coverage reporter

In your Travis file `.travis.yml`, add Codacity reporter install step:
```yaml
install:
  # Install Codacity coverage reporter (install build reporter)
  - curl $DEPLOYER_URL/codacity-coverage-reporter-install.sh | sudo bash
```

Call the reporter and cleanup:
```yaml
after_success:
  # Call Codacity coverage reporter
  - curl $DEPLOYER_URL/codacity-coverage-reporter-runner.sh | bash -s -- -l Java -r target/site/jacoco/jacoco.xml
```

## License
Apache License, version 2.0

repository: Gilandel/deployer

repo_name: Gilandel/deployer


text:
# Digital Image Processing

This folder contains some utility functions to help some common question in digital image processing.

## How to use?
You can either jupyter and open the notebook file locally or you can open this jupyter notebook in google colab by simplly uploading it to goodle drive.

If you are running it locally you might need ko install following packages:
 - opencv
 - pandas
 - sympy
 - numpy
 - tabulate

## Credits

Alot of function written here are written by [@ameerhmzx](https://github.com/ameerhmzx/).

repository: nmanumr/comsats-scripts

repo_name: nmanumr/comsats-scripts


text:
# Disambiguation of Neural Disambiguation of Causal Lexical Markers Based on Context

Causation is part of the human mental model of reasoning, so it is crucial the understanding of causal relations in text in order to build the causal reasoning expressed by an human in a piece of text. This work is focused on the disambiguation of the causal meaning of lexical markers or discurse connectives. The disambiguation system is based on deep learning and the use of dense vector spaces to represent the meaning of the input utterances. The data used is the AltLex Corpus (Hidey and McKeown, 2016) ([repository](https://github.com/chridey/altlex "repository of AltLex corpus"), [paper](https://www.aclweb.org/anthology/P/P16/P16-1135.pdf "paper of AltLex corpus")), and the results reached outperform the state-of-the-art on that corpus.

Please use the following citation:

```
@InProceedings{martinezCamara:2017:iwcs2017,
  author    = {Mart{\'i}nez C{\'a}mara, Eugenio and Shwartz, Vared and Gurevych, Iryna and Dagan, Ido},
  title     = {Neural Disambiguation of Causal Lexical Markers Based on Context},
  booktitle = {Proceedings of the 12th International Conference on Computational Semantics (IWCS 2017)},
  month     = September,
  year      = {2017},
  pages     = {(to appear)}
}
```

> **Abstract:** Causation is a psychological tool of humans to understand the world and it is projected in natural language. Causation relates two events, so in order to understand the causal relation of those events and the causal reasoning of humans, the study of causality classification is required. We claim that the use of linguistic features may restrict the representation of causality, and dense vector spaces can provide a better encoding of the causal meaning of an utterance. Herein, we propose a neural network architecture only fed with word embeddings for the task of causality classification. Our results show that our claim holds, and we outperform the state-of-the-art on the AltLex corpus.

Contact person: Eugenio Martínez Cámara<EMAIL_ADDRESS>
https://www.ukp.tu-darmstadt.de/

https://www.tu-darmstadt.de/

Don't hesitate to send us an e-mail or report an issue, if something is broken (and it shouldn't be) or if you have further questions.

> This repository contains experimental software and is published for the sole purpose of giving additional background details on the respective publication.

## Project structure
**(change this as needed!)**

* `folder/src` -- The code of the experiments
* `folder/src/semantic_relation_classification_console_app.py` -- The main file of the application
* `folder/model` -- The files of the application
* `data/config` -- The configuration files

## Requirements

* python 3.5.4
* tensorflow 0.11.0rc2
* numpy 1.12.1
* scikit-learn 0.18
* NLTK 3.2.1
* If you use GPU: Cuda 8.0
* Word embeddings: You have to use the Common Crawl (840B tokens, 2.2M vocab, cased, 300d vectors, 2.03 GB download) version of Glove: http://nlp.stanford.edu/data/glove.840B.300d.zip

## Installation

In order to run the code used for the experiments of the paper, you have to know the following:

1.- You can evaluate the two neural arquitectures of the paper:
  * Stated_Pair_LSTM
  * Pair_LSTM
2.- You can evaluate the three zero-padding strategies:
  * Maximum
  * Mean
  * Mode
3.- You can evaluate the two optimizers:
  * Adadelta
  * Adam

Configuration:
------------------

To evaluate the different configurations of the network you have to use one of the files of the folder "config". Depending on the arquitecture you want to evaluate you have to use a different file:

* For the arquitecture `Stated_Pair_LSTM`: Please use the configuration files: config_altlex_sentence_encoding_lstm_stated_
* For the arquitecture `Pair_LSTM`: Please use the configuration files: config_altlex_sentence_encoding_lstm_

The name of the zero-padding strategy (max, mean, mode) and the optimizer (adadelta, adam) are in the name of the file. For instance, if you want to evaluate the arquitecture Pair_LSTM_Mean_Adam, you have to use the configuration file config_altlex_sentence_encoding_lstm_lexical_marker_in_second_argument_mean_adam.txt.

Before the running of the application, you have to set some paths in the configuration file:

* PATH_PROPOSITION_CORPUS --> The path of the training corpus.
* PATH_CORPUS_DEV --> The path of the development corpus.
* PATH_PROPOSITION_CORPUS_TEST --> The path of the test corpus.
* WORD_EMBEDDINGS_PATH --> The path to the word embeddings file
* NN_ENVIRONMENT_LOG_DIG --> The path to store the models of each epoch
* NN_ENVIRONMENT_MODEL_DIR --> The path to store the best model

You can also configure out the number of epochs, the batch size, the drop out and the regularization

* DROP_OUT_TRAINING --> The drop out value, for instance: 0.5
* LANDA_REGULARIZATION --> The regularization value, for instance: 8e-3
* LANDA_LOSS_REGULARIZATION --> The alpha value of regularization, for instance: 0.1
* NUMBER_OF_EPOCHS --> The number of epochs
* SIZE_OF_BATCHES --> The size of the batches

You can configure the number of dense layers:

* NUMBER_OF_DENSE_LAYERS

Run
------------------

To run the experimenst you have to go to the folder code and run the following command:

python3 semantic_relation_classification_console_app.py --config_file [path to the configuration file]

If you want to see the logging information, please run the following command:

python3 semantic_relation_classification_console_app.py --config_file [path to the configuration file] --logging --log_level DEBUG

### Expected results

After running the experiments, you should expect the results that are in the paper (The link will be published soon).