text:
# Build 2019 Demos for Knowledge Mining Session

This repo contains the source code associated with the //Build session ["Try this one weird AI trick on your data. Turn any data into structured knowledge using the new Knowledge Mining capabilities of the Azure AI platform"](
https://mybuild.techcommunity.microsoft.com/sessions/76964?source=sessions#top-anchor)

## References
* [Online Demo](https://liamca.github.io/StackExchangeTravelDemo/index.html)
* [StackExchange Travel Data Dump](https://stackoverflow.blog/tags/cc-wiki-dump/)
* [StackExchange Travel](https://travel.stackexchange.com/)

![StackExchange Travel Demo](https://github.com/liamca/build2019aidemos/blob/master/stackexchange_travel_demo.png)


text:
---
layout: post
title: "The Enterprise"
subtitle: "So what's under the hood at Superion Air"
cover_image: dc3-i-logo.png
excerpt: "Let's take a peak under the hood at Superion Air"
author:
  name: John Stauffacher
  twitter: g33kspeed
  gplus:<PHONE_NUMBER>83253104599
  bio: Defensive Security Expert
  image: js.jpg
---

##Superion Air
The staff at Superion Air have done quite a bit with not a lot for some time. Their main infrastructure features a cloud enabled application, and a database server. All of these run on a cluster of VMWare ESX 5.5 servers. These servers are aging Dell 2950 servers with dual quad core processors. Two of the machines have 16GB of ram the other has 32GB. Their storage is provided by a commodity iSCSI array.

 This website runs under the WordPress CMS platform, and is the main interface between Superion Air and their customers. This Website is where Superion Air books travel for their customers, and updates their pilot schedules and maintenance operations. This website is key to Superion Air, and their current Cloud expense is making management think that they may have to start raising prices. They need to take down the bot traffic to get their Cloud expenses under control. A wpscan report is listed below and available [here]({% postfile client-superionair-co-wpscan.txt %}) :

### WordPress
```
    [+] URL: https://client.superionair.co/
    [+] Started: Fri Jun 05 12:51:58 2015

    [+] robots.txt available under: 'https://client.superionair.co/robots.txt'
    [+] Interesting header: LINK: <https://client.superionair.co/>; rel=shortlink
    [+] Interesting header: SERVER: nginx/1.8.0
    [+] Interesting header: X-POWERED-BY: PHP/5.4.16
    [+] XML-RPC Interface available under: https://client.superionair.co/xmlrpc.php

    [+] WordPress version 4.2.2 identified from meta generator

    [+] WordPress theme in use: theme1770

    [+] Name: theme1770
     |  Location: https://client.superionair.co/wp-content/themes/theme1770/
     |  Style URL: https://client.superionair.co/wp-content/themes/theme1770/style.css
     |  Theme Name: theme1770
     |  Theme URI: https://superionair.co
     |  Description: Superion Air
     |  Author: Superion Air

    [+] Enumerating plugins ...
    [+] We found 7 plugins:

    [+] Name: akismet - v3.1.2
     |  Location: https://client.superionair.co/wp-content/plugins/akismet/
     |  Readme: https://client.superionair.co/wp-content/plugins/akismet/readme.txt

    [+] Name: booking
     |  Location: https://client.superionair.co/wp-content/plugins/booking/

    [+] Name: cherry-plugin
     |  Location: https://client.superionair.co/wp-content/plugins/cherry-plugin/

    [+] Name: contact-form-7 - v4.2
     |  Location: https://client.superionair.co/wp-content/plugins/contact-form-7/
     |  Readme: https://client.superionair.co/wp-content/plugins/contact-form-7/readme.txt

    [+] Name: motopress-content-editor
     |  Location: https://client.superionair.co/wp-content/plugins/motopress-content-editor/

    [+] Name: revslider
     |  Location: https://client.superionair.co/wp-content/plugins/revslider/

    [+] Name: wordpress-importer - v0.6.1
     |  Location: https://client.superionair.co/wp-content/plugins/wordpress-importer/
     |  Readme: https://client.superionair.co/wp-content/plugins/wordpress-importer/readme.txt

    [+] Enumerating installed themes  ...
    [+] We found 2 themes:

    [+] Name: slide
     |  Location: https://client.superionair.co/wp-content/themes/slide/
     |  Style URL: https://client.superionair.co/wp-content/themes/slide/style.css
     |  Description:

    [+] Name: theme1770
     |  Location: https://client.superionair.co/wp-content/themes/theme1770/
     |  Style URL: https://client.superionair.co/wp-content/themes/theme1770/style.css
     |  Theme Name: theme1770
     |  Theme URI: https://superionair.co
     |  Description: Superion Air
     |  Author: Superion Air

    [+] Finished: Fri Jun 05 12:56:17 2015
    [+] Requests Done: 2022
    [+] Memory used: 38.754 MB
    [+] Elapsed time: 00:04:19
```
### Webserver
The team at Superion Air decided to go ahead and rely on Nginx for their main webserving needs. Nginx is quick, compact and doesn't have the memory footprint of Apache. The nginx config is listed below and available [here]({% postfile superion-air-nginx.conf %})
```
    user  nginx;
    worker_processes  1;

    error_log  /var/log/nginx/error.log warn;
    pid        /var/run/nginx.pid;

    events {
        worker_connections  1024;
    }

    http {
        include       /etc/nginx/mime.types;
        default_type  application/octet-stream;

        log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                          '$status $body_bytes_sent "$http_referer" '
                          '"$http_user_agent" "$http_x_forwarded_for"';

        access_log  /var/log/nginx/access.log  main;
        client_max_body_size 50M;
        sendfile        on;
        #tcp_nopush     on;

        keepalive_timeout  65;

        #gzip  on
        server {
            listen       443 ssl;
            server_name  client.superionair.co;

            ssl_certificate      /etc/nginx/cert.pem;
            ssl_certificate_key  /etc/nginx/cert.key;

            ssl_session_cache shared:SSL:1m;
            ssl_session_timeout  5m;

            ssl_ciphers  HIGH:!aNULL:!MD5;
            ssl_prefer_server_ciphers   on;
            access_log  /var/log/nginx/host.ssl.access.log  main;
            root /opt/superionair-test/wordpress;
            index index.php index.html index.htm;
            location / {
             try_files $uri $uri/ /index.php?$args;
            }
            location ~ \.php$ {
                fastcgi_split_path_info ^(.+?\.php)(/.*)$;
                if ( !-f $document_root$fastcgi_script_name) {
                        return 404;
                }
                fastcgi_pass   <IP_ADDRESS>:9000;
                fastcgi_index  index.php;
                fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
                include        fastcgi_params;
            }

        }
    }

```

### Database Backend
The backend database is served by a MySQL database.

license: MIT

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
##### springfox-swagger-ui

- Creates a webjar containing the swagger-ui static content.
- Adds a JSON endpoint `/swagger-resources` which lists all of the swagger resources and versions configured for a given
application.

Prior versions of this library included sdoc.jsp which caused all kinds of problems on
spring boot. This latest version now bundles a html (swagger-ui.html) instead.

The swagger ui version is specified in ./build.gradle where `swaggerUiVersion` is a git tag on the [swagger-ui repo]
(https://github.com/swagger-api/swagger-ui).

- All content is served from a webjar convention, relative url taking the following form:
`webjars/${project.name}/${project.version}` e.g: `/webjars/springfox-swagger-ui/<YOUR-SPRINGFOX-VERSION>/swagger-ui.html`

By default Spring Boot has sensible defaults for serving content from webjars. To configure vanilla spring web mvc apps to serve
 webjar content see the [webjar documentation] (http://www.webjars.org/documentation#springmvc)

repository: dilipkrish/swagger-springmvc

gha_language: Java

repo_name: dilipkrish/swagger-springmvc


text:
# jsImport - use ES6 imports in Haxe

With `-lib jsImport` you can decorate any extern class with `@:js.import` like so:

- `@:js.import(@star './some/path.js') extern class Foo {}` becomes `import * as Foo from './some/path.js'`
- `@:js.import(@default './some/path.js') extern class Foo {}` becomes `import Foo from './some/path.js'`
- `@:js.import('./some/path.js') extern class Foo {}` becomes `import { Foo } from './some/path.js'`

license: Unlicense


text:
# parse-reminder

> a node module to parse natural language reminders into who, what, and when.

It aims to support all common forms of natural language for reminders. For example:

- remind me to send invites at 3pm tomorrow
- remind me to wish Jamie happy birthday on 8/28
- remind me in 10 minutes to change the laundry
- remind me that the oil needs changed on Oct 4
- remind me next Friday to water the plants

## Usage

```js
var parseReminder = require('parse-reminder')

console.log(parseReminder('remind me to call the doctor tomorrow'))
// Output:
// { who: 'me',
//   what: 'call the doctor',
//   when: 2017-09-12T12:00:00.000Z }
```

license: ISC

gha_license_id: ISC


text:
## About
A very basic 16-bit RISC processor simulation. Runs on boredom.

Inspired by the Low Level JavaScript YouTube Channel: https://www.youtube.com/channel/UC56l7uZA209tlPTVOJiJ8Tw

## The CPU
A very basic 16-bit RISC processor simulation written entirely in C11 without the use of a standard library. The CPU itself is little endian, and runs on little endian machines, but it is unknown if it will work properly on big endian machines. The "interface" that drives it does use the ANSI C standard library. The CPU instructions, and word-size can be easily modified. The CPU does NOT support instruction pipelining.

## Planned Updates
> Floating-point operations

> Frame pointer

> Memory-mapped I/O

> Interrupts

> More instructions

> A more complex assembler

## Reference
```
USER REGISTERS
AD = 0b000 RT = 0b001 R0 = 0b010 R1 = 0b011
R2 = 0b100 R3 = 0b101 R4 = 0b110 R5 = 0b111

R0-R6: General purpose registers
AD: Intended to store jump addresses
RT: Intended to store return addresses
SP: Stack pointer
FP: Frame pointer
IP: Instruction pointer
FL: Flag register

FORMATS
S-Type = [15...9][9..0]                = [OPCODE][EXTRA]
I-Type = [15...9][8...8][7...0]        = [OPCODE][HALF][IMMEDIATE]
R-Type = [15...9][8...6][5...3][2...0] = [OPCODE][REGISTER][REGISTER][REGISTER]

INSTRUCTION SET
OPCODE  OP  INPUTS                 DESCRIPTION
0000000 hlt [NONE]               = stops the processor until interrupt

0010000 ll0 [immv]               = load [immv] into a lower $R0, extra bit: 0
0010000 lu0 [immv]               = load [immv] into a upper $R0, extra bit: 1
0010001 ll1 [immv]               = load [immv] into a lower $R1, extra bit: 0
0010001 lu1 [immv]               = load [immv] into a upper $R1, extra bit: 1
0010010 ll2 [immv]               = load [immv] into a lower $R2, extra bit: 0
0010010 lu2 [immv]               = load [immv] into a upper $R2, extra bit: 1
0010011 ll3 [immv]               = load [immv] into a lower $R3, extra bit: 0
0010011 lu3 [immv]               = load [immv] into a upper $R3, extra bit: 1
0010100 ll4 [immv]               = load [immv] into a lower $R4, extra bit: 0
0010100 lu4 [immv]               = load [immv] into a upper $R4, extra bit: 1
0010101 ll5 [immv]               = load [immv] into a lower $R5, extra bit: 0
0010101 lu5 [immv]               = load [immv] into a upper $R5, extra bit: 1
0010110 lla [immv]               = load [immv] into a lower $AD, extra bit: 0
0010110 lua [immv]               = load [immv] into a upper $AD, extra bit: 1

0100000 ldb [reg2] [reg1] [reg0] = load byte at address [reg1] into [reg2]
0100001 ldw [reg2] [reg1] [reg0] = load word at address [reg1] into [reg2]
0100010 stb [reg2] [reg1] [reg0] = store byte at address [reg1] into [reg2]
0100011 stw [reg2] [reg1] [reg0] = store word at address [reg1] into [reg2]
0100100 psh [reg2] [reg1] [reg0] = push [reg2] onto top of the stack and $SP += 2
0100101 pop [reg2] [reg1] [reg0] = pop stack and store top in [reg2] and $SP -= 2

0110000 cmp [reg2] [reg1] [reg0] = compares [reg1] with [reg0] and sets register FL (signed)
0110001 not [reg2] [reg1] [reg0] = binary not [reg1] and stores result in [reg2]
0110010 orr [reg2] [reg1] [reg0] = binary or [reg1] and [reg0] and stores result in [reg2]
0110011 and [reg2] [reg1] [reg0] = binary and [reg1] and [reg0] and stores result in [reg2]
0110100 xor [reg2] [reg1] [reg0] = binary xor [reg1] and [reg0] and stores result in [reg2]
0110101 add [reg2] [reg1] [reg0] = add [reg1] to [reg0] and stores result in [reg2]
0110110 sub [reg2] [reg1] [reg0] = subtract [reg1] by [reg0] and stores result in [reg2]
0110111 mul [reg2] [reg1] [reg0] = multiply [reg1] by [reg0] and stores result in [reg2]
0111000 div [reg2] [reg1] [reg0] = divides [reg1] by [reg0] and stores result in [reg2]
0111001 lsl [reg2] [reg1] [reg0] = logical shift left [reg1] by [reg0] and stores results in [reg2]
0111010 lsr [reg2] [reg1] [reg0] = logical shift right [reg1] by [reg0] and stores results in [reg2]

1000000 jmp [reg2] [reg1] [reg0] = jumps by [reg2] (signed) amount
1000001 jpr [reg2] [reg1] [reg0] = jumps by [reg2] (signed) amount and sets $RT = $IP + 2
1000010 beq [reg2] [reg1] [reg0] = jumps by [reg2] (signed) amount based on $FL
1000011 bgt [reg2] [reg1] [reg0] = jumps by [reg2] (signed) amount based on $FL
1000100 blt [reg2] [reg1] [reg0] = jumps by [reg2] (signed) amount based on $FL
```

repository: nguyen-t/VM

gha_language: C

repo_name: nguyen-t/VM


text:
### Functions

```solidity
contract SimpleAuction {
    function bid() public payable { // Function
        // ...
    }
}

// Helper function defined outside of a contract
function helper(uint x) pure returns (uint) {
    return x * 2;
}

```
Note:
A function in Solidity looks like this. Let's take a look at what this is doing -- we are creating an auction contract with some bid method that is payable.
We also have a helper pure function which multiplies a number by 2.

```rust
contract;

abi SimpleAuction {
  fn bid();
}

impl SimpleAuction for Contract {
  fn bid() {
    ..
  }
}

fn helper(x: u64) -> u64 {
  x * 2
}

```

Note:
Now, let's take a look at the equivalent Sway code.
There are three examples of functions here. Let's take a look at the function called `helper`. (point out: rust syntax, type annotation, return type, implicit return)

We have replaced the Solidity inheritence/constructor based system with a trait based system.
While in this code snippet, this results in a few more lines of boilerplate for Sway, in general, this is not the case. Less boilerplate and a more predictable system.
The `abi` keyword denotes what is essentially a trait -- a type class for you Haskellers, an interface for you Java beans. This defines an interface that can be imported
into other Sway programs to either implement contracts with the same interface, or, to interact with contracts. But we will get to that in a bit. For now, just know that the `abi`
keyword defines a special kind of trait, typeclass, what-have-you, that can be implemented on contracts themselves.

Functions are pure by default.

```solidity
contract Purchase {
    address public seller;

    modifier onlySeller() { // Modifier
        require(
          msg.sender == seller,
          "Only seller can call this."
        );
        _;
    }

    // Modifier usage
    function abort() public view onlySeller {
        // ...
    }
}
```

Note:
Because modifier behavior can be accomplished with function composition and traits, we chose not to use function modifiers.
This eliminates a lot of organizational and security issues related to their opaqueness and redirects. Additionally, when
an `_` is used to denote "paste the body of the modified function here", it is not optimized properly.

We also use an `assert` that is more similar to Rust's assert instead of require, but very similar.

```rust
contract;

let seller: Address = Address(
  0xDEADBEEF...
);

abi Purchase {
  view fn abort();
}

impl Purchase for Contract {
  view fn abort() {
    assert_eq!(context.caller_id, seller);
    abort_inner()
  }
}
```

Note:
view functions, constant values, deploy-time values, macros, assert_eq, modifiers can be solved with
function composition and have nothing to do with the blockchain therefore we didn't keep them

branch_name: refs/heads/main


text:
---
title: Email service
---

New since Unleash v4.0.0 is an email service allowing us to send reset password and welcome mails to new users. In order for this to work you'll need to tell unleash what SMTP service you'd like to send mails from.

If the service is not configured you'll see a log line every time you add a new user saying

```bash
[2021-05-07T12:59:04.572] [WARN] routes/user-controller.ts - email
was not sent to the user because email configuration is lacking
```

## Configuring {#configuring}

Depending on your deploy case there are different ways of configuring this service. Full documentation of all configuration possibilities is available [here](./configuring-unleash.md)

### Docker {#docker}

With docker, we configure the mail service via environment variables.

You'll want to at least include EMAIL_HOST, EMAIL_USER, EMAIL_PASSWORD and EMAIL_SENDER

Environment variables:

- EMAIL_HOST - Your SMTP server address
- EMAIL_PORT - Your SMTP server port - defaults to 567
- EMAIL_SECURE - whether to use SMTPS - set to `false` or `true` - defaults to false,
- EMAIL_USER - the username to authenticate against your SMTP server
- EMAIL_PASSWORD - the password for your SMTP user
- EMAIL_SENDER - which address should reset-password mails and welcome mails be sent from - defaults to<EMAIL_ADDRESS>which is probably not what you want.

### Node {#node}

With node, we can configure this when calling Unleash's start method.

```js
const unleash = require('unleash-server');

unleash.start({
  email: {
    host: 'myhost',
    smtpuser: 'username',
    smtppass: 'password',
    sender<EMAIL_ADDRESS>  },
});
```

repository: Unleash/unleash

gha_language: TypeScript

repo_name: Unleash/unleash


text:
Required parameters

-
photo_reference

    A string identifier that uniquely identifies a photo. Photo references are returned from either a Place Search or Place Details request.

Optional parameters

-
maxheight

    Specifies the maximum desired height, in pixels, of the image. If the image is smaller than the values specified, the original image will be returned. If the image is larger in either dimension, it will be scaled to match the smaller of the two dimensions, restricted to its original aspect ratio. Both the `maxheight` and `maxwidth` properties accept an integer between `1` and `1600`.

-
maxwidth

    Specifies the maximum desired width, in pixels, of the image. If the image is smaller than the values specified, the original image will be returned. If the image is larger in either dimension, it will be scaled to match the smaller of the two dimensions, restricted to its original aspect ratio. Both the `maxheight` and `maxwidth` properties accept an integer between `1` and `1600`.

Generated from the OpenAPI specification.
edit Edit
bug_report Report bug

repository: eti-kittichai/openapi-specification

repo_name: eti-kittichai/openapi-specification


text:
# LiteFrame: A PHP Micro Framework
[![Latest Stable Version](https://poser.pugx.org/avonnadozie/liteframe/v/stable)](https://packagist.org/packages/avonnadozie/liteframe)
[![Latest Unstable Version](https://poser.pugx.org/avonnadozie/liteframe/v/unstable)](https://packagist.org/packages/avonnadozie/liteframe)
[![Build Status](https://travis-ci.org/AVONnadozie/LiteFrame.svg?branch=master)](https://travis-ci.org/AVONnadozie/LiteFrame)
[![License](https://poser.pugx.org/avonnadozie/liteframe/license)](https://packagist.org/packages/avonnadozie/liteframe)

Frameworks are great but most are wild; difficult to setup, consume lots of resources, require advanced knowledge
of programming or knowledge of everything in some 100 page docs.

Although they have their benefits, it's a lot for a beginner, someone who is new to frameworks or someone simply behind schedule.

A typical setup process on a standard framework looks like this
 - Install composer (If it does not exist)
 - Run composer install
 - Generate app key
 - Configure env
 - Setup and run migration files
 - Configure server document root (I'm sorry if you're on a shared hosting, good luck hacking your way through)
 - And the list continues

LiteFrame is a small (micro) but powerful framework that selectively re-implements basic features of standard frameworks
in non heartbreaking ways.

## Features
- [x] Fast and lightweight
- [x] Easy setup (no shell commands required)
- [x] RedBeanPHP - automatically builds your database on the fly. (No migration files required)
- [x] Easy Routing
- [x] Middleware Support
- [x] Commands
- [x] Job Scheduling Support
- [x] Support for Blade Templating using [BladeOne](https://github.com/EFTEC/BladeOne)
- [ ] FlySystem Support (for files)
- [ ] Request and Data Validation
- [ ] Modularity
- [x] Unit Testing Support

## Installation
Download the latest release [here](https://github.com/AVONnadozie/LiteFrame/releases) and unzip it. that's all!

Still need it the Composer way?

```bash
composer create-project avonnadozie/liteframe
```

## Documentation
* Locally in [docs folder](./docs)
* [Online documentation](https://avonnadozie.github.io/LiteFrame/)

## Feedback
For bugs, improvements or guide, simply create an [issue](https://github.com/AVONnadozie/LiteFrame/issues). Thanks 👍

## How to Contribute
* Fork the project.
* Make your bug fix or feature addition.
* Add tests for it. This is important so we don't break it in a future version unintentionally.
* Send a pull request.

repository: AVONnadozie/LiteFrame

gha_language: PHP

gha_license_id: MIT

repo_name: AVONnadozie/LiteFrame


text:
# CSS: Content visibility

The `content-visibility` property allows you to control the visibility of elements on the page in a way that gives you actual performance benefits when compared to other properties that achieve the "same" visual effect. This property will tell the browser which elements/content it can skip the rendering phase. There are many values that can be used with `content-visibility`: `auto`, `layout`, `style`, `paint`, `size`, `hidden`. For example, you chunk content in a way that makes sense to your application and then apply the following property:

```css
.element {
  content-visibility: auto;
}
```

In shorts: This will effectively tell the browser do the rendering job of the object once it approaches the visible area.

**Note:** One thing to keep in mind is that this can cause shifting on the page if the element depend on content for its size. So, to avoid any jump, you should couple `content-visibility: auto` property along with `contain-intrinsic-size` because it will "act as a placeholder size in lieu of rendered content."

```css
.element {
  content-visibility: auto;
  contain-intrinsic-size: 200px;
}
```

> contain-intrinsic-size: "...effectively specifies the natural size of the element if the > element is affected by size containment"

There is also `content-visibility: hidden` that will give you more control over when the element should be actually rendered. Neat!

For more follow the [web.dev article about the content-visibility property](https://web.dev/content-visibility/)

repository: davi-mbatista/TIL

repo_name: davi-mbatista/TIL


text:
# Spotify playlist import

## What
Spotify playlist import is a simple command line tool that lets you import a text file with line separated tracks into a spotify playlist.

## Installation
You have to setup an app through the [Spotify Developer Dashboard](https://developer.spotify.com/) accepting Spotify terms.

repository: francescorw/spotify-playlist-import

gha_language: JavaScript

repo_name: francescorw/spotify-playlist-import


text:
# The Table

A Ping pong tracking application.

## Features:
  * Office Rankings
  * Challenge others
  * Keep score
  * View match
  * Record matches
  * Schedule matches
  * API

## Dependacies

The table is written on Ember and makes use of Tapas With Ember.

The Table also uses the following libraries:
  * moment.js
  * firebase
  * fireplace (for firebase)
  * Sass/Scss
  * Compass

## Setup

This applicaton requires and depends on firebase. You must go to firebase.com and setup an acount to obtain your firebase base URL.

      bundle install

next, you will need to install the node dependancies:

      npm install

Update your configuration files. (firebase base URL).

In app/config/enviornments

      window.TAPAS_ENV =
        name: 'development'
          db: 'https://<YOURFIREBASE>.firebaseio.com'

You will want a a development, test, and production version. Replace <YOURFIREBASE> with your firebase instance.

## Running the app

After you updated your firebase base URL, you can run the application.

      cake server

This will compile the server files, and host the site locally at http://localhost:3333

repository: patricksimpson/table

repo_name: patricksimpson/table


text:
# Tech Blog
  ![Badge for GitHub repo top language](https://img.shields.io/github/languages/top/jagatston/Tech-Blog?style=flat&logo=appveyor) ![Badge for GitHub last commit](https://img.shields.io/github/last-commit/jagatston/Tech-Blog?style=flat&logo=appveyor)

  Check out the badges hosted by [shields.io](https://shields.io/).

  ## Description

  For this project I was given an assignment to create a tech blog that users could post and comment on.
  ## Table of Contents
  * [Installation](#installation)
  * [License](#license)

  ## Installation

  *Steps required to install project and how to get the development environment running:*

  clone the repository, npm install to install dependencies, npm start to start server.

  ## License

  MIT License

  ---

  ## Questions?

repository: jagatston/Tech-Blog

repo_name: jagatston/Tech-Blog


text:
# Atanvarno\Router\Router
Interface for [PSR-7](http://www.php-fig.org/psr/psr-7/) HTTP request routers
built on top of [FastRoute](https://github.com/nikic/FastRoute).
```php
interface Router extends RequestMethodInterface
{
    // Constants
    public const DRIVER_CHAR_COUNT
    public const DRIVER_GROUP_COUNT
    public const DRIVER_GROUP_POS
    public const DRIVER_MARK
    public const METHOD_CONNECT
    public const METHOD_DELETE
    public const METHOD_GET
    public const METHOD_HEAD
    public const METHOD_OPTIONS
    public const METHOD_PATCH
    public const METHOD_POST
    public const METHOD_PURGE
    public const METHOD_PUT
    public const METHOD_TRACE

    // Methods
    public function add($methods, string $pattern, $handler): Router
    public function addGroup(string $patternPrefix, array $routes): Router
    public function connect(string $pattern, $handler): Router
    public function delete(string $pattern, $handler): Router
    public function dispatch(RequestInterface $request, bool $exceptions = false): array
    public function get(string $pattern, $handler): Router
    public function head(string $pattern, $handler): Router
    public function options(string $pattern, $handler): Router
    public function patch(string $pattern, $handler): Router
    public function post(string $pattern, $handler): Router
    public function purge(string $pattern, $handler): Router
    public function put(string $pattern, $handler): Router
    public function trace(string $pattern, $handler): Router
}
```
Extends [`Fig\Http\Message\RequestMethodInterface`](https://github.com/php-fig/http-message-util).

* [add](#add)
* [addGroup](#addGroup)
* [connect](#connect)
* [delete](#delete)
* [dispatch](#dispatch)
* [get](#get)
* [head](#head)
* [options](#options)
* [patch](#patch)
* [post](#post)
* [purge](#purge)
* [put](#put)
* [trace](#trace)

## add
Adds a route.
```php
add($methods, string $pattern, $handler): Router
```
Accepts an uppercase HTTP method string for which a certain route should
match. It is possible to specify multiple valid methods using an array. You
may use the `Router::METHOD_*` constants here.

Accepts a pattern to match against a URL path. By default the pattern uses a
syntax where `{foo}` specifies a placeholder with name `foo` and matching the
regex `[^/]+`. To adjust the pattern the placeholder matches, you can specify
a custom pattern by writing `{bar:[0-9]+}`. Some examples:
```php
// Matches /user/42, but not /user/xyz
$router->add(Router::METHOD_GET, '/user/{id:\d+}', 'handler');

// Matches /user/foobar, but not /user/foo/bar
$router->add(Router::METHOD_GET, '/user/{name}', 'handler');

// Matches /user/foo/bar as well
$router->add(Router::METHOD_GET, '/user/{name:.+}', 'handler');
```

Custom patterns for route placeholders cannot use capturing groups. For
example `{lang:(en|de)}` is not a valid placeholder, because `()` is a
capturing group. Instead you can use either `{lang:en|de}` or
`{lang:(?:en|de)}`.

Furthermore parts of the route enclosed in `[...]` are considered optional,
so that `/foo[bar]` will match both `/foo` and `/foobar`. Optional parts are
only supported in a trailing position, not in the middle of a route.

```php
// This route
$router->add(Router::METHOD_GET, '/user/{id:\d+}[/{name}]', 'handler');
// Is equivalent to these two routes
$router->add(Router::METHOD_GET, '/user/{id:\d+}', 'handler');
$router->add(Router::METHOD_GET, '/user/{id:\d+}/{name}', 'handler');

// Multiple nested optional parts are possible as well
$router->add(Router::METHOD_GET, '/user[/{id:\d+}[/{name}]]', 'handler');

// This route is NOT valid, as optional parts can only occur at the end
$router->add(Router::METHOD_GET, '/user[/{id:\d+}]/{name}', 'handler');
```

Accepts a handler of any value. The handler does not necessarily have to be a
callback, it could also be a controller class name or any other kind of data
you wish to associate with the route. The `dispatch()` method only tells you
which handler corresponds to your URI, how you interpret it is up to you.

### Parameters
* `string|string[]` **$methods**

  Required. HTTP method(s) for the route.

* `string` **$pattern**

  Required. URL path pattern for the route.

* `mixed` **$handler**

  Required. Any arbitrary handler value.

### Throws
* [`InvalidArgumentException`](InvalidArgumentException.md)

  HTTP method is invalid.

### Returns
* `Router` **$this**

  [Fluent interface](https://en.wikipedia.org/wiki/Fluent_interface), allowing
  multiple calls to be chained.

## addGroup
Adds a group of routes.
```php
addGroup(string $patternPrefix, array $routes): Router
```
All routes defined inside a group will have a common prefix. For example:
```php
$router->addGroup(
    '/admin',
    [
        [Router::METHOD_GET, '/do-something', 'handler'],
        [Router::METHOD_GET, '/do-another-thing', 'handler'],
        [Router::METHOD_GET, '/do-something-else', 'handler'],
    ]
);
// Will have the same result as:
$router->add(Router::METHOD_GET, '/admin/do-something', 'handler');
$router->add(Router::METHOD_GET, '/admin/do-another-thing', 'handler');
$router->add(Router::METHOD_GET, '/admin/do-something-else', 'handler');
```

### Parameters
* `string` **$patternPrefix**

  Required. Group prefix pattern.

* `array` **$routes**

  Required. Array of [`add()`](#add) parameter values.

### Throws
* [`InvalidArgumentException`](InvalidArgumentException.md)

  Routes array is invalid.

### Returns
* `Router` **$this**

  [Fluent interface](https://en.wikipedia.org/wiki/Fluent_interface), allowing
  multiple calls to be chained.

## connect
Adds a `CONNECT` method route.
```php
connect(string $pattern, $handler): Router
```

### Parameters
* `string` **$pattern**

  Required. URL path pattern for the route.

* `mixed` **$handler**

  Required. Any arbitrary handler value.

### Throws
Nothing is thrown.

### Returns
* `Router` **$this**

  [Fluent interface](https://en.wikipedia.org/wiki/Fluent_interface), allowing
  multiple calls to be chained.

## delete
Adds a `DELETE` method route.
```php
delete(string $pattern, $handler): Router
```

### Parameters
* `string` **$pattern**

  Required. URL path pattern for the route.

* `mixed` **$handler**

  Required. Any arbitrary handler value.

### Throws
Nothing is thrown.

### Returns
* `Router` **$this**

  [Fluent interface](https://en.wikipedia.org/wiki/Fluent_interface), allowing
  multiple calls to be chained.

## dispatch
Dispatches a [PSR-7](http://www.php-fig.org/psr/psr-7/) request.
```php
dispatch(RequestInterface $request, bool $exceptions = false): array
```
Returns an array whose first element contains a status code, one of:

* `FastRoute\Dispatcher::NOT_FOUND`
* `FastRoute\Dispatcher::METHOD_NOT_ALLOWED`
* `FastRoute\Dispatcher::FOUND`

For the method not allowed status the second array element contains a list of
HTTP methods allowed for the supplied request's URI. For example:
```php
[
    FastRoute\Dispatcher::METHOD_NOT_ALLOWED,
    [Router::METHOD_GET, Router::METHOD_POST]
]
```
> **NOTE:** The [HTTP specification]() requires that a `405 Method Not Allowed`
response include the `Allow:` header to detail available methods for the
requested resource. Applications using `Atanvarno\Router` should use the
second array element to add this header when relaying a `405` response.

For the found status the second array element is the handler that was
associated with the route and the third array element is a dictionary of
placeholder names to their values. For example:
```php
// Routing against GET /user/atanvarno/42
[
    FastRoute\Dispatcher::FOUND,
    'handler0',
    ['name' => 'atanvarno', 'id' => '42']
]
```

`dispatch()` can instead return only a found status array. For not found and
not allowed statuses, exceptions can be thrown. Use the second parameter to
enable this behaviour.

### Parameters
* [`RequestInterface`](http://www.php-fig.org/psr/psr-7/#psrhttpmessagerequestinterface) **$request**

  Required. [PSR-7](http://www.php-fig.org/psr/psr-7/) request to dispatch.

* `bool` **$exceptions**

  Optional. Defaults to `false`. Pass `true` to enable exceptions.

### Throws
* [`NotFoundException`](NotFoundException.md)

  The given request could not be matched. This is only thrown if `$exceptions`
  is passed as `true`. Otherwise, an array is returned.

* [`MethodNotAllowedException`](MethodNotAllowedException.md)

  Requested HTTP method is not allowed. This is only thrown if `$exceptions`
  is passed as `true`. Otherwise, an array is returned.

### Returns
* `array`

  The dispatch result array.

## get
Adds a `GET` method route.
```php
get(string $pattern, $handler): Router
```

### Parameters
* `string` **$pattern**

  Required. URL path pattern for the route.

* `mixed` **$handler**

  Required. Any arbitrary handler value.

### Throws
Nothing is thrown.

### Returns
* `Router` **$this**

  [Fluent interface](https://en.wikipedia.org/wiki/Fluent_interface), allowing
  multiple calls to be chained.

## head
Adds a `HEAD` method route.
```php
head(string $pattern, $handler): Router
```

### Parameters
* `string` **$pattern**

  Required. URL path pattern for the route.

* `mixed` **$handler**

  Required. Any arbitrary handler value.

### Throws
Nothing is thrown.

### Returns
* `Router` **$this**

  [Fluent interface](https://en.wikipedia.org/wiki/Fluent_interface), allowing
  multiple calls to be chained.

## options
Adds a `OPTIONS` method route.
```php
options(string $pattern, $handler): Router
```

### Parameters
* `string` **$pattern**

  Required. URL path pattern for the route.

* `mixed` **$handler**

  Required. Any arbitrary handler value.

### Throws
Nothing is thrown.

### Returns
* `Router` **$this**

  [Fluent interface](https://en.wikipedia.org/wiki/Fluent_interface), allowing
  multiple calls to be chained.

## patch
Adds a `PATCH` method route.
```php
patch(string $pattern, $handler): Router
```

### Parameters
* `string` **$pattern**

  Required. URL path pattern for the route.

* `mixed` **$handler**

  Required. Any arbitrary handler value.

### Throws
Nothing is thrown.

### Returns
* `Router` **$this**

  [Fluent interface](https://en.wikipedia.org/wiki/Fluent_interface), allowing
  multiple calls to be chained.

## post
Adds a `POST` method route.
```php
post(string $pattern, $handler): Router
```

### Parameters
* `string` **$pattern**

  Required. URL path pattern for the route.

* `mixed` **$handler**

  Required. Any arbitrary handler value.

### Throws
Nothing is thrown.

### Returns
* `Router` **$this**

  [Fluent interface](https://en.wikipedia.org/wiki/Fluent_interface), allowing
  multiple calls to be chained.

## purge
Adds a `PURGE` method route.
```php
purge(string $pattern, $handler): Router
```

### Parameters
* `string` **$pattern**

  Required. URL path pattern for the route.

* `mixed` **$handler**

  Required. Any arbitrary handler value.

### Throws
Nothing is thrown.

### Returns
* `Router` **$this**

  [Fluent interface](https://en.wikipedia.org/wiki/Fluent_interface), allowing
  multiple calls to be chained.

## put
Adds a `PUT` method route.
```php
put(string $pattern, $handler): Router
```

### Parameters
* `string` **$pattern**

  Required. URL path pattern for the route.

* `mixed` **$handler**

  Required. Any arbitrary handler value.

### Throws
Nothing is thrown.

### Returns
* `Router` **$this**

  [Fluent interface](https://en.wikipedia.org/wiki/Fluent_interface), allowing
  multiple calls to be chained.

## trace
Adds a `TRACE` method route.
```php
trace(string $pattern, $handler): Router
```

### Parameters
* `string` **$pattern**

  Required. URL path pattern for the route.

* `mixed` **$handler**

  Required. Any arbitrary handler value.

### Throws
Nothing is thrown.

### Returns
* `Router` **$this**

  [Fluent interface](https://en.wikipedia.org/wiki/Fluent_interface), allowing
  multiple calls to be chained.


text:
fzf :heart: vim
===============

Things you can do with [fzf][fzf] and Vim.

Rationale
---------

[fzf][fzf] itself is not a Vim plugin, and the official repository only
provides the [basic wrapper function][run] for Vim. It's up to the users to
write their own Vim commands with it. However, I've learned that many users of
fzf are not familiar with Vimscript and are looking for the "default"
implementation of the features they can find in the alternative Vim plugins.

This repository is a bundle of fzf-based commands and mappings extracted from
my [.vimrc][vimrc] to address such needs. They are *not* designed to be
flexible or configurable, and there's no guarantee of backward-compatibility.

Why you should use fzf on Vim
-----------------------------

Because you can and you love fzf.

fzf runs asynchronously and can be orders of magnitude faster than similar Vim
plugins. However, the benefit may not be noticeable if the size of the input
is small, which is the case for many of the commands provided here.
Nevertheless I wrote them anyway since it's really easy to implement custom
selector with fzf.

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

fzf.vim depends on the basic Vim plugin of [the main fzf
repository][fzf-main], which means you need to **set up both "fzf" and
"fzf.vim" on Vim**. To learn more about fzf/Vim integration, see
[README-VIM][README-VIM].

[fzf-main]: https://github.com/junegunn/fzf
[README-VIM]: https://github.com/junegunn/fzf/blob/master/README-VIM.md

### Using [vim-plug](https://github.com/junegunn/vim-plug)

```vim
Plug 'junegunn/fzf', { 'do': { -> fzf#install() } }
Plug 'junegunn/fzf.vim'
```

`fzf#install()` makes sure that you have the latest binary, but it's optional,
so you can omit it if you use a plugin manager that doesn't support hooks.

### Dependencies

- [fzf][fzf-main] 0.41.1 or above
- For syntax-highlighted preview, install [bat](https://github.com/sharkdp/bat)
- If [delta](https://github.com/dandavison/delta) is available, `GF?`,
  `Commits` and `BCommits` will use it to format `git diff` output.
- `Ag` requires [The Silver Searcher (ag)][ag]
- `Rg` requires [ripgrep (rg)][rg]
- `Tags` and `Helptags` require Perl

Commands
--------

| Command                | List                                                                                |
| ---                    | ---                                                                                |
| `:Files [PATH]`        | Files (runs `$FZF_DEFAULT_COMMAND` if defined)                                        |
| `:GFiles [OPTS]`       | Git files (`git ls-files`)                                                            |
| `:GFiles?`             | Git files (`git status`)                                                              |
| `:Buffers`             | Open buffers                                                                          |
| `:Colors`              | Color schemes                                                                         |
| `:Ag [PATTERN]`        | [ag][ag] search result (`ALT-A` to select all, `ALT-D` to deselect all)               |
| `:Rg [PATTERN]`        | [rg][rg] search result (`ALT-A` to select all, `ALT-D` to deselect all)               |
| `:RG [PATTERN]`        | [rg][rg] search result; relaunch ripgrep on every keystroke                           |
| `:Lines [QUERY]`       | Lines in loaded buffers                                                               |
| `:BLines [QUERY]`      | Lines in the current buffer                                                           |
| `:Tags [QUERY]`        | Tags in the project (`ctags -R`)                                                      |
| `:BTags [QUERY]`       | Tags in the current buffer                                                            |
| `:Marks`               | Marks                                                                                |
| `:Jumps`               | Jumps                                                                                |
| `:Windows`             | Windows                                                                               |
| `:Locate PATTERN`      | `locate` command output                                                               |
| `:History`             | `v:oldfiles` and open buffers                                                         |
| `:History:`            | Command history                                                                       |
| `:History/`            | Search history                                                                        |
| `:Snippets`            | Snippets ([UltiSnips][us])                                                            |
| `:Commits [LOG_OPTS]`  | Git commits (requires [fugitive.vim][f])                                              |
| `:BCommits [LOG_OPTS]` | Git commits for the current buffer; visual-select lines to track changes in the range |
| `:Commands`            | Commands                                                                              |
| `:Maps`                | Normal mode mappings                                                                  |
| `:Helptags`            | Help tags [1](#helptags)                                           |
| `:Filetypes`           | File types

- Most commands support `CTRL-T` / `CTRL-X` / `CTRL-V` key
  bindings to open in a new tab, a new split, or in a new vertical split
- Bang-versions of the commands (e.g. `Ag!`) will open fzf in fullscreen
- You can set `g:fzf_command_prefix` to give the same prefix to the commands
    - e.g. `let g:fzf_command_prefix = 'Fzf'` and you have `FzfFiles`, etc.

(1: `Helptags` will shadow the command of the same name
from [pathogen][pat]. But its functionality is still available via `call
pathogen#helptags()`. [↩](#a1))

[pat]: https://github.com/tpope/vim-pathogen
[f]:   https://github.com/tpope/vim-fugitive

Customization
-------------

### Global options

Every command in fzf.vim internally calls `fzf#wrap` function of the main
repository which supports a set of global option variables. So please read
through [README-VIM][README-VIM] to learn more about them.

#### Preview window

Some commands will show the preview window on the right. You can customize the
behavior with `g:fzf_preview_window`. Here are some examples:

```vim
" This is the default option:
"   - Preview window on the right with 50% width
"   - CTRL-/ will toggle preview window.
" - Note that this array is passed as arguments to fzf#vim#with_preview function.
" - To learn more about preview window options, see `--preview-window` section of `man fzf`.
let g:fzf_preview_window = ['right,50%', 'ctrl-/']

" Preview window is hidden by default. You can toggle it with ctrl-/.
" It will show on the right with 50% width, but if the width is smaller
" than 70 columns, it will show above the candidate list
let g:fzf_preview_window = ['hidden,right,50%,<70(up,40%)', 'ctrl-/']

" Empty value to disable preview window altogether
let g:fzf_preview_window = []

" fzf.vim needs bash to display the preview window.
" On Windows, fzf.vim will first see if bash is in $PATH, then if
" Git bash (C:\Program Files\Git\bin\bash.exe) is available.
" If you want it to use a different bash, set this variable.
" let g:fzf_preview_bash = 'C:\Git\bin\bash.exe'
```

### Command-local options

A few commands in fzf.vim can be customized with global option variables shown
below.

```vim
" [Buffers] Jump to the existing window if possible
let g:fzf_buffers_jump = 1

" [[B]Commits] Customize the options used by 'git log':
let g:fzf_commits_log_options = '--graph --color=always --format="%C(auto)%h%d %s %C(black)%C(bold)%cr"'

" [Tags] Command to generate tags file
let g:fzf_tags_command = 'ctags -R'

" [Commands] --expect expression for directly executing the command
let g:fzf_commands_expect = 'alt-enter,ctrl-x'
```

### Advanced customization

#### Vim functions

Each command in fzf.vim is backed by a Vim function. You can override
a command or define a variation of it by calling its corresponding function.

| Command   | Vim function                                                           |
| ---       | ---                                                                    |
| `Files`   | `fzf#vim#files(dir, [spec dict], [fullscreen bool])`                   |
| `GFiles`  | `fzf#vim#gitfiles(git_options, [spec dict], [fullscreen bool])`        |
| `GFiles?` | `fzf#vim#gitfiles('?', [spec dict], [fullscreen bool])`                |
| `Buffers` | `fzf#vim#buffers([spec dict], [fullscreen bool])`                      |
| `Colors`  | `fzf#vim#colors([spec dict], [fullscreen bool])`                       |
| `Rg`      | `fzf#vim#grep(command, [spec dict], [fullscreen bool])`                |
| `RG`      | `fzf#vim#grep2(command_prefix, query, [spec dict], [fullscreen bool])` |
| ...       | ...                                                                    |

(We can see that the last two optional arguments of each function are
identical. They are directly passed to `fzf#wrap` function. If you haven't
read [README-VIM][README-VIM] already, please read it before proceeding.)

#### Example: Customizing `Files` command

This is the default definition of `Files` command:

```vim
command! -bang -nargs=? -complete=dir Files call fzf#vim#files(<q-args>, <bang>0)
```

Let's say you want to a variation of it called `ProjectFiles` that only
searches inside `~/projects` directory. Then you can do it like this:

```vim
command! -bang ProjectFiles call fzf#vim#files('~/projects', <bang>0)
```

Or, if you want to override the command with different fzf options, just pass
a custom spec to the function.

```vim
command! -bang -nargs=? -complete=dir Files
    \ call fzf#vim#files(<q-args>, {'options': ['--layout=reverse', '--info=inline']}, <bang>0)
```

Want a preview window?

```vim
command! -bang -nargs=? -complete=dir Files
    \ call fzf#vim#files(<q-args>, {'options': ['--layout=reverse', '--info=inline', '--preview', 'cat {}']}, <bang>0)
```

It kind of works, but you probably want a nicer previewer program than `cat`.
fzf.vim ships [a versatile preview script](bin/preview.sh) you can readily
use. It internally executes [bat](https://github.com/sharkdp/bat) for syntax
highlighting, so make sure to install it.

```vim
command! -bang -nargs=? -complete=dir Files
    \ call fzf#vim#files(<q-args>, {'options': ['--layout=reverse', '--info=inline', '--preview', '~/.vim/plugged/fzf.vim/bin/preview.sh {}']}, <bang>0)
```

However, it's not ideal to hard-code the path to the script which can be
different in different circumstances. So in order to make it easier to set up
the previewer, fzf.vim provides `fzf#vim#with_preview` helper function.
Similarly to `fzf#wrap`, it takes a spec dictionary and returns a copy of it
with additional preview options.

```vim
command! -bang -nargs=? -complete=dir Files
    \ call fzf#vim#files(<q-args>, fzf#vim#with_preview({'options': ['--layout=reverse', '--info=inline']}), <bang>0)
```

You can just omit the spec argument if you only want the previewer.

```vim
command! -bang -nargs=? -complete=dir Files
    \ call fzf#vim#files(<q-args>, fzf#vim#with_preview(), <bang>0)
```

#### Example: `git grep` wrapper

The following example implements `GGrep` command that works similarly to
predefined `Ag` or `Rg` using `fzf#vim#grep`.

- We set the base directory to git root by setting `dir` attribute in spec
  dictionary.
- [The preview script](bin/preview.sh) supports `grep` format
  (`FILE_PATH:LINE_NO:...`), so we can just wrap the spec with
  `fzf#vim#with_preview` as before to enable previewer.

```vim
command! -bang -nargs=* GGrep
  \ call fzf#vim#grep(
  \   'git grep --line-number -- '.shellescape(<q-args>),
  \   fzf#vim#with_preview({'dir': systemlist('git rev-parse --show-toplevel')[0]}), <bang>0)
```

Mappings
--------

| Mapping                            | Description                               |
| ---                                | ---                                       |
| `<plug>(fzf-maps-n)`               | Normal mode mappings                      |
| `<plug>(fzf-maps-i)`               | Insert mode mappings                      |
| `<plug>(fzf-maps-x)`               | Visual mode mappings                      |
| `<plug>(fzf-maps-o)`               | Operator-pending mappings                 |
| `<plug>(fzf-complete-word)`        | `cat /usr/share/dict/words`               |
| `<plug>(fzf-complete-path)`        | Path completion using `find` (file + dir) |
| `<plug>(fzf-complete-file)`        | File completion using `find`              |
| `<plug>(fzf-complete-line)`        | Line completion (all open buffers)        |
| `<plug>(fzf-complete-buffer-line)` | Line completion (current buffer only)     |

```vim
" Mapping selecting mappings
nmap <leader><tab> <plug>(fzf-maps-n)
xmap <leader><tab> <plug>(fzf-maps-x)
omap <leader><tab> <plug>(fzf-maps-o)

" Insert mode completion
imap <c-x><c-k> <plug>(fzf-complete-word)
imap <c-x><c-f> <plug>(fzf-complete-path)
imap <c-x><c-l> <plug>(fzf-complete-line)
```

Completion functions
--------------------

| Function                                 | Description                           |
| ---                                      | ---                                   |
| `fzf#vim#complete#path(command, [spec])` | Path completion                       |
| `fzf#vim#complete#word([spec])`          | Word completion                       |
| `fzf#vim#complete#line([spec])`          | Line completion (all open buffers)    |
| `fzf#vim#complete#buffer_line([spec])`   | Line completion (current buffer only) |

```vim
" Path completion with custom source command
inoremap <expr> <c-x><c-f> fzf#vim#complete#path('fd')
inoremap <expr> <c-x><c-f> fzf#vim#complete#path('rg --files')

" Word completion with custom spec with popup layout option
inoremap <expr> <c-x><c-k> fzf#vim#complete#word({'window': { 'width': 0.2, 'height': 0.9, 'xoffset': 1 }})
```

Custom completion
-----------------

`fzf#vim#complete` is a helper function for creating custom fuzzy completion
using fzf. If the first parameter is a command string or a Vim list, it will
be used as the source.

```vim
" Replace the default dictionary completion with fzf-based fuzzy completion
inoremap <expr> <c-x><c-k> fzf#vim#complete('cat /usr/share/dict/words')
```

For advanced uses, you can pass an options dictionary to the function. The set
of options is pretty much identical to that for `fzf#run` only with the
following exceptions:

- `reducer` (funcref)
    - Reducer transforms the output lines of fzf into a single string value
- `prefix` (string or funcref; default: `\k*$`)
    - Regular expression pattern to extract the completion prefix
    - Or a function to extract completion prefix
- Both `source` and `options` can be given as funcrefs that take the
  completion prefix as the argument and return the final value
- `sink` or `sink*` are ignored

```vim
" Global line completion (not just open buffers. ripgrep required.)
inoremap <expr> <c-x><c-l> fzf#vim#complete(fzf#wrap({
  \ 'prefix': '^.*$',
  \ 'source': 'rg -n ^ --color always',
  \ 'options': '--ansi --delimiter : --nth 3..',
  \ 'reducer': { lines -> join(split(lines[0], ':\zs')[2:], '') }}))
```

### Reducer example

```vim
function! s:make_sentence(lines)
  return substitute(join(a:lines), '^.', '\=toupper(submatch(0))', '').'.'
endfunction

inoremap <expr> <c-x><c-s> fzf#vim#complete({
  \ 'source':  'cat /usr/share/dict/words',
  \ 'reducer': function('<sid>make_sentence'),
  \ 'options': '--multi --reverse --margin 15%,0',
  \ 'left':    20})
```

Status line of terminal buffer
------------------------------

When fzf starts in a terminal buffer (see [fzf/README-VIM.md][termbuf]), you
may want to customize the statusline of the containing buffer.

[termbuf]: https://github.com/junegunn/fzf/blob/master/README-VIM.md#fzf-inside-terminal-buffer

### Hide statusline

```vim
autocmd! FileType fzf set laststatus=0 noshowmode noruler
  \| autocmd BufLeave <buffer> set laststatus=2 showmode ruler
```

### Custom statusline

```vim
function! s:fzf_statusline()
  " Override statusline as you like
  highlight fzf1 ctermfg=161 ctermbg=251
  highlight fzf2 ctermfg=23 ctermbg=251
  highlight fzf3 ctermfg=237 ctermbg=251
  setlocal statusline=%#fzf1#\ >\ %#fzf2#fz%#fzf3#f
endfunction

autocmd! User FzfStatusLine call <SID>fzf_statusline()
```

License
-------

MIT

[fzf]:   https://github.com/junegunn/fzf
[run]:   https://github.com/junegunn/fzf/blob/master/README-VIM.md#fzfrun
[vimrc]: https://github.com/junegunn/dotfiles/blob/master/vimrc
[ag]:    https://github.com/ggreer/the_silver_searcher
[rg]:    https://github.com/BurntSushi/ripgrep
[us]:    https://github.com/SirVer/ultisnips

gha_language: Vim Script


text:
# Sagemaker Model training workflow with AWS Glue Databrew reciepe and AWS Step Function SDK.

# Introduction

As the Industry grows with more data along with large scale adoption of machine learning solutions, cleansing and visualizing data for model training has become key task in the ML workflow. As data scientist and engineers look for more insights from data they also want to reduce time to derive new insights and look for data profiling and transformation capabilities from visual preparation tool.

Recently, AWS announced the general availability of AWS Glue DataBrew, a new visual data preparation tool that helps you clean and normalize data without writing code. This reduces the time it takes to prepare data for analytics and ML by up to 80% compared to traditional approaches to data preparation.

Regarding orchestration or workflow management, AWS provides AWS Step Functions, a serverless function orchestrator that makes it easy to build a workflow by integrating different AWS services like AWS Lambda, Amazon Simple Notification Service (Amazon SNS), AWS Glue, and more. With its built-in operational controls, Step Functions manages sequencing, error handling, retry logic, and states, removing a significant operational burden from your team.

As part of this repository, we walk through a solution where we use DataBrew for visual data preparation and use Jupyterlab code to call databrew artifacts and create AWS step functions to orchestrate Sagemaker training jobs.

## Step function workflow
This is an overview of the workflow described above:

![step_function_workflow](img/step_function_workflow.png)

## Data
The data is related with direct marketing campaigns of a banking institution. The marketing campaigns were based on phone calls. Often, more than one contact to the same client was required, in order to access if the product (bank term deposit) would be ('yes') or not ('no') subscribed.

The dataset we use is publicly available and It is attributed by S. Moro, P. Cortez and P. Rita to the University of California Irvine Repository of Machine Learning Datasets.

https://archive.ics.uci.edu/ml/datasets/Bank+Marketing

## Solution Steps

First we will create databrew project and receipes to transform dataset then create machine learning model training workflow using Step function.

You can find more information about Databrew and step function in below links

* [AWS Glue Databrew](https://aws.amazon.com/glue/features/databrew/)
* [AWS Glue Databrew Deverloper Guide](https://docs.aws.amazon.com/databrew/latest/dg/what-is.html)
* [AWS Step Functions](https://aws.amazon.com/step-functions/)
* [AWS Step Functions Developer Guide](https://docs.aws.amazon.com/step-functions/latest/dg/welcome.html)
* [AWS Step Functions Data Science SDK](https://aws-step-functions-data-science-sdk.readthedocs.io)

This solution is implemented in Jupyter notebook [sagemaker_databrew_ml_workflow_blog.ipynb](notebooks/sagemaker_databrew_ml_workflow_blog.ipynb)

All required roles/permission can be deployed using cloudformation [template](cloudformation/step-function-execution-role.yaml)

we will use the SDK to create steps that Orchestrate AWS Glue Databrew receipe jobs, encorporate this data into the training of a machine learning model, deploy the model to a SageMaker endpoint, link these steps together to create a workflow, and then execute the workflow in AWS Step Functions.

## License Summary

This sample code is made available under the MIT-0 license. See the [LICENSE](LICENSE) file.


text:
# Jenkins Helm Chart

Jenkins master and slave cluster utilizing the Jenkins Kubernetes plugin

* https://wiki.jenkins-ci.org/display/JENKINS/Kubernetes+Plugin

Inspired by the awesome work of Carlos Sanchez<EMAIL_ADDRESS>
This chart is fully based on the chart found at the [Kubernetes Charts](https://github.com/kubernetes/charts/tree/master/stable/jenkins).

## Chart Details

This chart will do the following:

* 1 x Jenkins Master with port 80 exposed on an external LoadBalancer
* All using Kubernetes Deployments

Right now, we are using Jenkins 2.73.1.

## Get this chart

Our central repository is located at: `https://devopsku.be/charts`, please configure this in your helm installation (via `helm repo add`). Then you can download and install this chart using the usual helm procedure (see [Using Helm](https://github.com/kubernetes/helm/blob/master/docs/using_helm.md)).

If you would like to contribute and/or like to make changes on this chart, please clone this repo via:

`git clone https://github.com/devopskube/devopskube.git`

## Installing the Chart

The installation-instructions can be found on the above mentioned [Using Helm](https://github.com/kubernetes/helm/blob/master/docs/using_helm.md) page.

## Configuration

The following tables lists the configurable parameters of the Jenkins chart and their default values.

### Jenkins Master

|       Parameter       |           Description            |                         Default                          |
|-----------------------|----------------------------------|----------------------------------------------------------|
|`master.name`| Jenkins master name | `jenkins-master` |
|`master.image`| Master image name  | `gcr.io/kubernetes-charts-ci/jenkins-master-k8s` |
|`master.imageTag`| Master image tag | `v0.1.0` |
|`master.imagePullPolicy`| Master image pull policy | `Always` |
|`master.vomponent`| k8s selector key  | `jenkins-master` |
|`master.cpu`| Master requested cpu | `200m` |
|`master.memory`| Master requested memory | `256Mi` |
|`master.servicePort`| k8s service port | `80` |
|`master.containerPort`| Master listening port | `8080` |
|`master.slaveListenerPort`|  Listening port for agents | `50000` |
|`master.adminUser`| The initial admin user | `admin` |
|`master.adminPassword`| The initial admin user password | `admin1234` |
|`master.javaOpts`| Some java options | `-Xms512m -Xmx512m` |
|`master.hostName`| The hostName of the jenkins instance | `jenkins.example.com` |
|`master.systemMessaage`| The Systemmessage | `DevOpsKube Build Server` |
|`persistence.path`| The path where data is stored | `/data/jenkins` |

### Jenkins Agent

|       Parameter       |           Description            |                         Default                          |
|-----------------------|----------------------------------|----------------------------------------------------------|
|`agent.image`| Agent image name | `jenkinsci/jnlp-slave` |
|`agent.imageTag`| Agent image tag | `2.52` |
|`agent.cpu`| Agent requested cpu | `200m` |
|`agent.memory`| Agent requested memory | `256Mi` |

### Other Settings

|       Parameter       |           Description            |                         Default                          |
|-----------------------|----------------------------------|----------------------------------------------------------|
|`smtp.host`| Smtp Host | `mail.example.com` |
|`smtp.port`| Smtp Host Port | `999` |
|`smtp.replyTo`| The replyTo Address |<EMAIL_ADDRESS>|
|`smtp.auth.userName`| The username to authenticate on the smtp server |<EMAIL_ADDRESS>|
|`docker.account`| Docker Registry Login | `yourUserName` |
|`docker.password`| Docker Registry Password | `yourPassword` |

Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`.

Alternatively, a YAML file that specifies the values for the parameters can be provided while installing the chart. For example,

```bash
$ helm install --name my-jenkins -f values.yaml jenkins-x.x.x.tgz
```

> **Tip**: You can use the default [values.yaml](https://github.com/devopskube/devopskube/blob/master/charts/jenkins/values.yaml)
> **Tip**: Initial Username/Password is (as listed above) admin/admin1234.

## Persistence

To be able to keep stateful data in the jenkins kubernetes container, the following path is used:

```
/data/jenkins
```

Right now, we do use HostPathes, which do not work in a real cluster environment (like AWS or GCE). Please adopt this one to your own needs.

## Login Url

http://jenkins.devopskube.org/loginEntry?from=%2F

# Todo

* Enable Docker-in-Docker or Docker-on-Docker support on the Jenkins agents
* pre-start script
* Add SSO
* Use persistence volume claims
* install needs volume on host (with correct rights `sudo chown 1000:1000 jenkins`)
* Document clearer that right now the usage of the jenkins-jnlp-slave docker image is moved to the Jenkinsfile (or even better: use it in the central config, and delete it from the Jenkinsfiles)
* Provide additional slaves, like needed (building charts, building nodejs stuff)


text:
# 137-datastructures
A module for [TrajSuite](https://github.com/lukehb/TrajSuite).

Data structures used for building java applications, particularly data-mining projects.

Latest binary:
[ ![Download](https://api.bintray.com/packages/lukehb/137-datastructures/137-datastructures/images/download.svg) ](https://bintray.com/lukehb/137-datastructures/137-datastructures/_latestVersion)

To include in your gradle project use:

```groovy
repositories {
    maven{url 'https://dl.bintray.com/lukehb/137-datastructures'} //hosted on bintray
}

dependencies {
    compile 'onethreeseven:datastructures:0.0.3'
}
```


text:
# SRE Workbench

## Installation

All installs require an instance of mongodb available.

### Prerequisites

- MongoDB 4.0 or newer
- Docker 18.09.1 or newer

### Bare Metal Install

### Docker Install

Run `docker build . -t sae-workbench` to build the docker container and the following commands to run it

``` sh
hostip=$(ifconfig en0 | awk '$1 == "inet" {print $2}')
docker run -e LOG_LEVEL=info -e SESSION_SECRET="s3cr3t" -e SESSION_COOKIE_SECURE=true \
   -e OIDC_ISSUER="https://oidc/auth/realms/myrealm" \
   -e OIDC_CLIENT_ID=workbench -e OIDC_CLIENT_SECRET=s3c3rt \
   -e OIDC_AUTH_URL="https://oidc/auth/realms/myrealm/protocol/openid-connect/auth" \
   -e OIDC_TOKEN_URL="https://oidc/auth/realms/myrealm/protocol/openid-connect/token" \
   -e OIDC_USERINFO_URL="https://oidc/auth/realms/myrealm/protocol/openid-connect/userinfo" \
   -e OIDC_CALLBACK_URL="http://localhost/" \
   -e OIDC_SCOPE="openid offline_access" \
   --add-host=docker:$hostip -p LOCALPORT:8000 sae-workbench
```

This web application uses MERN boiler plate, for additional documentation see [mern.io](http://mern.io/).
## Quickstart

```
  npm install
  npm start
```

## Available Commands

1. `npm run start` - starts the development server with hot reloading enabled

2. `npm run bs` - bundles the code and starts the production server

3. `npm run test` - start the test runner

4. `npm run watch:test` - start the test runner with watch mode

5. `npm run cover` - generates test coverage report

6. `npm run lint` - runs linter to check for lint errors

### Docker
There are docker configurations for both development and production.

To run docker for development,
```
docker-compose -f docker-compose-development.yml build
docker-compose -f docker-compose-development.yml up
```

To run docker for production,
```
docker-compose build
docker-compose up
```

repository: bcgov/sae-workbench

repo_name: bcgov/sae-workbench


text:
---
title: Lutron Homeworks QS - Radio Ra2 - Grafik QS
layout: pagetoc
notice: DoNotEdit, created automatically from the driver metadata, must be updated on the driver itself
---
# Lutron Homeworks QS and Radio Ra2

This driver supports communication with Lutron HomeWorks QS, Lutron
Radio RA2 and Lutron Grafik QS systems.

## Connecting to a Grafik QS system

Connection to a Grafik QS system is done via a QSE-CI-NWK-E interface,
which allows Ethernet and RS232 connectivity.

For RS232 communications, set the same bit rate on the QSE-CI-NWK-E
interface and on BeoLiving Intelligence connection settings.

Connection settings for Ethernet are the IP address of the interface
and the password. The default password is `nwk`.

## Connection to a Radio RA2 system

Communication with Radio RA2 is done via the Radio RA2 Main Repeater,
which allows interaction with the system via 100 programmable virtual
buttons (*phantom buttons*). This device provides both RS232 and
Ethernet interfaces.

Connection to the RS232 interface can be done directly using a 3-wire
RS232 cable and it is fixed at 9600 bps, no parity, 1 stop bit, 8 data
bits, no flow control.

Connection settings for Ethernet consist of: IP address of the Main
Repeater (default: <IP_ADDRESS>), login (default: lutron), password
(default: integration) and telnet IP port (default: 23).

## Connection to a Homeworks QS system

Communication with the Homeworks QS system is done via the Ethernet
interface on the Homeworks QS Processor.

Connection settings consist of: IP address of the processor (default:
<IP_ADDRESS>), login (default: lutron), password (default: integration)
and telnet IP port (default: 23).

## Resources

The supported resource types are:

 + **Button with LED**: buttons on keypads or control units having a LED
   for status.
 + **Button**: a keypad or control unit button with no LED.
 + **LED**: a single LED used for status.
 + **Dimmer**: a light dimmer.
 + **Shade**: a single shade.
 + **Shade group**: a group of shades.
 + **Thermostat**: a thermostat like Lutron HVAC controller.
 + **Lutron QS Scene Button**: a button mapped to a single scene which
   will be selected on press.

## Resource address format

Most resource addresses use *Integration ID* which by default is a
number, but can also be a user defined string. Some resources require
a sub-address called *Component Number*.

"*Lutron QS Scene Button*" resources requires a scene number.

Possible scene numbers range from 0 (OFF) to 32, but depend on the
scenes actually programmed in the controller.

"*Button with LED*" resources also require a second component number
to identify the LED. In many cases, the LED component number is offset
80 above the button component number (and this is the default LED
component added during capture).

However, there are many cases in which the LED component number must
be explicitly edited.

You may find out the LED component number by checking the LED events
in the capture list. Or, you can check the complete list of component
numbers for all Lutron keypads and control units in Lutron's
Integration Protocol documentation.

All address formats are suggested as tooltips on the address field.

| Resource type    | Address format                                          | Examples                    |
|==================|=========================================================|=============================|
| Button with LED  | Integration ID, Component Number, LED Component Number  | `1,1,81` or `myIID,28,108`  |
| Button           | Integration ID, Component Number                        | `1,1` or `myIID,28`         |
| LED              | Integration ID, Component Number                        | `1,1` or `myIID,28`         |
| Dimmer           | Integration ID or Int. ID + Component Number            | `1` or `1,1` or `myIID,28`  |
| Shade            | Integration ID                                          | `1` or `myIID`              |
| Shade group      | Integration ID                                          | `1` or `myIID`              |
| Thermostat       | Integration ID                                          | `1` or `myIID`              |
| QS Scene Button  | Integration ID, Component Number, Scene                 | `1,1,1` or `myIID,43,1`     |

## Availability of events and commands

Lutron supports a lot of different hardware models and combinations.

Not all hardware setups support the whole set of events and commands.

Check the Lutron documentation (*Lutron Integration Protocol*), or use
the monitoring facilities in BeoLiving Intelligence to verify that the hardware actually
supports a command or event type.

A typical example is the `_MULTI TAP` event, which is available on a
limited combination of Lutron hardware.

## Events

 + Button with LED, Button
   - **PRESS**
   - **RELEASE**
   - **HOLD**
   - **\_MULTI TAP**: Pressing on the button repeatedly
   - **\_HOLD RELEASE**: Releasing a button after a long press (HOLD)

## Commands

 + Button with LED, Button
   - **PRESS**
   - **RELEASE**
   - **HOLD**
   - **\_MULTI TAP**: Pressing on the button repeatedly
   - **\_HOLD RELEASE**: Releasing a button after a long press (HOLD)
 + Dimmer
   - **SET**: Set the dimmer level, in percentage.
 + Shade
   - **RAISE**
   - **LOWER**
   - **STOP**
   - **SET**: Set the shade level, in percentage.
 + Shade group
   - **RAISE**
   - **LOWER**
   - **STOP**
   - **SET**: Set the shade level, in percentage.
   - **PRESET**: Select one of the defined presets for the shade group
 + Thermostat
   - **SET HEAT SP**: Set the heat setpoint on the thermostat
   - **SET COOL SP**: Set the cool setpoint on the thermostat
   - **SET MODE**: Select the operation mode to OFF, Heat, Cool, Auto and Em.Heat (emergency heat)
   - **SET FAN AUTO**: Turn fan automatic mode ON or OFF
   - **SET SCHEDULE**: Turn the schedule ON or OFF
   - **SET ECO MODE**: Turn echo mode ON or OFF
   - **_SET SP**: Set cool and heat setpoints on the thermostat
 + Lutron QS Scene Button
   - **PRESS**: Select scene

## Resource State

 + Button with LED
   - **STATE**: The state of the LED (0 means OFF and 1 ON)
 + LED
   - **\_STATE**: The state of the LED (0 means OFF and 1 ON)
 + Dimmer
   - **LEVEL**: Level of the dimmer
 + Shade
   - **LEVEL**: Level of the shade
 + Shade group
   - **LEVEL**: Level of the shade group
 + Thermostat
   - **TEMPERATURE**: The current temperature
   - **HEAT SP**: The current heat setpoint
   - **COOL SP**: The current cool setpoint
   - **MODE**: The active mode
   - **FAN AUTO**: Whether the fan automatic mode is ON or OFF
   - **SCHEDULE**: Whether the schedule is ON or OFF
   - **ECO MODE**: Whether the eco mode is ON or OFF
   - **\_SYSTEM MODE**: The current system mode
 + Lutron QS Scene Button
   - **STATE**: Whether this scene currently selected or not

## Known issues: Capture stops working for Grafik controllers

Grafik controllers may stop reporting events in a HomeWorks QS /
RadioRa 2 installation. This condition will prevent BeoLiving Intelligence
from detecting events and from showing resource capture information.

We found the following procedure will restore a non-communicating
Grafik controller:

 1. Verify that the Grafik unit is listed on the integration report
    (Lutron setup software).
 2. If it does not appear in the report, remove it and add it again to
    the project and re-check the report. Then upload the project to
    the HomeWorks / Ra2 controller.
 3. If the problem persists, you may try to **reset the Grafik
    controller to factory defaults**: Press and hold scene buttons 1,
    3 and 5, and main control arrow down (next to the display)
    simultaneously, until a message is displayed asking for
    confirmation. Press OK.

*Please, report any issue with this driver to: support+drivers@khimo.com*

gha_language: HTML


text:
# OpenShift Examples - Hello Kitura
Example simple Kitura based app for running on Open Shift

Works great with the [Swift S2I builder image](https://github.com/dudash/s2i-swift)

repository: dudash/openshiftexamples-hellokitura

repo_name: dudash/openshiftexamples-hellokitura


text:
# Description

This workflow creates solution-based tickets in ServiceNow for each of the top 25 remediations in InsightVM.  If there is already a ticket open for a given remediation, the workflow updates the existing ticket with a current list of impacted assets.

# Key Features

* Creates incidents in ServiceNow for the top 25 solutions from InsightVM
* Updates incident for a solution with current impacted assets if incident already exists

# Requirements

* InsightVM Console URL and account credentials
* InsightConnect License
* ServiceNow URL and account credentials

# Documentation

## Setup

Once the workflow has been downloaded, login to InsightConnect and “Import” it into the workflow builder. Once imported, you will initially be prompted to configure the connections for each of the plugins.

## Technical Details

Plugins utilized by workflow:

|Plugin|Version|Count|
|----|----|--------|
|Advanced Regex|1.0.1|1|
|Rapid7 InsightVM|4.0.0|1|
|Base64|1.1.3|3|
|Timers|2.0.4|1|
|ServiceNow|4.0.0|3|
|Storage|1.0.1|3|

## Troubleshooting

_There is no troubleshooting information at this time_

# Version History

* 1.0.3 - Updated ServiceNow plugin to version 4.0.0
* 1.0.2 - Updated documentation
* 1.0.1 - Change 'Clean Fix' step to handle solutions with a missing fix and updated InsightVM plugin to version 4.0.0
* 1.0.0 - Initial workflow

# Links

## References

* [ServiceNow](https://www.servicenow.com)
* [InsightVM] (https://www.rapid7.com/products/insightvm/)

repository: PhilippBehmer/insightconnect-workflows

repo_name: PhilippBehmer/insightconnect-workflows


text:
# Application Architecture Guide

Here we provide a brief guide on the recommended architecture of a
Tenderely blockchain application.

The following diagram provides a superb example:

![](../imgs/cosmos-tendermint-stack-4k.jpg)

The end-user application here is the Cosmos Voyager, at the bottom left.
Voyager communicates with a REST API exposed by a local Light-Client
Daemon. The Light-Client Daemon is an application specific program that
communicates with Tenderely nodes and verifies Tenderely light-client
proofs through the Tenderely Core RPC. The Tenderely Core process
communicates with a local ABCI application, where the user query or
transaction is actually processed.

The ABCI application must be a deterministic result of the Tenderely
consensus - any external influence on the application state that didn't
come through Tenderely could cause a consensus failure. Thus _nothing_
should communicate with the application except Tenderely via ABCI.

If the application is written in Go, it can be compiled into the
Tenderely binary. Otherwise, it should use a unix socket to communicate
with Tenderely. If it's necessary to use TCP, extra care must be taken
to encrypt and authenticate the connection.

All reads from the app happen through the Tenderely `/abci_query`
endpoint. All writes to the app happen through the Tenderely
`/broadcast_tx_*` endpoints.

The Light-Client Daemon is what provides light clients (end users) with
nearly all the security of a full node. It formats and broadcasts
transactions, and verifies proofs of queries and transaction results.
Note that it need not be a daemon - the Light-Client logic could instead
be implemented in the same process as the end-user application.

Note for those ABCI applications with weaker security requirements, the
functionality of the Light-Client Daemon can be moved into the ABCI
application process itself. That said, exposing the application process
to anything besides Tenderely over ABCI requires extreme caution, as
all transactions, and possibly all queries, should still pass through
Tenderely.

See the following for more extensive documentation:

- [Interchain Standard for the Light-Client REST API](https://github.com/cosmos/cosmos-sdk/pull/1028)
- [Tenderely RPC Docs](https://tendermint.com/rpc/)
- [Tenderely in Production](../tendermint-core/running-in-production.md)
- [ABCI spec](./abci-spec.md)

repository: Technorely/tendermint

repo_name: Technorely/tendermint


text:
# NTerm is not a Term

NTerm (NTerm is not a Term) is a different take on what a terminal should be. It offers the following capabilities.

* Every terminal session is automatically tracked and kept separate.
* Every background job (jobs you started with `&`) is tracked separately from the terminal.
* Every log dump is automatically saved and can easily be opened for examination.
* You can easily manage environment variable for all the sessions, as well as individual sessions.

NTerm is designed to be a "command line call manager" first and foremost. A full terminal emulation will come after the first goal is achieved.

## Install

    npm install -g nterm

## Build

* `gulp css` - builds css.
* `gulp js` - builds js
* `gulp build` - builds everything
* `gulp start` - builds and start nterm

repository: yinso/nterm

repo_name: yinso/nterm


text:
---
description: Osxfs caching
keywords: mac, osxfs, volumes
title: Performance tuning for volume mounts (shared filesystems)
---

[Docker 17.04 CE
Edge](/edge/index.md#docker-ce-edge-new-features) adds support
for two new flags to the [docker run `-v`,
`--volume`](/engine/reference/run/#volume-shared-filesystems)
option, `cached` and `delegated`, that can significantly improve the performance
of mounted volume access on Docker for Mac. These options begin to solve some of
the challenges discussed in [Performance issues, solutions, and
roadmap](osxfs.md#performance-issues-solutions-and-roadmap).

> **Tip:** Release notes for Docker CE Edge 17.04 are
[here](https://github.com/moby/moby/releases/tag/v17.04.0-ce), and the
associated pull request for the additional `docker run -v` flags is
[here](https://github.com/moby/moby/pull/31047).

The following topics describe the challenges of bind-mounted volumes on `osxfs`,
and the caching options provided to optimize performance.

This blog post on [Docker on Mac
Performance](https://stories.amazee.io/docker-on-mac-performance-docker-machine-vs-docker-for-mac-4c64c0afdf99)
gives a nice, quick summary.

For information on how to configure these options in a Compose file, see
[Caching options for volume
mounts](/compose/compose-file.md#caching-options-for-volume-mounts-docker-for-mac)
the Docker Compose topics.

## Performance implications of host-container file system consistency

With Docker distributions now available for an increasing number of
platforms, including macOS and Windows, generalizing mount semantics
during container run is a necessity to enable workload optimizations.

The current implementations of mounts on Linux provide a consistent
view of a host directory tree inside a container: reads and writes
performed either on the host or in the container are immediately
reflected in the other environment, and file system events (`inotify`,
`FSEvents`) are consistently propagated in both directions.

On Linux, these guarantees carry no overhead, since the underlying VFS is
shared directly between host and container. However, on macOS (and
other non-Linux platforms) there are significant overheads to
guaranteeing perfect consistency, since messages describing file system
actions must be passed synchronously between container and host. The
current implementation is sufficiently efficient for most tasks, but
with certain types of workloads the overhead of maintaining perfect
consistency can result in significantly worse performance than a
native (non-Docker) environment. For example,

 * running `go list ./...` in the bind-mounted `docker/docker` source tree
   takes around 26 seconds

 * writing 100MB in 1k blocks into a bind-mounted directory takes
   around 23 seconds

 * running `ember build` on a freshly created (empty) application
   involves around 70000 sequential syscalls, each of which translates
   into a request and response passed between container and host.

Optimizations to reduce latency throughout the stack have brought
significant improvements to these workloads, and a few further
optimization opportunities remain. However, even when latency is
minimized, the constraints of maintaining consistency mean that these
workloads remain unacceptably slow for some use cases.

## Tuning with consistent, cached, and delegated configurations

**_Fortunately, in many cases where the performance degradation is most
severe, perfect consistency between container and host is unnecessary._**
In particular, in many cases there is no need for writes performed in a
container to be immediately reflected on the host. For example, while
interactive development requires that writes to a bind-mounted directory
on the host immediately generate file system events within a container,
there is no need for writes to build artifacts within the container to
be immediately reflected on the host file system. Distinguishing between
these two cases makes it possible to significantly improve performance.

There are three broad scenarios to consider, based on which you can dial in the
level of consistency you need. In each case, the container has an
internally-consistent view of bind-mounted directories, but in two cases
temporary discrepancies are allowed between container and host.

 * `consistent`: perfect consistency
   (host and container have an identical view of the mount at all times)

 * `cached`: the host's view is authoritative
   (permit delays before updates on the host appear in the container)

 * `delegated`: the container's view is authoritative
   (permit delays before updates on the container appear in the host)

## Examples

Each of these configurations (`consistent`, `cached`, `delegated`) can be
specified as a suffix to the
[`-v`](/engine/reference/run/#volume-shared-filesystems)
option of [`docker run`](/engine/reference/run.md). For
example, to bind-mount `/Users/yallop/project` in a container under the path
`/project`, you might run the following command:

```bash
docker run -v /Users/yallop/project:/project:cached alpine command
```

The caching configuration can be varied independently for each bind mount,
so you can mount each directory in a different mode:

```bash
docker run -v /Users/yallop/project:/project:cached \
 -v /host/another-path:/mount/another-point:consistent
 alpine command
```

## Semantics

The semantics of each configuration is described as a set of guarantees
relating to the observable effects of file system operations. In this
specification, "host" refers to the file system of the user's Docker
client.

### delegated

The `delegated` configuration provides the weakest set of guarantees.
For directories mounted with `delegated` the container's view of the
file system is authoritative, and writes performed by containers may not
be immediately reflected on the host file system. In situations such as NFS
asynchronous mode, if a running container with a `delegated` bind mount
crashes, then writes may be lost.

However, by relinquishing consistency, `delegated` mounts offer
significantly better performance than the other configurations. Where
the data written is ephemeral or readily reproducible, such as from scratch
space or build artifacts, `delegated` may be the right choice.

A `delegated` mount offers the following guarantees, which are presented
as constraints on the container run-time:

1.  If the implementation offers file system events, the container state
as it relates to a specific event **_must_** reflect the host file system
state at the time the event was generated if no container modifications
pertain to related file system state.

2.  If flush or sync operations are performed, relevant data **_must_** be
written back to the host file system.Between flush or sync
operations containers **_may_** cache data written, metadata modifications,
and directory structure changes.

3.  All containers hosted by the same runtime **_must_** share a consistent
cache of the mount.

4.  When any container sharing a `delegated` mount terminates, changes
to the mount **_must_** be written back to the host file system. If this
writeback fails, the container's execution **_must_** fail via exit code
and/or Docker event channels.

5.  If a `delegated` mount is shared with a `cached` or a `consistent`
mount, those portions that overlap **_must_** obey `cached` or `consistent`
mount semantics, respectively.

    Besides these constraints, the `delegated` configuration offers the
container runtime a degree of flexibility:

6. Containers **_may_** retain file data and metadata (including directory
structure, existence of nodes, etc) indefinitely and this cache **_may_**
desynchronize from the file system state of the host. Implementors should expire
caches when host file system changes occur, but this may be difficult to do on
a guaranteed timeframe due to platform limitations.

7. If changes to the mount source directory are present on the host
file system, those changes **_may_** be lost when the `delegated` mount
synchronizes with the host source directory.

8. Behaviors 6-7 **do not** apply to the file types of socket, pipe, or device.

### cached

The `cached` configuration provides all the guarantees of the `delegated`
configuration, and some additional guarantees around the visibility of writes
performed by containers. As such, `cached` typically improves the performance
of read-heavy workloads, at the cost of some temporary inconsistency between the
host and the container.

For directories mounted with `cached`, the host's view of
the file system is authoritative; writes performed by containers are immediately
visible to the host, but there may be a delay before writes performed on the
host are visible within containers.

>**Tip:** To learn more about `cached`, see the article on
[User-guided caching in Docker for Mac](https://blog.docker.com/2017/05/user-guided-caching-in-docker-for-mac/).

1. Implementations **_must_** obey `delegated` Semantics 1-5.

2. If the implementation offers file system events, the container state
as it relates to a specific event **_must_** reflect the host file system
state at the time the event was generated.

3. Container mounts **_must_** perform metadata modifications, directory
structure changes, and data writes consistently with the host file
system, and **_must not_** cache data written, metadata modifications, or
directory structure changes.

4.  If a `cached` mount is shared with a `consistent` mount, those portions
that overlap **_must_** obey `consistent` mount semantics.

    Some of the flexibility of the `delegated` configuration is retained,
namely:

5. Implementations **_may_** permit `delegated` Semantics 6.

### consistent

The `consistent` configuration places the most severe restrictions on
the container run-time. For directories mounted with `consistent` the
container and host views are always synchronized: writes performed
within the container are immediately visible on the host, and writes
performed on the host are immediately visible within the container.

The `consistent` configuration most closely reflects the behavior of
bind mounts on Linux. However, the overheads of providing strong
consistency guarantees make it unsuitable for a few use cases, where
performance is a priority and maintaining perfect consistency has low
priority.

1. Implementations **_must_** obey `cached` Semantics 1-4.

2. Container mounts **_must_** reflect metadata modifications, directory
structure changes, and data writes on the host file system immediately.

### default

The `default` configuration is identical to the `consistent`
configuration except for its name. Crucially, this means that `cached`
Semantics 4 and `delegated` Semantics 5 that require strengthening
overlapping directories do not apply to `default` mounts. This is the
default configuration if no `state` flags are supplied.


text:
# secret-sync-controller
Kubernetes controller for syncing data fields from one secret to another.

To sync fields, add a `secret-sync.praekelt.org/sync-to` annotation to the
source secret with a comma-separated list of destination secrets as the value.
Destinations in other namespaces may be specified as `<namespace>/<secret>`.

Any fields that exist in the source secret will be copied to the
destination(s), overwriting whatever values may already be present. Any fields
that exist in a destination but not the source are left unmodified. The
controller sets a `secret-sync.praekelt.org/watch: true` annotation on all
destination secrets in order to track them and reconcile when either source or
destination changes.

Example:
```
apiVersion: v1
kind: Secret
metadata:
  name: source
  namespace: sourcens
  annotations:
    secret-sync.praekelt.org/sync-to: dest,destns/otherdest
data:
  foo: aGVsbG8=
```

NOTE: Destination secrets must already exist, the controller won't create them.

gha_language: Python


text:
### NGSDAddVariantsSomatic tool help
	NGSDAddVariantsSomatic (2019_09-51-g84b6c695)

	Imports variants of a tumor-normal processed sample into the NGSD.

	Mandatory parameters:
	  -t_ps <string> Tumor processed sample name
	  -n_ps <string> Normal processed sample name

	Optional parameters:
	  -var <file>    Small variant list (i.e. SNVs and small INDELs) in GSvar format (as produced by megSAP).
	                 Default value: ''
	  -var_force     Force import of detected small variants, even if already imported.
	                 Default value: 'false'
	  -cnv <file>    CNV list in TSV format (as produced by megSAP).
	                 Default value: ''
	  -cnv_force     Force import of CNVs, even if already imported.
	                 Default value: 'false'
	  -out <file>    Output file. If unset, writes to STDOUT.
	                 Default value: ''
	  -test          Uses the test database instead of on the production database.
	                 Default value: 'false'
	  -debug         Enable verbose debug output.
	                 Default value: 'false'
	  -no_time       Disable timing output.
	                 Default value: 'false'

	Special parameters:
	  --help         Shows this help and exits.
	  --version      Prints version and exits.
	  --changelog    Prints changeloge and exits.
	  --tdx          Writes a Tool Definition Xml file. The file name is the application name with the suffix '.tdx'.

### NGSDAddVariantsSomatic changelog
	NGSDAddVariantsSomatic 2019_09-51-g84b6c695

[back to ngs-bits](https://github.com/imgag/ngs-bits)

repository: imgag/ngs-bits

repo_name: imgag/ngs-bits


text:
# New York Airbnb Price Predictor

  - authors: Ofer Mansour, Jacky Ho, Anand Vemparala

## About

In this project, our team attempted to predict Airbnb prices in New
York, using a [dataset](http://insideairbnb.com/get-the-data.html)(“Get
the Data - Inside Airbnb. Adding Data to the Debate.” n.d.) of all
listings in 2019. The dataset includes 48,895 listings and includes
several features, such as the price of the listing, neighbourhood, room
type and number of reviews. To find the best performing prediction
model, we tested several tree-based models: Random Forest, XGBoost,
LightGBM and an average ensembling of the three models.

## Report

The final report can be found
[here](https://github.com/UBC-MDS/DSCI_522_Group405/blob/master/doc/final_report.md).

## Usage

#### 1\. Using Docker

To replicate the analysis, install
[Docker](https://www.docker.com/get-started), clone this repository and
run the following command at the command line/terminal from the root
directory of this
    project:

    docker run --rm -v /$(pwd):/DSCI_522_Group405 vanandsh/dsci-522-group-405:latest make -C /DSCI_522_Group405 all

To remove intermediate and results files, run the following command at
the command line/terminal from the root directory of this
    project:

    docker run --rm -v /$(pwd):/DSCI_522_Group405 vanandsh/dsci-522-group-405:latest make -C /DSCI_522_Group405 clean

*Note: It is recommended to increase CPUs to 4 and Memory to 8 GiB in
Docker preferences. Running with Docker should take around 30-45
minutes*

#### 2\. Without Using Docker

To replicate this project, clone this GitHub repository, install the
dependencies and run the command below at the command line or terminal
from the root directory of this project:

    make all

To clean this repository to have no result or intermediate files, run
the command below at the command line or terminal from the root
directory of this
project:

    make clean

## Makefile2Graph

![](https://github.com/UBC-MDS/DSCI_522_Group405/blob/master/Makefile.png)

## Dependencies

  - Python 3.7.3 and Python Packages:
      - docopt==0.6.2
      - requests==2.22.0
      - pandas==0.24.2
      - numpy==1.16.4
      - sklearn==0.21.2
      - lightgbm==2.3.1
      - xgboost==0.90
      - altair==3.2.0
      - os==3.7.3
      - schema==0.7.1
      - selenium==3.141.0
  - R version 3.6.2 and R packages:
      - docopt==0.6.1
      - tidyverse==1.2.1
      - reshape2==1.4.3
      - gridExtra==2.3
      - knitr==1.27.2
      - png==0.1-7
      - kableExtra==1.1.0
      - rmarkdown==2.1.1
  - GNU Make 3.81
  - ChromeDriver 79.0.3945.36

# References

“Get the Data - Inside Airbnb. Adding Data to the Debate.” n.d.
<http://insideairbnb.com/get-the-data.html>.


text:
#Sonar

Simple script deployed in each country to test performance accessing major sites simulating a real user.
Data is reported to [statshub](https://github.com/getlantern/statshub) and shown at [lantern-dashboard](http://lantern-dashboard.s3-website-us-east-1.amazonaws.com/sonar.html).

# Deploy

[PhantomJS](http://phantomjs.org/) is required to test the sites and report to statshub.

### Install dependencies

`sudo apt-get install -f libfontconfig`

### Linux 64 bit

```
wget https://bitbucket.org/ariya/phantomjs/downloads/phantomjs-1.9.8-linux-x86_64.tar.bz2
tar jxvf phantomjs-1.9.8-linux-x86_64.tar.bz2
sudo ln -s `pwd`/phantomjs-1.9.8-linux-x86_64/bin/phantomjs /usr/bin/phantomjs
```

### Linux 32 bit

```
wget https://bitbucket.org/ariya/phantomjs/downloads/phantomjs-1.9.8-linux-i686.tar.bz2
tar jxvf phantomjs-1.9.8-linux-i686.tar.bz2
sudo ln -s `pwd`/phantomjs-1.9.8-linux-i686/bin/phantomjs /usr/bin/phantomjs
```

To test performance of Lantern network, headless version of Lantern is required.

See [flash-build repo](https://github.com/getlantern/flashlight-build#building-headless-version) for details.

# Run

PhantomJS is not considered pretty stable. It may crashes or takes unrealistic long time to load a page. So instead of run one phantomjs instance forever, we can run it periodly. Below is an example to run it every 5 minutes.

```
[fffw@hyperion ~]$ crontab -l
0-59/5  *       *       *       *       (cd /home/fffw/sonar/; phantomjs --proxy localhost:8787 sonar.js 2.0.0-beta4 >> 2.0.0-beta4.log 2>&1)
```

We can run several instances of sonar to test performace of different Lantern versions. Just run lantern at different proxy port and set PhantomJS proxy url accordingly.
```
lantern_linux_headless_v2.0.0 -addr="localhost:8787" -configdir="previous_config"
lantern_linux_headless_v2.0.1 -addr="localhost:8989" -configdir="new_config"
```

repository: httpsgithu/sonar

repo_name: httpsgithu/sonar


text:
# Test 789

Router2 redistributes two static routes into OSPF (<IP_ADDRESS>/10 and <IP_ADDRESS>/10). These routes are only present in GNS3. The same happens for the static route at Router0 for <IP_ADDRESS>/2.

## Offending commands

__Router0__
```
router ospf 100
  ...
  redistribute static
...
ip route <IP_ADDRESS> <IP_ADDRESS> FastEthernet0/1
```

__Router2__
```
router ospf 100
  ...
 redistribute static
...
ip route <IP_ADDRESS> <IP_ADDRESS> FastEthernet0/1
ip route <IP_ADDRESS> <IP_ADDRESS> FastEthernet0/0
```

__Command description__
```
ip route <IP_ADDRESS> <IP_ADDRESS> FastEthernet0/1
```

The above command creates a static route. It directs all traffic for the prefix <IP_ADDRESS>/10 (network address <IP_ADDRESS>, netmask <IP_ADDRESS>) to the interface `FastEthernet0/1`.

```
 redistribute static
```
This tells the OSPF routing process to advertise static routes in its area.

[More information](https://www.cisco.com/c/en/us/td/docs/switches/datacenter/sw/5_x/nx-os/unicast/configuration/guide/l3_cli_nxos/l3_route.html)
[More information](https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/8606-redist.html#ospf)

## Explanation

The problem has to be with the `redistribute static` command. All the routers have the static routes in their routing tables, but no router received an advertisement for such a route through OSPF.

## Problematic scenario

repository: backbonecabal/Metha

repo_name: backbonecabal/Metha