text:
# AcatoPHP
For my job application at Acato, I was assigned to build the following :

A web application in Laravel, where an user can register them self with : 'username', 'password' , 'email' , 'postalcode' , 'streetname'
and 'city' . the registration was succesfull the registered user has to receive an HTML e-mail. (I chose to log this for local development reasons)

To use this application simply clone the master branch.
run composer install in the root directory
and see the rest for yourself :)

# Laravel PHP Framework

[![Build Status](https://travis-ci.org/laravel/framework.svg)](https://travis-ci.org/laravel/framework)
[![Total Downloads](https://poser.pugx.org/laravel/framework/d/total.svg)](https://packagist.org/packages/laravel/framework)
[![Latest Stable Version](https://poser.pugx.org/laravel/framework/v/stable.svg)](https://packagist.org/packages/laravel/framework)
[![Latest Unstable Version](https://poser.pugx.org/laravel/framework/v/unstable.svg)](https://packagist.org/packages/laravel/framework)
[![License](https://poser.pugx.org/laravel/framework/license.svg)](https://packagist.org/packages/laravel/framework)

## License

The Laravel framework is open-sourced software licensed under the [MIT license](http://opensource.org/licenses/MIT).

repository: StefanoGroenland/AcatoPHP

repo_name: StefanoGroenland/AcatoPHP


text:
# Package

## Properties
Name | Type | Description | Notes
------------ | ------------- | ------------- | -------------
**Id** | **int** | The ID of the package. | [optional]
**Name** | **string** | The name of the package. | [optional]
**DiscountPercentage** | **double** | The discount percentage applied to the package. | [optional]
**SellOnline** | **bool** | When `true`, only products that can be sold online are returned.<br />  When `false`, all products are returned. | [optional]
**Services** | [**\Nlocascio\Mindbody\Model\Service[]**](Service.md) | Information about the services in the packages. | [optional]
**Products** | [**\Nlocascio\Mindbody\Model\Product[]**](Product.md) | Information about the products in the packages. | [optional]

[[Back to Model list]](../README.md#documentation-for-models) [[Back to API list]](../README.md#documentation-for-api-endpoints) [[Back to README]](../README.md)

license: MIT

repository: ranitham/mindbody-laravel

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: ranitham/mindbody-laravel


text:
Small tool helps People who have thouble reading scrapbook content after updated to Firefox Quantum.
This is just a reader, does not modify any of your record.

* Install:
Just download these files into your scrapbook data directory.
jquery-3.3.1.js, read.html, read.js

* Run:
Open read.html with firefox. That's all.

* Snapshot

![image](https://github.com/victorfence/scrabook-easy-viewer/blob/master/reader.png?raw=true)

repository: jottschi/scrapbook-easy-viewer

repo_name: jottschi/scrapbook-easy-viewer


text:
# lixiaocong's personal CMS

This is a personal Content Management System.

The system consists of 3 parts:
+ Blog
    - Register an account
    - Connect to QQ ans login with QQ
    - Post, update and delete blog
    - Comment on blog
+ Admin
    - Manage user, blog, comments
    - Upload download task and download file to your server
+ WeChat
    - Users can get latest blog on their WeChat

The project is based on Spring including:
- Spring Framework
- Spring Security
- Spring Social
- Spring Data
- Spring Boot
- Spring MVC

## Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

### Prerequisites

To run this project on your machine, you need to install NodeJS Tomcat8 and Aria2.

I'm using H2 as my database, you can change to MySQL and other JDBC database.
Execute db.sql to init your database

The downloader is aria2c, you can also change to other downloader such as Transmission,checkout my [code](https://github.com/lixiaocong/transmission4j)

## Deployment

Clone the project to your machine using git
```
cd <any folder on your machine>
git clone git@github.com:lixiaocong/lxcCMS.git
cd lxcCMS
```

Edit the /admin/src/environments/environments.prod.ts to config your server address.

Then compile the Angular admin app
```bash
cd admin
npm install
npm install -g @angular/cli
ng build --bh /admin/ --prod --aot
```
Create application.properties and qqconnectconfig.properties in /src/mian/resources/. An example can be found in wiki page on my GitHub.

Compile the Java project
```
./gradlew war
mv ./build/libs/lxcCMS.war ${tomcat_dir}/ROOT.war
```

Your can also use the [hook](https://github.com/lixiaocong/hook)
## Contributing

Please read [CONTRIBUTING.md](https://gist.github.com/PurpleBooth/b24679402957c63ec426) for details on our code of conduct, and the process for submitting pull requests to me.

## Author

**li xiaocong**

## License

BSD 3-Clause License

Copyright (c) 2016<EMAIL_ADDRESS>All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this
  list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.

* Neither the name of the copyright holder nor the names of its
  contributors may be used to endorse or promote products derived from
  this software without specific prior written permission.


text:
# 2.3.5

The v2.3.5 release adds a few new features.

## Features

 * Add ability to request a map redraw (#845)
 * Opacity control for rasters (#846)
 * Add an action to finish the measure geometry programatically (#847)
 * Allow setting the measure style (#848)

repository: ksundeen/sdk

repo_name: ksundeen/sdk


text:
[Home](./index.md) > [sip.js](./sip.js.md) > [ClientTransaction](./sip.js.clienttransaction.md) > [receiveResponse](./sip.js.clienttransaction.receiveresponse.md)

## ClientTransaction.receiveResponse() method

Receive incoming responses from the transport which match this transaction. Responses will be delivered to the transaction user as necessary.

Signature:

```typescript
abstract receiveResponse(response: IncomingResponseMessage): void;
```

## Parameters

|  Parameter | Type | Description |
|  --- | --- | --- |
|  response | IncomingResponseMessage | The incoming response. |

Returns:

`void`

gha_license_id: MIT


text:
<p align="center">
  A libopenTIDAL python wrapper.
</p>

MIT License

>  Copyright (c) 2021 Hugo Melder
>
>  Permission is hereby granted, free of charge, to any person obtaining a copy
>  of this software and associated documentation files (the "Software"), to deal
>  in the Software without restriction, including without limitation the rights
>  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
>  copies of the Software, and to permit persons to whom the Software is
>  furnished to do so, subject to the following conditions:
>
>  The above copyright notice and this permission notice shall be included in
>  all copies or substantial portions of the Software.
>
>  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
>  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
>  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
>  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
>  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
>  THE SOFTWARE.

### Introduction
libopenTIDAL is a TIDAL API client library written in ANSI C. It's lightweight, fast and easy to use.

After reverse-engineering the TIDAL API and documenting all endpoints, I had the idea to write a portable C library. The goal was to integrate the OAuth2 Device-Flow, auto-refreshing sessions and all endpoints.

A python module using openTIDAL is also available and easy to install (currently in development).

##### What is implemented?
* OAuth Log-In/Logout and Automatic Session Renewal
* Demo Session
* Playlist Creation, Deletion and Manipulation
* Mixes (also known as Radio)
* Favourites Management
* Recently Played, Your History, Because You Listened To {album} and other user-based content recommendations
* Pagination (Limit & Offset)
* Order & Sort Filters
* Content HTTP Streams (Audio & Video)
* Easy and Extensive Error Handling

### Wiki
Work in progress.

### Thread Safety
openTIDAL is thread safe.
You need to create a http-handle for a new thread.
Session refresh checks and requests are only available on the main thread.

### Building
```
$ git submodule init && git submodule update
```
```
$ pip3 install ./
```

##### Dependencies
openTIDAL uses libcURL for HTTP Requests. In modern systems curl is preinstalled (macOS, Windows 10 (1803 or later) and most Linux distributions).

You'll need the development package on some Linux distributions. The libcurl header files are bundled with the xcode command line tools on macOS.

On Debian & other APT-based Distros:
```
$ apt install libcurl-dev
```

On CentOS:
```
$ dnf install libcurl-devel
```

pyopenTIDAL uses the cffi module. This module requires a working C compiler if you build pyopenTIDAL from source.

## Disclaimer

I deeply discourage you from building and distributing copyright-infringing apps. Create something that adds up to TIDAL's Service.

## Credits
* cURL (Daniel Stenberg & Contributors)
* cJSON (Dave Gamble & Contributors)
* Base64 (The Apache Group.)

repository: Fokka-Engineering/pyopenTIDAL

branch_name: refs/heads/main

repo_name: Fokka-Engineering/pyopenTIDAL


text:
# Bullet
```js
class Bullet {}
```

Class for a Bullet object, which represents the bullets that Players will be shooting at each other

## Constants

### bulletSize
```js
const bulletSize = 5;
```

The size of each Bullet object

### bulletSpeed
```js
const bulletSpeed = 25;
```

The number of straight line pixels that this Bullet will move in a frame

### maxBounces
```js
const maxBounces = 3;
```

The maximum number of bounces that a Bullet can survive before being destroyed by a collision with a wall or [Obstacle][1]

### maxDamage
```js
const maxDamage = 10;
```

The maximum amount of damage a Bullet can do upon hitting a [Player][2]

The actual damage dealt is lowered by each bounce

## Instance Variables

### (x, y)

The co-ordinates of the top left corner of the Bullet.

!!! tip
    When drawing, half the size is subtracted in both directions to draw the center of the Bullet at the point (x, y)

### size

An instance based storage of the bullet size. Purely for use in collision testing

### (xChange, yChange)

The number of pixels this Bullet instance will move in the x and y directions respectively

This value will be calculated when the Bullet is fired

### bouncesRemaining

The number of bounces the Bullet can still survive before being destroyed

### owner

The [Player][2] instance that fired this Bullet instance

### bulletNum

The index of this Bullet in its owner's Bullet array

## Constructor
```js
function constructor(
	x,
	y,
	angle,
	owner,
	bulletNum
)
```

Creates a new Bullet instance from the center of it's owner travelling in the given angle

!!! note
	The `owner` and `bulletNum` values are used to reference this object in the [Player][1] class that fired it.

### Parameters
| Parameter |                      Description                       |
| --------- | ------------------------------------------------------ |
|     x     | The x co-ordinate of the top left corner of the Bullet |
|     y     | The y co-ordinate of the top left corner of the Bullet |
|   angle   |   The angle in which the Bullet was fired in radians   |
|   owner   |       The Player instance which fired the Bullet       |
| bulletNum |  The index of this Bullet in its owner's bullets array |

## Instance Variables

### draw
```js
function draw(
    context // Type: CanvasRenderingContext2d
) {}
```

Handles the drawing of this Bullet instance onto the canvas using its context and its owner's colour

### updatePosition
```js
function updatePosition() {}
```

Updates the Bullet's position by increasing or decreasing the x and y values by the xChange and yChange values

#### Parameters
| Parameter |                  Description                  |
| --------- | --------------------------------------------- |
|  context  | The context from the canvas used for the game |

### bounce
```js
function bounce() {}
```

Checks if the Bullet has any bounces remaining, and destroys it if it cannot bounce any more.

Reports back whether the Bullet has been destroyed

#### Returns
| Parameter |                          Description                          |
| --------- | ------------------------------------------------------------- |
| destroyed | True if the Bullet was destroyed by bouncing, false otherwise |

### checkPlayerCollision
```js
function checkPlayerCollision(
	players // Type: Player[]
)
```

Checks if a Player has been hit by this Bullet instance and deals damage to that instance

Ignores the Bullet's owner and Players who have died

!!! warning "Todo"
	Once the server is up and running, this method needs to be changed as a game client should only ever update its `local` player

#### Parameters
| Parameter |                    Description                    |
| --------- | ------------------------------------------------- |
|  players  | Array containing the Player instances in the game |

[1]: /game/obstacle "Obstacle"
[2]: /game/player "Player"

repository: gitter-badger/Arena-Electron

repo_name: gitter-badger/Arena-Electron


text:
# Wiins.io
[![Sauce Test Status](https://eps-git.s3.eu-west-3.amazonaws.com/welcome-to.png)](https://eps-git.s3.eu-west-3.amazonaws.com/welcome-to.png)
[![Sauce Test Status](https://eps-git.s3.eu-west-3.amazonaws.com/donations-adress.png)](https://eps-git.s3.eu-west-3.amazonaws.com/donations-adress.png)

Wiins is a social media with the particularity of centralizing all web functions to improve the entertainment, security, comfort and ease of use.

Donation link :
- [Our bitcoin account (BTC)](https://www.blockchain.com/btc/address/3LTuh8uygp9FgjgsiDjSheWE3EesgEBgDi) : 3LTuh8uygp9FgjgsiDjSheWE3EesgEBgDi
- [Our bitcoin cash account (BCH)](https://www.blockchain.com/btc/address/17aPovD2JS6kbVajHjm3SZhRqgyz8jmyvP) : 17aPovD2JS6kbVajHjm3SZhRqgyz8jmyvP
- [Our ethereum address (ETH)](https://www.blockchain.com/eth/address/0xB30E1527785011Ce1746023A86540Ae99aA51970) : 0xB30E1527785011Ce1746023A86540Ae99aA51970

## Link to access the platorm

- [The production link](https://www.wiins.io/sign/in), is connected to the master
- [The developement link](https://piins-front-end-web.herokuapp.com/sign/in), is connected to the pre-master

## Requirement

The easier way to help to community to update or add a language is to do it with https://www.electronjs.org/apps/i18n-manager.
You can just update all the words of the plateform by opening the project with this software. This library is connected to the app and the web plateform.

## Important to know

- Join our discord [WiinsCommunity](https://discord.gg/eGW8f75). The community can talk about a task and help each other. A reward will be split only if the owner of the pushed branch assures to [iamraphaelsalei](https://twitter.com/iamraphaelsalei) the participation.
- On discord, everyone can know more about the company. (History of rewards, future update, special challenge, etc.. )
- Even if your update is not mentioned. Anyone can push a new version which can improve the platform (the administrators can merge if they deem the idea necessary)
- Don't forget to share the project, more we have in the community, better the updates, and better the rewards

## Caution

- Only the twitter of [iamraphaelsalei](https://twitter.com/iamraphaelsalei) is official. Don't send donations to other bitcoin addresses. (Make sure during the donation, [iamraphaelsalei](https://twitter.com/iamraphaelsalei) is to the owner of the publication)

## Contacts

My twitter : [iamraphaelsalei](https://twitter.com/iamraphaelsalei)

repository: etsraphael/WiinsApp

branch_name: refs/heads/production

gha_language: JavaScript

repo_name: etsraphael/WiinsApp


text:
# learning-java
Repo to learn programming in Java 11+

## TOC
- Control flow
- Operators
- Generic classes & methods
- Functional Style
- Collections
- Streams
- Lambdas
- Objects
- Classes
- Interfaces
- Inheritance
- Exception handling
- Primitive types
- String
- Threads
- JVM/JRE
- IO
- Modules
- Data Structures
- Concurrency
- Best Practices

repository: dapithor/learning-java

repo_name: dapithor/learning-java


text:
# Kubernetes-Cleaner

[![Go Report Card](https://goreportcard.com/badge/github.com/Cytram/kubernetes-cleaner)](https://goreportcard.com/report/github.com/Cytram/kubernetes-cleaner)

CronJob that remove pods from cluster.

# Usage

This cleaner will look in an given namespace and search for a given pod or a regex can be given.

Set Enviroment variables
```
export CLEANER_NAMESPACE=dev
export CLEANER_SEARCH=telepresence.*
```

Run application

```
$ ./cleaner
```

# Build

The cleaner can be build using the standard Go tool chain if you have it available.

```
go build
```

You can build inside a docker imagee as well.
This produces a `cleaner` image that can run with the binary as entry point.

```
docker build -t cleaner .
```

# Deployment

To deploy the Cleaner in Kubernetes, you can find a simple Kubernetes Cronjob and RBAC yaml in the `examples` folder. You have to change the cronjob and RBAC namespace so it has `LIST` and `DELETE` rights in Kubernetes.

To deploy it to your kubernetes cluster run the following commands:

```
kubectl apply -f examples/cronjob.yaml
kubectl apply -f examples/rbac.yaml
```

repository: Cytram/kubernetes-cleaner

repo_name: Cytram/kubernetes-cleaner


text:
# yesno

`yesno` is a simple command providing a 'yes/no' prompt to your shell script.

# How to install

```bash
go get github.com/minoritea/yesno
```

# Usage

```bash
#!/bin/bash
if yesno "are you sure?";then # if you type y
  # continue to execute your commands
fi
```

# License
[MIT LISENCE](https://github.com/minoritea/yesno/blob/master/LICENSE)

repository: minoritea/yesno

repo_name: minoritea/yesno


text:
# TSN_Colab
This repository contains the Google colab implementation of Temporal Segment Networks for action recognition in videos.

The original paper can be found here https://arxiv.org/abs/1705.02953.

And the officail implementation here https://github.com/yjxiong/temporal-segment-networks.


text:
# NeoRack Specification

The NeoRack specification is a balancing act between a number of conflicting needs:

1. The need to maintain backwards compatibility.

2. The need for a clear API that helps developers intuit how to leverage NeoRack using idiomatic Ruby.

3. The need to support real-time applications (i.e., long polling and connection upgrades).

4. The need to promote separation of concerns between application logic and network/protocol logic.

5. The need to make servers authorship flexible while allowing for more efficiency (less memory use, less string conversions, etc').

## Why a separate response object?

The most backwards compatible approach would have been to have the `request` object called `env` and require that it respond to `.response`.

This would allow Rack and NeoRack applications to look almost the same `Proc.new {|env|...}`.

However, this would also make `response` available for persistent connections long after the response was sent, which may result in subtle bugs.

In addition, NeoRack opted for **explicit backwards compatibility** rather than an **implicit** one.

This means that applications should be aware that they are using a backwards compatibility layer and CGI style Rack code.

## Why not use Hash directly for the request object?

The `request` object should inherit from Hash, but isn't directly a Hash.

This allows Ruby mix-ins to be utilized for NeoRack extensions (i.e., `request.class.include ...`).

By requiring the `request.server` method, servers are already required to add their own method, making it impractical for them to use the Hash class directly.

## Why not adopt Rack's header naming?

The CGI Rack specification used HTTP variables with the `HTTP_` prefix for some (but not all) variables and with the `-` replaced with `_`.

This is a historical CGI requirement related to the fact that the variables were stored in the processes Unix `env` object before the process was forked and had naming restrictions that allowed these objects to be accessed from any script / language (i.e., `bash` scripts, etc').

However, this approach requires more String objects and CPU processing time.

For applications that do not require backwards compatibility, it makes no sense to copy the HTTP header names to a new String when they can simply use the same String (and down-case it in place).

The use of lower case header names also matches the HTTP/2 protocol behavior and provides opportunities for servers to optimize memory usage where header name objects are concerned.

## What about protocol details

Protocol details, such as `keep-alive`, `content-length` etc' **should** be handles by the server, not the application.

Incoming protocol details may still be accessible, if not removed by the server, but they should be ignored by the application.

repository: boazsegev/neorack

path: /SPEC - rational.md

filename: SPEC - rational.md

repo_name: boazsegev/neorack


text:
---
author: angad
categories:
  - Events
  - Featured
  - Headline
  - Photos
comments: true
date: 2010-10-25T00:00:00.000Z
title: The Ruby Tournament!
url: /2010/10/the-ruby-tournament/
aliases:
  - /2010/10/25/the-ruby-tournament/
---

We had a great time at the Ruby Tournament held on the 22nd of October. It was great to have Chris Boesch, Professor at School of Information Systems from SMU. He and his wife, Sandra conducted the tournament with the same vigor and energy, as always. And we loved it.

We had 27 participants in the Programming Lab 1 in SoC, NUS. It was fun to see them all churning out Ruby code to grab onto the prizes (and glory). The SingPath platform created by Chris and Sandra is a great place to practice new languages and syntax. The leaderboard on the screen in front of the participants made the tournament even more interesting.

The prizes were sponsored by IDA and Garag3. We had Ruby books - "Cloning internet applications with Ruby" by Chang Sau Sheong, thumb drives and memory card readers as prizes.

Here are the pictures from the day and we can see happy prize winners :)
//www.flickr.com/photos/41455961@N08/

Created with flickr slideshow from softsea.

The Hack Workshop Series, sponsored by IDA Singapore, equips geeks/non-geeks with a good base in development and idea execution.

It is co-organized with NES, Garag3, e27, Hackerspace and NOC Alumni.

repository: nushackers/nushackers-site

gha_language: HTML

repo_name: nushackers/nushackers-site


text:
packer_wrapper.pl
=================

### What is it

`packer_wrapper.pl` is a simple perl script to help with templating packer builds. This version has been developed with chef as the provisioner, but should work with other provisioners. It generates environment variables which are sourced and fed in to a json template which packer uses.

The template is parsed as an argument - so theoretically it should be able to do anything that packer is able to, although modification of the script might be necessary (the script currently supports and has been tested against the chef provisioner, using both roles and environments and chef policy files).

### What is does

`packer_wrapper.pl` takes a list of arguments - and combines the users environment - a file called `projects.vars` (containing variables about the current project such as the assume role etc..).

It creates a key pair on AWS if not available locally, combines environment variables and runs a packer build with a defined template, to build an AMI.

### Using it

Execute it on the command line with arguments, e.g.

`./packer_wrapper.pl  --session keypair-name -r base`

It takes quite a few arguments, some of these have defaults set, but would probably have to be overridden for your project.

The arguments are as follows:

```
-s, --session             aws-key-pair to create   (mandatory)
-r, --resource            chef role or policy name (mandatory)
-i, --image               aws-image (base image to build from)
-t, --type                aws instance type
-v, --volume              size of EBS volume (in gigabytes)
-E, --environment         chef environment or policy group
-a, --attribute-json      reserved for future use (maybe injecting additional json into template)
-vpcid, --vpcid           AWS vpc (id) in which packer builds AMI
-subnetid, --subnetid     AWS subnet (id) in which packer builds AMI
-j, --json-file           path to packer json file used to create the build
```

e.g.

```
/packer_wrapper.pl --session 'new-ssh-keypair' --vpcid vpc-66b9af02 --subnetid subnet-9f7b21c7 \
-E staging -r facade -j packer-chef-policy.json --image ami-495c612f
```

** Hint **
if you have a .chef directory in the root directory of the repo with a knife.rb file your life will become much simpler. And you *should* be able to use it all the way down the directory tree.

*cat .chef/knife.rb*
```
current_dir = File.dirname(__FILE__)

user = ENV['OPSCODE_USER'] || ENV['USER']
node_name                user
client_key               "#{ENV['HOME']}/.chef/#{user}.pem"
secret_file              "#{ENV['HOME']}/.chef/js_identity_encrypted_data_bag_secret"
syntax_check_cache_path  "#{ENV['HOME']}/.chef/syntax_check_cache"
chef_server_url          "https://api.chef.io/organizations/js-identity"
cookbook_path            ["#{current_dir}/../cookbooks", "#{current_dir}/../site-cookbooks"]
cookbook_copyright       "JSainsburyPLC"
cookbook_license         "apachev2"
cookbook_email           ENV['EMAIL_ADDRESS']

# Amazon AWS
knife[:aws_access_key_id]     = ENV['AWS_ACCESS_KEY_ID']
knife[:aws_secret_access_key] = ENV['AWS_SECRET_ACCESS_KEY']
knife[:aws_ssh_key_id]        = ENV['AWS_SSH_KEY_ID']

# Knife SSH settings
knife[:ssh_user]              = ENV['SSH_USER']
knife[:identity_file]         = "#{ENV['HOME']}/.ssh/#{ENV['SSH_KEY']}"

knife[:ssh_attribute]         = 'cloud.local_ipv4'
knife[:ssh_timeout]           = 10

Dir["#{ENV['HOME']}/.chef/knife.d/*.rb"].each {|file| require file }
```

As said earlier, the script also relies upon a file called `project.vars`, here is a example file:
*cat project.vars*
```
export AWS_SESSION_TOKEN=$AWS_SECURITY_TOKEN
export CHEFORG="js-identity"
export PROJECT_IAM_ROLE="arn:aws:iam::AWS_ACCOUNT_NUMBER:role/js_roles_js_identity_partial"
export CHEF_VALIDATION_CLIENT_NAME="js-identity-validator"
export CHEF_SECRET_KEY="~/.chef/encrypted_data_bag_secret"
export CHEF_VALIDATION_KEY="~/.chef/js-identity-validator.pem"
export CHEF_SERVER_URL="https://api.chef.io/organizations/js-identity"
export CHEF_ENCRYPTED_DATA_BAG_FILE_NAME="js_identity_encrypted_data_bag_secret"
export ORG=$CHEFORG
export ORGNAME=$CHEFORG
export ACCESS_KEY=$AWS_ACCESS_KEY_ID
export SECRET_KEY=$AWS_SECRET_ACCESS_KEY
```

**Please replace AWS_ACCOUNT_NUMBER with the account number for the project and likewise the IAM role**

Finally here is an example template for using chef policy files:
[packer-chef-policy.json](packer-chef-policy.json)

And an example template for using chef roles / environments:
[packer-chef-role.json](packer-chef-role.json)

### To Do

Maybe re-write it in a different language which is more popular, which retains exactly the same functionality (including, switches etc..), both scripts should be consistent with each other.


text:
---
layout: for-developers
title: "Using Apache as a reverse proxy"
permalink: self-hosting/nss/apache
tags: [pod-server]
exclude: true
redirect_from:
  - /for-developers/pod-server/apache
redirect_to:
  - https://github.com/solid/solidproject.org/wiki/Using-Apache-as-a-reverse-proxy
---

# Using Apache as a Reverse Proxy

A reverse proxy allows you to run a Solid server on a local port
and let the proxy handle traffic to public HTTP and HTTPS ports.

gha_language: SCSS


text:
---
title: Congratulations to Dr. Suki Wong
category: research
excerpt: Dr. Suki Wong PhD defense
feature_text: <h1 style="color:White">  Dr. Suki Wong </h1>
image: http://galenmckinley.github.io/assets/img/ocean.jpg
tags:
comments: true
---

Congratulations to Suki Wong for her successful PhD defense on May 30.

Suki has worked to understand the ocean carbon cycle across scales from coastal to global, using in situ data, machine learning derived products and CMIP6 models. One paper on the representation of carbon fluxes due to ENSO in CMIP6 is [published](https://academiccommons.columbia.edu/doi/10.7916/b30q-be39), and another analyzing global-scale CO2 flux variability in our LDEO-HPD observation-based product is coming soon.

![Galen McKinley, Suki Wong, Richard Seager]({{site.baseurl}}/assets/img/Wong_McKinley_Seager_30May2023.jpg){:height="70%" width="70%"}

Suki with her advisors, Galen McKinley and Richard Seager


text:
# .NET CI Pipelines

This document details the new pipeline workflow available on some .NET CI Jenkins servers.  It covers an overview of the system, how to create pipelines, and how to tell Jenkins to run your pipeline.

# Overview

.NET CI uses Jenkins to enable CI for OSS projects in .NET Core (and a few others).  Traditionally, we have primarily used Jenkins 'freestyle' jobs to do most of the work.  These jobs are fairly ridgid in their workflow, made up of several predefined phases.  Their entire workflow is 'statically' configured in Jenkins by the Job DSL plugin and a commit to the definition script (typically called netci.groovy) is required to update that workflow.

While useful, these freestyle jobs have a number of drawbacks:
* It's not possible to change the workflow of the job in a PR.
* Multi-machine workflows require linking several freestyle jobs together.  This is difficult to define in the job dsl script (netci.groovy) and prone to error.
* The job dsl definition script (netci.groovy) file tends to become very difficult to decipher over time.  They tend to grow into a spaghetti code mass.

Jenkins Pipelines were introduced a few years back and became a 'first class' citizen in Jenkins with the Jenkins 2.0 overhaul.  They solve many of the issues with freestyle jobs. A pipeline job reads a script from source control and executes it.  This script interacts with the Jenkins CI system to allocate nodes, run commands, gather results, etc.

# .NET CI System Lifecycle - FreeStyle vs. Pipelines

Assuming some familiarity with the existing .NET CI system (netci.groovy), this section details the current FreeStyle (netci.groovy) lifecycle and how the Jenkins pipeline workflow is different.

## Classic (Freestyle) Workflow Today

1. User adds an entry to the [repo list](../data/repolist.txt).
2. Each jenkins server notices a change to the [repo list](../data/repolist.txt) and reads the file.  It creates a folder for each entry in the list that is targeted at the server and a 'generator' job which watches the repo/branch combo for the changes in the CI definition file (usually netci.groovy)
3. When a new CI definition file is committed to the repo, Jenkins runs the netci.groovy file.  This file is effectively a script that sets up state in Jenkins.  In this case, the state consists of the set of jobs, their triggers, views, etc. that are defined for the repo.
4. The created jobs start waiting for their triggers (PR test, PR comment, etc.)
5. Upon triggering, Jenkins reads the set of steps preconfigured in the job (source to clone, build steps to run, test results to publish) and executes them on the target machine pool configured in the job.

## The New World Of Pipelines

1. User adds an entry to the [repo list](../data/repolist.txt).
2. Each jenkins server notices a change to the [repo list](../data/repolist.txt) and reads the file.  It creates a folder for each entry in the list that is targeted at the server and a 'generator' job which watches the repo/branch combo for the changes in a 'pipeline declaration' file (usually pipelines.groovy)
3. When a new pipeline declaration file is committed to the repo, Jenkins runs it. The pipeline declaration file is similar to the traditional CI definition file, but is more barebones.  It notes the pipeline script to run in the repo, the parameters to pass it, and the triggers on which to run it.  The entire workload logic is contained within the pipeline itself, which is read from source control.
4. The created pipeline jobs start waiting for their triggers (PR test, PR comment, etc.)
5. Upon triggering, Jenkins reads the specified pipeline script, typically from source control, passes it the default set of parameters configured in the pipeline declaration file, and executes the pipeline.

## What Does A Pipeline CI Declaration Look Like?

The new pipeline declaration files are similar in form to the traditional CI definitions, with much of the complexity taken out.

```
// Import the pipeline declaration classes.
import org.dotnet.ci.pipelines.Pipeline

// Declare a new pipeline.
def windowsPipeline = Pipeline.createPipeline(this, 'windows-pipeline.groovy')

// Over the array of 'Debug' and 'Release' configurations, generate a pipeline
// job that runs windows-pipeline on each push, passing in the parameter
// 'Configuration' with the value of 'configuration'
['Debug', 'Release'].each { configuration ->
    windowsPipeline.triggerPipelineOnPush(['Configuration':configuration])
}

// Over the array of 'Debug' and 'Release' configurations, generate a pipeline
// job that runs linux-pipeline.groovy on each PR, passing in the parameter
// 'Configuration' with the value of 'configuration'
def linuxPipeline = Pipeline.createPipeline(this, 'linux-pipeline.groovy')
// Pass Debug/Release configuration
['Debug', 'Release'].each { configuration ->
    linuxPipeline.triggerPipelineOnEveryPR(['Configuration':configuration])
}
```

## What Does A Pipeline Script Look Like?

A simple Jenkins pipeline script looks something like this:

```
String stringToPrint = 'foo2'
// 'node' indicates to Jenkins that the enclosed block runs on a node that matches
// the label 'windows-with-vs'
node ('windows-with-vs') {
    // 'stage' is primarily for visualization.  All steps within the stage block
    // show up in the UI under the heading 'Say Hello'.
    stage ('Say Hello') {
        // 'echo' prints the string to the pipeline log file
        // The echoed string is a multi-line string with no inline
        // replacement (single quotes)
        echo '''Hello World.
        This is a Jenkins pipeline.
        '''
    }
    stage ('Run some command') {
        // 'bat' Executes a batch script with the enclodes text.
        // In this case, the enclosed string is a multiline string with
        // inline replacement (double quotes).  The expression inside of ${} will
        // be replaced. Here, it's the stringToPrintVariable.
        bat """type foo > bar.txt
        type ${stringToPrint} >> bar.txt
        """
    }
    stage ('Archive artifacts') {
        // 'archiveArtifacts' Archives artifacts to the server for
        // later.
        archiveArtifacts allowEmptyArchive: false, artifacts: 'bar.txt'
    }
}
```

## What Can Be Changed In A PR? What Can't Be Changed?

In the traditional CI definition, not much could be changed in a PR.  Changes to the CI definition did not take effect until after commit.  There are ways to compile the definition (@dontet-bot test ci please), then manually enable and run new/modified jobs, but they are clunky.

Pipelines improve upon this substantially.  Becuase the pipeline script, where most of the workflow logic is defined, is read from source control, a pull request will pick up any changes to the script.  Unfortunately, the pipeline declaration is still run and created on commit, so the following changes will not show up in your PR, though they can still be verified with '@dotnet-bot test ci please'

* Changing file names of pipelines
* Adding/removing pipelines
* Changing/adding triggers for pipelines
* Parameters passed to pipelines

# Onboarding Your Project onto Pipelines

The following details the process by which you can onboard your projects onto the new pipelines.

1. Make a PR that adds an entry to the repo list. dotnet/dotnet-ci and dotnet/dotnet-ci-internal.  dotnet-ci should be used for OSS pipelines, dotnet-ci-internal for VSTS/private pipelines.
    1. [OSS](https://github.com/dotnet/dotnet-ci/blob/master/data/repolist.txt)
    2. [VSTS/Internal](https://github.com/dotnet/dotnet-ci-internal/blob/master/data/repolist.txt)
    3. The entry should have the following characteristics, in addition to the other typical parameters:
        * OSS GitHub pipelines
            * definitionScript=<path to declaration script in your repo>
        * VSTS pipelines
            * The first entry, is <project>/<repo-name>
            * server=dotnet-vsts
            * credentials=<please see mmitche for info, but generally
            * collection=<project collection server, mseng or devdiv>
            * definitionScript=<path to declaration script in your repo>
2. Add your pipeline declaration script at the indicated place in your repo.   For a sample starter, please see the [sample](sample-pipeline-declaration.groovy).  For a list of triggers, please see [Pipeline.groovy](../src/org/dotnet/ci/pipelines/Pipeline.groovy).  Methods that set up triggers for pipelines start with 'trigger'.  The triggers are also listed [below](#available-triggers).  It's recommended that you check-in your pipeline declaration prior to writing your pipeline script, with manual (triggerPipelineManually) or GitHub comment (triggerPipelineOnGithubPRComment) triggers enabled.  Then verification/development of your new pipeline can be done in PR or by manually launching it against your dev branch/fork.
3. Write your pipeline.  Please see [below](#writing-net-ci-pipelines) for information.

# Writing .NET CI Pipeline Declarations

Writing the CI declarations is quite simple.  After the initial import, you declare your pipeline to Jenkins.  The `this` pointer passed is the context that the CI declaration script is executing in.  It's used to generate jobs in Jenkins for each call to one of the `trigger*` methods.

```
// Declare a new pipeline.
def windowsPipeline = Pipeline.createPipeline(this, 'windows-pipeline.groovy')
```
Then simply determine what parameters you wish to pass to this pipeline script and what triggers you wish to use and make the appropriate calls to `trigger*` methods.

```
windowsPipeline.triggerPipelineOnPush(['Configuration':configuration])
```

## Available Triggers
* triggerPipelineOnEveryPR (GitHub, VSTS) - Triggers the pipeline on every PR.
    `myPipeline.triggerPipelineOnEveryPR('GitHub Status Check Name', ['paramA':'valueA', 'paramB,valueB'])`
* triggerPipelineOnEveryGithubPR (GitHub) - Triggers the pipeline on every PR.
    `myPipeline.triggerPipelineOnEveryGithubPR('GitHub Status Check Name', ['paramA':'valueA', 'paramB,valueB'])`
* triggerPipelineOnEveryGithubPR (GitHub) - Triggers the pipeline on every PR with a custom re-trigger phrase
    `myPipeline.triggerPipelineOnEveryGithubPR('GitHub Status Check Name', ".*test\\W+my\\W+job.*", ['paramA':'valueA', 'paramB,valueB'])`
* triggerPipelineOnGithubPRComment (GitHub) - Triggers the pipeline on a PR only when the status check text is commented.
    `myPipeline.triggerPipelineOnGithubPRComment('GitHub Status Check Name', ['paramA':'valueA', 'paramB,valueB'])`
* triggerPipelineOnGithubPRComment (GitHub) - Triggers the pipeline on a PR only when a specific phrase is commented.
    `myPipeline.triggerPipelineOnGithubPRComment('GitHub Status Check Name', ".*test\\W+my\\W+job.*", ['paramA':'valueA', 'paramB,valueB'])`
* triggerPipelineOnPush (GitHub/VSTS) - Triggers a pipeline on a push
    `myPipeline.triggerPipelineOnPush(['paramA':'valueA', 'paramB,valueB'])`
* triggerPipelineOnVSTSPush (VSTS) - Triggers a pipeline on a push (VSTS specific)
    `myPipeline.triggerPipelineOnPush(['paramA':'valueA', 'paramB,valueB'])`
* triggerPipelineOnGithubPush (GitHub) - Triggers a pipeline on a push (GitHub specific)
    `myPipeline.triggerPipelineOnPush(['paramA':'valueA', 'paramB,valueB'])`
* triggerPipelinePeriodically (GitHub/VSTS) - Triggers a pipeline on a shedule, specified by cron job syntax.
    `myPipeline.triggerPipelineOnPush('@hourly', ['paramA':'valueA', 'paramB,valueB'])`
* triggerPipelineManually (GitHub/VSTS) - Adds a pipeline job that can be triggered when desired by manual or REST API interaction.

# Writing .NET CI Pipelines

Writing .NET CI pipelines is significantly more straightforward than the old .NET CI job definitions.  Each pipeline should start with the following:

```
@Library('dotnet-ci') _
```

This pulls in the .NET CI SDK and imports all the global methods and utility functionality.

## Incoming Parameters

Parameters passed to the pipeline are implicitly added to the environment.  They are also accessible via local variables and the `params` local. For instance, if a pipeline had a String parameter called 'Configuration' set to 'Debug', the following would be true:
```
assert env['Configuration'] == Configuration
assert params.Configuration == env['Configuration']
```
Note that there is an important caveat to this.  Accessing variables via the local actually implicitly accesses the environment map.  Just like on a typical OS, the environment is simply a list of strings.  Therefore, if a boolean parameter is passed in, the local will refer to the string value of the boolean, not the true/false value.
```
assert env['IsMyBooleanParam'] == true // Incorrect usage
assert IsMyBooleanParam == true // Incorrect usage
assert params.IsMyBooleanParam == true // Correct usage
```
Therefore, as a best practice when dealing with incoming parameters, accessing them as `params.ParamName` is safer and clearer.

### Default Parameters/Environment Variables

Jenkins injects a number of default parameters into pipelines, and the .NET CI SDK injects a few others.  Here are some of them:
* WORKSPACE - Workspace path on the node (only valid inside the a node block)
* BUILD_ID - ID of the build (name/number combo)
* BUILD_NUMBER - Number of the build
* GitBranchOrCommit (added by .NET CI) - Branch/commit to build
* RepoName (added by .NET CI) - Repository, with org/project name
* OrgOrProjectName (added by .NET CI) - GitHub org or VSTS Project name containing the repo
* QualifiedRepoName (added by .NET CI) - Combination of OrgOrProjectName and RepoName
* BranchName - Target branch for this job

## Node/Docker Blocks

Node blocks wrap functionality the runs on an agent with a workspace.  Inside a node block you can run batch scripts, archive data, run tests, etc.  In .NET CI, you are encouraged to use two wrappers around Jenkins node functionality: `simpleNode` and `simpleDockerNode`.  These node blocks handle cleanup, label assignment, and a few other tasks for you.

```
// simpleNode allocates a new node with the OS as the first parameter and
// the version as the second.  These node names are resolved from the
// src/org/dotnet/ci/util/Agents.groovy in `getAgentLabel`.
// Users of the traditional CI job definitions will remember this as
// Utilities.setMachineAffinity.
simpleNode('Windows_NT','latest') {
    echo 'Hello World'
}
```
Docker is also supported:
```
// simpleDockerNode allocates a new node and runs docker on it, downloading the specified image and executing the enclosed block inside the container.  Cleanup is done for you.
simpleDockerNode('microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2') {
    echo 'Hello World'
}
```

## Checking Out Source
Source is not automatically checked out into the workspace at the allocation of a node, but there is an easy step for this. `checkout scm` checks out the same source that was used to checkout the pipeline script.  So if a pipeline was triggered on every PR run, Jenkins will read the pipeline script from the PR branch, and `checkout scm` would pull the pipeline script's repository at the same branch/commit.

Example:
```
simpleDockerNode('microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2') {
    stage ('Checking out Source') {
        // This step checks out the same source control that was configured
        // for the pipeline script itself.  'scm' is a variable representing the
        // source control settings for the pipeline
        checkout scm
    }
}
```

You can also check out arbitrary repos using the `git` step.  These repos can even be checked out along side the regular scm.

Example:
```
simpleDockerNode('microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2') {
    stage ('Checking out Source') {
        // This step checks out the same source control that was configured
        // for the pipeline script itself.  'scm' is a variable representing the
        // source control settings for the pipeline
        checkout scm
    }
    stage ('Checkout corefx') {
        // Creates a directory called corefx under the workspace, and all
        // commands under this have the 'corefx' current working directory
        dir('corefx') {
            git 'https://github.com/dotnet/coreclr'
        }
        dir('coreclr at another branch') {
            git url: 'https://github.com/dotnet/coreclr', branch: 'release/2.0.0'
        }
    }
}
```
## Parallelism
Jenkins pipelines allow for parallelism using the `parallel` statement.  The parallel statement takes a map of the names of the parallel branch of workflow (e.g. 'Build x64') to each corresponding workflow.  For example, a workflow that echoes two messages in parallel might look like:
```
parallel (
    'Hello World" : { echo 'Hello World'},
    'Hello Universe" : { echo 'Hello Universe'}
)
```
A similar workflow might be:
```
def parallelWork = [
    "x64 build" : {
        simpleNode('Windows_NT', 'latest') {
            checkout scm
            echo 'Build x64'
        }
    },

    "x86 build" : {
        simpleNode('Windows_NT', 'latest') {
            checkout scm
            echo 'Build x86'
        }
    }
]

parallel parallelWork
```
Failures in either branch will
## Timeouts
Timeouts can be specified for blocks of pipeline code:
```
simpleDockerNode('microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2') {
    // If the enclosed block doesn't complete within 5 minutes,
    // then the pipeline will fail.
    timeout(5) {
        sh './build.sh'
        sh './test.sh'
    }
}
```
## Retries
Retries can be implemented fairly simply too.  HEre
```
simpleDockerNode('microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2') {
    // If the enclosed block doesn't complete within 5 minutes,
    // due to the timeout, then the block will fail.  The block will retry up to 3
    // times before giving up.
    retry(3) {
        timeout(5) {
            sh './build.sh'
            sh './test.sh'
        }
    }
}
```
## Errors and error handling
Each pipeline step can have errors which will affect the outcome of the pipeline.  For instance, using `sh './build.sh'` will fail the current pipeline, or the current branch of a parallel workflow if build.sh returns a non-zero exit code.  Errors can also be thrown explicitly using the `error` step.
```
    simpleDockerNode('microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2') {
        if (params.Outerloop) {
            error 'Outerloop not supported in this docker container'.
        }
    }
```
Errors, which are effectively exceptions, can also be caught, rethrown, etc.  Just like in typical Java/Groovy/C# code, we can use `try/catch/finally` blocks:

```
simpleDockerNode('microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2') {
    timeout(5) {
        try {
            // We expect that publish.sh will fail right now, because the
            // publishing service is unavailable due to an outage.  It's not
            // critical for our build, so just continue.
            sh './publish.sh'
        }
        catch(err) {
            echo 'Publishing service down, continuing build!'
            // Log the failure so we can check it out.
            archiveArtifacts allowEmptyArchive: true, artifacts: "msbuild.log"
        }
    }
}
```
Maybe we want to do some logging upon failure:
```
simpleDockerNode('microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2') {
    try {
        // This step really mucks up the temp dir.  Make sure we clean this up
        // before continuing onto testing.
        sh './build.sh'
    }
    finally {
        sh './clean-temp.sh'
    }
    sh './test.sh'
}
```
And maybe we even want to log and rethrow:
```
simpleDockerNode('microsoft/dotnet-buildtools-prereqs:rhel7_prereqs_2') {
    try {
        // This step tends to fail, but we don't know why. Make sure we
        // log on failure, but propagate the error outward.
        sh './build.sh'
    }
    catch(e) {
        archiveArtifacts allowEmptyArchive: true, artifacts: "msbuild.log"
        throw e
    }
}
```
## Multi-machine workflows and stashing
One of the strengths of the Jenkins pipelines is the ability to orchestrate multiple machines in the same script. To do this, we simply write a pipeline that has multiple node blocks.  We can pass files between blocks any way we'd like (e.g. Azure Blob Storage), but one easy way is to use the `stash` and `unstash` steps to create a small temporary archive. Note that caution should be used to limit archive size.
```
simpleNode('Windows_NT','latest') {
    // Build some stuff
    bat 'build.cmd'
    // Stash this for a subsequent Linux job
    stash name: 'nt-build-artifacts', includes: 'bin/foo.dll'
}

simpleNode('Ubuntu14.04','latest') {
    dir ('linux-bin') {
        // Unstash to a different directory
        unstash 'nt-build-artifacts'
    }
    // Build some stuff
    sh './build.sh linux-bin/foo.dll'
}
```

## .NET CI SDK Utility Functionality
The .NET CI SDK, which is imported at the start of your pipelines, contains a number of utility steps, sometimes called 'global variables' in pipelines, which make life easier.  Each step is implemented in its own script file under the [vars](../vars) directory in this repository.  Most utility steps should be fairly self explanatory.  Please see the [defining global variables](https://jenkins.io/doc/book/pipeline/shared-libraries/#defining-global-variables) for info on how they work.  Some interesting ones are highlighted here
* getUser() - Attempts to get the user who started the run.  Can be useful for some reporting/submission steps
* getCommit() - Attempts to get the commit for this run.  For a PR, this will be the PR source commit.  For a push/manually triggered run it's the commit of the repo in the directory which getCommit() is called.  This is becuase a job can check out multiple repositories
* getLogFolder() - Gets the name of the log folder automatically created in the workspace when `simpleNode` or `simpleDockerNode` is used.  This folder is automatically archived before existing the node.
* getHelixSource() - For Helix submissions, attempts to construct a helix source for the run that can be passed to the Helix submission script.
* waitForHelixRuns(helixRunsBlob) - Given the json output of SubmittedHelixRuns.txt, wait for all of the runs to finish and report their status.  It does not need to be called inside a node block, and this should be avoided to improve efficiency.
    ```
    def logFolder = getLogFolder()
    def submittedHelixJson = readJSON file: "${logFolder}/SubmittedHelixRuns.txt"
    waitForHelixRuns(submittedHelixJson)
    ```
## .NET CI Pipeline Examples

* [CoreFX Linux pipeline](https://github.com/dotnet/corefx/blob/master/buildpipeline/linux.groovy).
* [CoreFX Windows pipeline](https://github.com/dotnet/corefx/blob/master/buildpipeline/windows.groovy).
* [CoreFX OSX pipeline](https://github.com/dotnet/corefx/blob/master/buildpipeline/osx.groovy).
* [Pipeline tests (written in pipeline)](../tests/pipeline/pipeline-tests.groovy)

# Additional Resources

Note that if you come across "Declarative Pipeline" references, these are not a pipeline form that we utilize today.  We use Scripted Pipelines.

* [Jenkins pipeline tutorial](https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md)
* [Jenkins official pipeline tour](https://jenkins.io/doc/book/pipeline/)
* [Jenkins pipeline shared library globals](https://jenkins.io/doc/book/pipeline/shared-libraries/#defining-global-variables)
* [Pipeline syntax reference](https://jenkins.io/doc/book/pipeline/syntax/) - See bottom of page for Scripted syntax reference.
* [Pipeline Steps Reference For Installed Plugins](https://ci3.dot.net/pipeline-syntax/globals)

repository: mavasani/dotnet-ci

repo_name: mavasani/dotnet-ci


text:
---
layout: post
title: "OSNEK"
description: ""
category: gene family
---

* **Information**
    + OsNek1, [LOC_Os03g43590](http://rice.uga.edu/cgi-bin/ORF_infopage.cgi?orf=LOC_Os03g43590), [Os03g0636800](https://rapdb.dna.affrc.go.jp/locus/?name=Os03g0636800).
    + OsNek2, [LOC_Os12g41180](http://rice.uga.edu/cgi-bin/ORF_infopage.cgi?orf=LOC_Os12g41180), [Os12g0604700](https://rapdb.dna.affrc.go.jp/locus/?name=Os12g0604700).
    + OsNek4, [LOC_Os05g36960](http://rice.uga.edu/cgi-bin/ORF_infopage.cgi?orf=LOC_Os05g36960), [Os05g0440800](https://rapdb.dna.affrc.go.jp/locus/?name=Os05g0440800).
    + OsNek5, [LOC_Os01g64490](http://rice.uga.edu/cgi-bin/ORF_infopage.cgi?orf=LOC_Os01g64490), [Os01g0864700](https://rapdb.dna.affrc.go.jp/locus/?name=Os01g0864700).
    + OsNek6, [LOC_Os02g37830](http://rice.uga.edu/cgi-bin/ORF_infopage.cgi?orf=LOC_Os02g37830), [Os02g0590800](https://rapdb.dna.affrc.go.jp/locus/?name=Os02g0590800).

* **Publication**
    + [Members of the plant NIMA-related kinases are involved in organ development and vascularization in poplar, Arabidopsis and rice.](http://www.ncbi.nlm.nih.gov/pubmed?term=Members of the plant NIMA-related kinases are involved in organ development and vascularization in poplar, Arabidopsis and rice.%5BTitle%5D), 2007, Plant J..
    + [Cytoplasmic male sterility-related protein kinase, OsNek3, is regulated downstream of mitochondrial protein phosphatase 2C, DCW11.](http://www.ncbi.nlm.nih.gov/pubmed?term=Cytoplasmic male sterility-related protein kinase, OsNek3, is regulated downstream of mitochondrial protein phosphatase 2C, DCW11.%5BTitle%5D), 2009, Plant Cell Physiol..
    + [OsDIS1-mediated stress response pathway in rice.](http://www.ncbi.nlm.nih.gov/pubmed?term=OsDIS1-mediated stress response pathway in rice.%5BTitle%5D), 2011, Plant Signal Behav.
    + [The SINA E3 ligase OsDIS1 Negatively Regulates Drought Response in Rice.](http://www.ncbi.nlm.nih.gov/pubmed?term=The SINA E3 ligase OsDIS1 Negatively Regulates Drought Response in Rice.%5BTitle%5D), 2011, Plant Physiol..


text:
---
title: Transaction Weight
---

A number of resources in any chain can be limited, such as storage or computation. Weights exist to
prevent individual components of the chain from consuming too much of any resource.

Consuming some weights should generally incur a fee. The fee implications of the weight system are
covered in the [Fee Developer document](development/module/fees.md).

## Weight Fundamentals

Weights represent the _limited_ resources of your blockchain, for example computational cycles,
memory, storage, etc. A custom implementation may use complex structures to express this. Substrate
weights are simply a [numeric value](https://substrate.dev/rustdocs/master/palette_support/weights/type.Weight.html).

A weight calculation should always:

- Be computable __ahead of dispatch__. A block producer should be able to examine the weight of a
  dispatchable before actually deciding to accept it or not.
- Consume few resources itself. It does not make sense to consume similar resources computing a
  transaction's weight as would be spent to execute it. Thus, weight computation should be much
  lighter than dispatch.
- Delegate _variable_ resource consumption costs and limitations to the dispatched logic. Weights
  are good at representing _fixed_ measurements, whereas logic may not be consistently heavy. The
  implementation of the dispatch should take the state of the change into account and manually take
  extra fees or bonds or take any other measures to make sure that the transaction is safe.

The [System module](https://substrate.dev/rustdocs/master/palette_system/struct.Module.html) is
responsible for accumulating the weight of each block as it gets executed and making sure that it
does not exceed the limit. The [Transaction Payment
module](https://substrate.dev/rustdocs/master/pallet_transaction_payment/index.html) is responsible
for interpreting these weights and deducting fees based upon them. The weighing function is part of
the runtime so it can be upgraded if needed.

## Block Weight and Length Limit

Aside from affecting fees, the main purpose of the weight system is to prevent a block from being
filled with too many transactions. While processing transactions within a block, the System module
accumulates both the total length of the block (sum of encoded transactions in bytes) and the total
weight of the block. If either of these numbers surpass the limits, no further transactions are
accepted in that block. These limits are defined in
[`MaximumBlockLength`](https://substrate.dev/rustdocs/master/palette_system/trait.Trait.html#associatedtype.MaximumBlockLength)
and
[`MaximumBlockWeight`](https://substrate.dev/rustdocs/master/palette_system/trait.Trait.html#associatedtype.MaximumBlockLength).

One important note about these limits is that a portion of them are reserved for the `Operational`
dispatch class. This rule applies to both of the limits and the ratio can be found in
[`AvailableBlockRatio`](https://substrate.dev/rustdocs/master/palette_system/trait.Trait.html#associatedtype.AvailableBlockRatio).

For example, if the block length limit is 1 megabyte and the ratio is set to 80%, all transactions
can fill the first 800 kilobytes of the block while the last 200 can only be filled by the
operational class.

## Next Steps

### Learn More

- Substrate Recipes contains examples of both [custom
  weights](https://github.com/substrate-developer-hub/recipes/tree/master/kitchen/modules/weights)
  and custom
  [WeightToFee](https://github.com/substrate-developer-hub/recipes/tree/master/kitchen/runtimes/weight-fee-runtime).
- The [srml-example](https://github.com/paritytech/substrate/blob/master/palette/example/src/lib.rs)
  module.

### Examples

- See an example of [adding a transaction
  weight](https://substrate.dev/recipes/design/econsecurity.html?highlight=weight#assigning-transaction-weights)
  to a custom runtime function.

### References

- Take a look at the [SRML Transaction Payment
  module](https://github.com/paritytech/substrate/blob/master/palette/transaction-payment/src/lib.rs).
- Find info about weights including the `SimpleDispatchInfo` enum in
  [weights.rs](https://github.com/paritytech/substrate/blob/master/primitives/sr-primitives/src/weights.rs).

branch_name: refs/heads/source


text:
# MoneyStack

This is a library to assist with currency related math. It helps with some of the precision issues that come from floating point math. All values are limited to a given percison, anything after will be truncated.

_This is a prealpha state and should be considered unstable. Use with extreme caution._

## Usage

```
cd {your-project}
npm install git://github.com/onebytegone/MoneyStack.git#0.0.1 --save
```

## Development

### Install Dependencies

```
npm install
```

### Create minified version

```
npm run build
```

### Run unit tests

```
npm run test
```

## Changelog

  * v0.0.1 - Initial release

repository: onebytegone/MoneyStack

repo_name: onebytegone/MoneyStack


text:
# BlueRange in Docker

This docker compose script starts one BlueRange instance, MySQL and MongoDB databases, an nginx frontend proxy, a Mosquitto MQTT broker and a Node Red instance.

The volumes `mysql` and `mongodb` are set up in order not to lose data stored when the nodes are rebuild.

## Hosted service ports

The following ports are available on the hosting machine:

- 443: HTTPS of `nginx`
- 1880: Node Red HTTP service of `nodered`
- 1883: MQTT using TCP of `mosquitto`, bound to docker host only
- 3306: MySQL service of `database`, bound to docker host only
- 8080: BlueRange UI of `bluerange`, bound to docker host only
- 8099: Spring Actuators of `bluerange`, bound to docker host only
- 8883: MQTT using SSL of `mosquitto`
- 9001: MQTT over WebSockets of `mosquitto`
- 27017: MongoDB service of `mongodb`, bound to docker host only

Ports not required for operation but for diagnostics only are bound to the docker host only. All port mappings may be customized by overwriting them in the `server.env` file. The names of those custom port mappings can be looked up in [.env](.env) and are prefixed by `PORT_`.

## Required configuration

The compose scripts expect that the following files are provided:

- `server.env`: environment variable file containing the host machine name as registered in DNS and mail server configuration
- `server.pem`: certificate used for HTTPS which must match the host machine name registered with DNS
- `server.key`: private key for issuing the HTTPS certificate
- `ca.pem`: additional CA certificate(s) used for signing the `server.pem` so that all of those PEMs form a full chain of trust

The `server.env` file should look like this:

```env
HOST=my-machine.my-domain.me
SMTP_HOST=smtp-machine.my-domain.me
SMTP_PORT=25
SMTP_USERNAME=smtp-username
SMTP_PASSWORD=XXXXXXXX
```

The HTTPS certificate required may be generated using <https://letsencrypt.org/>. Please make sure to have a property DNS record set up for your workstation.

In case no HTTPS certificate is found the [bluerange-compose.sh](bluerange-compose.sh) script will set up a certificate authority interactively. Secure connections using this mechanism require installation of the `ca.pem` file created as a trusted CA onto all IoT gateways, mobile and browser clients.

## Optional configuration

The [docker-compose.yml](docker-compose.yml) contains commented sections for running `nginx` in debug mode and for mounting a custom `mosquitto.conf` file, see <https://hub.docker.com/r/relution/relution-mosquitto>.

## Appliance configuration

The configuration offers a fully functioning BlueRange server environment suitable for production as well as for testing and/or development purposes. The logging and update servers are included as well.

In case a logging server such as an ELK installation exists in the IT infrastructure hosting BlueRange already it should be reused. As update server the publically available cloud service of M-Way Solutions GmbH may be used as well.

### BlueRange software stack

To help getting started with a fully self-administered on-premise setup including all of BlueRange, logging and update servers the entire software stack can be started at once:

```sh
# start all-in-one BlueRange software stack
$ ./bluerange-compose.sh

Starting bluerange_database_1  ... done
Starting bluerange_bluerange_1 ... done
Starting bluerange_mosquitto_1 ... done
Starting bluerange_nodered_1   ... done
Starting bluerange_nginx_1     ... done
...

mender-useradm$ useradm create-user<EMAIL_ADDRESS>--password=admin123
4f091170-da1a-11e9-aaef-0800200c9a66

    BlueRange: https://my-machine.my-domain.me:443  (admin / admin123)
       Mender: https://my-machine.my-domain.me:444<EMAIL_ADDRESS>/ admin123)
       Kibana: https://my-machine.my-domain.me:5602 (admin / admin)
ElasticSearch: https://my-machine.my-domain.me:9201 (admin / admin)
```

> ℹ The Mender, NodeRED, ElasticSearch logging and Prometheus monitoring services are optionally started depending on the [profiles](https://docs.docker.com/compose/profiles/) activated by setting `COMPOSE_PROFILES` in `server.env`.

Notice, the [bluerange-compose.sh](bluerange-compose.sh) script can be used just like `docker-compose`:

```sh
# display all logs with follow
$ ./bluerange-compose.sh logs -f

# stop all-in-one BlueRange software stack
$ ./bluerange-compose.sh down
```

Further customization should be done using the `docker-compose.override.yml` mechanism, see <https://docs.docker.com/compose/extends/>.

### Monitoring server

The file [docker-compose.monitoring.yml](docker-compose.monitoring.yml) contains services supporting [Prometheus](https://prometheus.io/) monitoring and [Grafana](https://grafana.com/) visualization.

> ℹ The optional Prometheus monitoring services are enabled by specifying `COMPOSE_PROFILES=monitoring` in `server.env`.

Mesh gateway devices support pushing metrics to the [Graphite](https://graphiteapp.org/) service when installing a configuration policy via the platform.

### Logging server

The file [docker-compose.elasticsearch.yml](docker-compose.elasticsearch.yml) contains an ElasticSearch stack, based on [Open Distro for Elasticsearch](https://opendistro.github.io/for-elasticsearch/).

> ℹ The optional ElasticSearch logging services are enabled by specifying `COMPOSE_PROFILES=elasticsearch` in `server.env`.

In order to let the mesh gateway devices know about the custom logging server, a configuration policy must be applied in the platform.

### Update server

Likewise the file [docker-compose.mender.yml](docker-compose.mender.yml) contains the setup required to start a dedicated update server.

> ℹ The optional Mender update services are enabled by specifying `COMPOSE_PROFILES=mender` in `server.env`.

Once started the update server is available via HTTPS at port 444, i.e. <https://my-machine.my-domain.me:444>. In order to log into the server an initial user account is created by `bluerange-compose.sh` automatically. Additional users may be registered interactively in the Mender UI or like this:

```sh
# create user<EMAIL_ADDRESS>$ ./bluerange-compose.sh exec -T mender-useradm useradm create-user<EMAIL_ADDRESS>--password=admin123
```

In order to let the mesh gateway devices know about the custom update server, a configuration policy must be applied in the platform.

## Backup and Restore

The script `bluerange-backup.sh` allows saving the database content and server configuration into a single file:

```sh
$ ./bluerange-backup.sh
...
* backup/bluerange-20210421_132111.tar.gz
```

The backup file can be uploaded to some permanent storage such as S3. The script is intended to run regularly using cron, for example.

The `bluerange-restore.sh` script allows restoring the installation given a fresh working copy:

```sh
$ ./bluerange-restore.sh backup/bluerange-20210421_132111.tar.gz
All existing BlueRange server data will be erased!
Are you sure to restore from bluerange-20210421_132111?
Type YES: YES
...
Backup bluerange-20210421_132111 restored.
* ./bluerange-compose.sh to start the server...
```

Finally start the server using `bluerange-compose.sh` once so that the system services are installed.

## Beacons and the Mesh Gateway

By default, the environment is set up automatically creating an organization named `IOT`. It is expected to enroll IoT things therein. To log on use username `admin` and password `iot12345`.

Start by creating a Site, enrolling a Mesh Gateway and positioning some Beacons... or have a look at the manual at <https://www.bluerange.io/docs/master/iot_development.html> to get going.

## Node RED and MQTT

> ℹ The optional Node RED service is enabled by specifying `COMPOSE_PROFILES=nodered` in `server.env`.

The Node RED instance can be accessed through nginx at <https://my-machine.my-domain.me/nodered> specifying username `iot` and password `mway1234` as credentials. Additional users can be added using the command `htpasswd htpasswd ${username}`. On Cent OS 7 the tool can be installed using `yum install httpd-tools`. For further information see [Restricting Access with HTTP Basic Authentication](https://docs.nginx.com/nginx/admin-guide/security-controls/configuring-http-basic-authentication/).

**At the time of writing only the System/Organization Administrator accounts are allowed to send messages to MQTT.** Other users connecting to MQTT using access tokens are granted read-only access to their respective organization only. Any attempt violating security restrictions may cause immediate disconnection!

### To get credentials for connecting Node RED to the `mosquitto` broker...

The values required for authentication are specific to each installation. It is not possible to write them down here, but this is how to obtain the information required:

1. Log on to BlueRange <https://my-machine.my-domain.me> with username `admin` and password `iot12345`.
2. Go to `Settings/Organization` and then the details of `IOT`. Now, in the browser address bar there is the UUID of the IOT Organization displayed. Write down the *iot-organization-uuid*.
3. Go to `Settings/Users` and then the details of `admin` of the `IOT` organization. Now, the address bar shows the UUID of the IOT Administrator. Write it down as *iot-administrator-uuid*.
4. In the menu please go to `IOT Administrator/Profile` and then tab `Access Tokens`.
5. Create an Access Token giving it a name at your discretion, ideally `nodered`. Write down your *iot-access-token-secret*.

Information required for setting up the connection are:

- server: `mosquitto`
- port: `1883`
- username: `Token-`*iot-administrator-uuid*`-nodered`
- password: *iot-access-token-secret*
- topic: `rltn-iot/`*iot-organization-uuid*`/#`

### An example flow that can be imported...

```javascript
[
    {
        "id": "38d59f86.19688",
        "type": "mqtt in",
        "z": "e648d23d.3bddc",
        "name": "",
        "topic": "rltn-iot/${iot-organization-uuid}/#",
        "qos": "0",
        "broker": "21e63dd2.d444f2",
        "x": 260,
        "y": 60,
        "wires": [
            [
                "c1f6d91e.5e1768"
            ]
        ]
    },
    {
        "id": "c1f6d91e.5e1768",
        "type": "debug",
        "z": "e648d23d.3bddc",
        "name": "",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "payload",
        "x": 590,
        "y": 60,
        "wires": []
    },
    {
        "id": "21e63dd2.d444f2",
        "type": "mqtt-broker",
        "z": "",
        "name": "mosquitto",
        "broker": "mosquitto",
        "port": "1883",
        "clientid": "",
        "usetls": false,
        "compatmode": true,
        "keepalive": "60",
        "cleansession": true,
        "willTopic": "",
        "willQos": "0",
        "willPayload": "",
        "birthTopic": "",
        "birthQos": "0",
        "birthPayload": "",
        "username": "Token-${iot administrator uuid}-nodered",
        "password": "${iot-access-token-secret}"
    }
]
```

Make sure to replace the `${iot-organization-uuid}`, `${iot administrator uuid}` and `${iot-access-token-secret}`. Notice, alternatively you may connect to `my-machine.my-domain.me`, port `8884` with `usetls`.

### Connecting `MQTT.fx` for sending arbitrary messages...

To connect [MQTT.fx](http://mqttfx.jensd.de/) to act as System Administrator to `mosquitto` please obtain credentials as:

1. Log on to BlueRange <https://my-machine.my-domain.me> with username `admin` and password `admin123`.
2. Go to `Settings/Users` and then the details of `admin` of the `SYSTEM` organization. Now, the address bar shows the UUID of the IOT Administrator. Write it down as *system-administrator-uuid*.
3. In the menu please go to `(?)/Web API`.
4. Open path `users` and operation `POST /gofer/security/rest/users/{userUuid}/accessTokens`.
5. Press `Try it out`.
6. Enter the *system-administrator-uuid* value for `userUuid` path parameter.
7. Enter the JSON `{"name": "MQTT.fx"}` as `accessToken` body parameter.
8. Click `Execute` exactly **once**.
9. Write down the `token` value of the response JSON body as *access-token-secret*.
10. Create an Access Token giving it a name at your discretion, ideally `nodered`. Write down your *system-access-token-secret*.

Information required for setting up the connection are:

- server: `my-machine.my-domain.me`
- port: `8884`
- username: `Token-`*system-administrator-uuid*`-nodered`
- password: *system-access-token-secret*

You need to enable SSL/TLS security.

When publishing messages keep in mind that Node RED is subscribed to `rltn-iot/`*iot-organization-uuid*`/#` so that only messages below this topic path are delivered to it.

# Questions & Answers

## What format the HTTPS private key must be stored in?

The compose scripts assume the `server.key` is in PKCS#8 format like so:

```
<REDACTED_PRIVATE_KEY>
```

Files starting with `-----BEGIN RSA PRIVATE KEY-----` must be converted using the command:

```sh
$ openssl pkcs8 -topk8 -inform PEM -in server.rsa -out server.key -nocrypt
```

repository: bluerange-io/bluerange-setup

gha_language: Shell

repo_name: bluerange-io/bluerange-setup


text:
NES/SNES 240p de-jitter mod
==============

snes_dejitter is a mod board which eliminates sync jitter of NES/SNES 240p modes. Technical description and discussion is found on [this](https://shmups.system11.org/viewtopic.php?f=6&t=61285) thread.

Requirements for building the board and CPLD firmware
--------------------------------------------------------
* Hardware
  * [PCB](https://oshpark.com/shared_projects/XwqVt6Gq) + [parts](pcb/bom/snes_dejitter.ods)

* Software
  * [Altera Quartus II version 13.0sp1 with MAX7000 support](http://dl.altera.com/13.0sp1/?edition=web)
  * [pof2jed](http://www.microchip.com/design-centers/programmable-logic/spld-cpld/tools/software/pof2jed) conversion tool
  * [ATMISP](http://www.microchip.com/design-centers/programmable-logic/spld-cpld/tools/software/atmisp) software
  * [WINE](https://www.winehq.org/) (if Windows OS is not used)

Requirements for flashing CPLD firmware
--------------------------------------------------------
* Hardware
  * OpenOCD supported JTAG programmer (e.g. FT2232 based)

* Software
  * [OpenOCD](http://openocd.org/)
  * Telnet client

CPLD image build procedure
--------------------------------------------------------
1. Open the project file in Quartus, and run compilation

2. Convert MAX7000 targeted POF object file into JEDEC file suitable for 1502AS via winpof2jed.exe:
~~~~
1. Select .pof file from previous step as input file
2. Select 1502AS as device
3. Set Open Collector to "Off", and JTAG mode to "On"
4. Click "Run"
~~~~
![pof2jed](/pics/pof2jed.png)

3. Convert JED to SVF via ATMISP:
~~~~
1. Create a new device chain via File->New
2. Set number of devices to 1
3. Set device to ATF1502AS
4. Set JTAG instruction to "Program/Verify"
5. Select .jed file from previous step as JEDEC file
6. Click "OK"
7. Tick "Write SVF file" and click "Run"
~~~~
![atmisp1](/pics/atmisp_chain.png)
![atmisp1](/pics/atmisp_setup.png)

Board flashing
--------------------------------------------------------
The board can be flashed using any OpenOCD supported JTAG programmer that provides 3.3V-5V IO signal level. A standalone snes_jitter board is flashed by hooking all of its 6 JTAG header pins to respective pins of the programmer/cable, and by running flash procedure specified below. After the board has been installed to NES/SNES, firmware can be subsequently updated, but in this method 5V pin of the JTAG connector MUST be left disconnected, and programming needs to be done while NES/SNES is powered on (without a game is ok). The update procedure is similar in both cases:

1. Create openocd.conf that matches your JTAG programmer. A configuration file for FT2232-based programmers is found in installation/openocd-ft2232.conf, and it uses following standard pinout for data signals:

Board pin | Programmer pin
--------- | -------------
TCK       | ADBUS0
TMS       | ADBUS3
TDI       | ADBUS1
TDO       | ADBUS2

2. After hooking up JTAG cable, initiate JTAG connection:
~~~~
openocd -f openocd.conf
~~~~
3. OpenOCD auto-probing should report a TAP controller with id 0x0150203f. You can now open another terminal to interact with openocd and program the chip:
~~~~
telnet localhost 4444
> svf <full_path_to_svf_file>
~~~~
4. The programming procedure should finish with no error, after which you can finish installation by powering off hardware and disconnecting the programmer.

Installation
--------------------------------------------------------
General descriptions on board pins are in table below. Model-specific installation instructions are added to separate subdirectories.

Board pin  | Description
---------- | -------------
CSYNC_i    | TTL C-sync signal from the console
MCLK_EXT_i | External clock input. Used only in PAL mode, not needed in pure NTSC installations.
CLK_SEL_i  | Master clock source selection (0=internal/NTSC, 1=external/PAL). In PAL mode, MCLK and CSYNC are bypassed to output. Pin is pulled low internally, so it can be left disconnected in pure NTSC installations. Connected to PALMODE in multiregion installations. Can be forced high by bridging JP1 (pre-1.2 boards only), but must never be done if the pin is wired to console.
MCLK_o     | Clock output. See model-specific instructions on voltage divider (R13,R14 / JP2) requirement.
CSYNC_o    | C-sync output (~2.5Vpp unterminated, ~1.1Vpp to 75ohm termination) to an isolated multi-AV pin. Driver circuit is identical to SHVC-CPU-01.


text:
# Sentiance SDK Starter Swift
A simple single-view application that uses the Sentiance SDK inside a Swift project.

Steps applied: [Sentiance iOS SDK docs](https://developers.sentiance.com/docs)

## To run this project:
1.  Clone this repository
2.  Download and extract the latest framwork file from the [sentiance ios sdk docs](https://developers.sentiance.com/docs/sdk/ios/integration#include-sdk)
3.  Place the extracted framework in the repository root path
4.  [Create a developer account here](https://developers.sentiance.com/)
5.  [Register a Sentiance application here](https://developers.sentiance.com/apps) to obtain an application ID and secret
6.  `open SDKStarter.xcodeproj`
7.  In `SDKStarter/AppDelegate.swift`: replace `YOUR_APP_ID` and `YOUR_APP_SECRET` with the credentials from the application you added in step 5.
8.  Clean, build and run the application on your device

## More info
- [Full documentation on the Sentiance SDK](https://developers.sentiance.com/docs)
- [Developer signup](https://developers.sentiance.com/)

repository: sentiance/sdk-starter-swift

gha_language: Swift

repo_name: sentiance/sdk-starter-swift


text:
Basic info:
- Book called 'Terraform: Up and Running' https://www.terraformupandrunning.com/
- https://learn.hashicorp.com

Quick Start:
- https://learn.hashicorp.com/terraform (~10 hours each module)

Guide with best practices from Gruntwork:
- https://blog.gruntwork.io/a-comprehensive-guide-to-terraform-b3d32832baca

Courses:
- https://www.udemy.com/course/learn-devops-infrastructure-automation-with-terraform/
- terraform aws  https://github.com/wardviaene/terraform-course
- terraform azure  https://github.com/in4it/terraform-azure-course

Terraform state:
- https://blog.gruntwork.io/how-to-manage-terraform-state-28f5697e68fa (mainly on using AWS backend provider)

repository: vadimisakanov/open-infrastructure

repo_name: vadimisakanov/open-infrastructure


text:
# Eutrema yungshunense (W.T.Wang) Al-Shehbaz & Warwick SPECIES

#### Status
ACCEPTED

#### According to
International Plant Names Index

#### Published in
null

#### Original name
Cardamine yungshunensis W.T. Wang

### Remarks
null

repository: mdoering/backbone

repo_name: mdoering/backbone


text:
---
layout:       post
title:        Doors
class:       "cart"
date:         2015-11-24T17:52:48+11:00
description: "Building Components: Doors"
categories:
image:
---

**Identity**

{% include building-components/table-layout-block.markdown letter="B" key="building-components/doors/00-key.markdown" value="building-components/doors/00-value.markdown" %}
{% include building-components/table-layout-text.markdown image="building-components/doors/00-image.markdown" %}

**Describe** Door assemblies and finishes

{% include building-components/table-layout-block.markdown letter="J" key="building-components/doors/01-key.markdown" value="building-components/doors/01-value.markdown" %}
{% include building-components/table-layout-image.markdown image="building-components/doors/01-image.svg" %}

{% include building-components/table-layout-block.markdown letter=" " key="building-components/doors/02-key.markdown" value="building-components/doors/02-value.markdown"  %}
{% include building-components/table-layout-image.markdown image="building-components/doors/02-image.svg" %}

{% include building-components/table-layout-block.markdown letter=" " key="building-components/doors/03-key.markdown" value="building-components/doors/03-value.markdown"  %}
{% include building-components/table-layout-image.markdown image="building-components/doors/03-image.svg" %}

{% include building-components/table-layout-block.markdown letter=" " key="building-components/doors/04-key.markdown" value="building-components/doors/04-value.markdown"  %}
{% include building-components/table-layout-image.markdown image="building-components/doors/04-image.svg" %}

{% include building-components/table-layout-block.markdown letter="K" key="building-components/doors/05-key.markdown" value="building-components/doors/05-value.markdown"  %}
{% include building-components/table-layout-image.markdown image="building-components/doors/05-image.svg" %}

{% include building-components/table-layout-block.markdown letter="Z" key="building-components/doors/06-key.markdown" value="building-components/doors/06-value.markdown"  %}
{% include building-components/table-layout-image.markdown image="building-components/specifications-image.svg" %}

{% include building-components/table-layout-block.markdown letter=" " key="building-components/doors/07-key.markdown" value="building-components/doors/07-value.markdown"  %}
{% include building-components/table-layout-text.markdown image="building-components/doors/07-text.markdown" %}

**Describe** External doors

{% include building-components/table-layout-block.markdown letter="A" key="building-components/doors/08-key.markdown" value="building-components/doors/08-value.markdown"  %}
{% include building-components/table-layout-image.markdown image="building-components/doors/08-image.svg" %}

{% include building-components/table-layout-block.markdown letter="J" key="building-components/doors/09-key.markdown" value="building-components/doors/09-value.markdown"  %}
{% include building-components/table-layout-image.markdown image="building-components/doors/09-image.svg" %}

{% include building-components/table-layout-block.markdown letter="B" key="building-components/doors/10-key.markdown" value="building-components/doors/10-value.markdown"  %}
{% include building-components/table-layout-image.markdown image="building-components/doors/10-image.svg" %}

{% include building-components/table-layout-block.markdown letter="C" key="building-components/doors/11-key.markdown" value="building-components/doors/11-value.markdown"  %}
{% include building-components/table-layout-image.markdown image="building-components/doors/11-image.svg" %}

{% include building-components/table-layout-block.markdown letter="C" key="building-components/doors/12-key.markdown" value="building-components/doors/12-value.markdown"  %}
{% include building-components/table-layout-image.markdown image="building-components/doors/12-image.svg" %}

{% include building-components/table-layout-block.markdown letter="Z" key="building-components/doors/13-key.markdown" value="building-components/doors/13-value.markdown"  %}
{% include building-components/table-layout-image.markdown image="building-components/specifications-image.svg" %}

repository: BaptisteHiggs/styleguide

extension: markdown

repo_name: BaptisteHiggs/styleguide


text:
[![Dil-se-Dosti](https://telegra.ph/file/5c38e2df8dd48b7c89067.jpg)](https://t.me/Tg_Error_404)

  🇳🇪 Official-Dil-se-Dosti-music-bot🇳🇪

⚡DEPLOY⚡

## Deploy to Heroku

[![Deploy](https://www.herokucdn.com/deploy/button.svg)](https://dashboard.heroku.com/new?button-url=https%3A%2F%2Fgithub.com%2FPushpendra6367%2FOFFICIAL-DIL-SE-DOSTI-MUSIC-BOT%2Fblob%2Fmaster%2FREADME.md&template=https%3A%2F%2Fgithub.com%2FPushpendra6367%2FOFFICIAL-DIL-SE-DOSTI-MUSIC-BOT)

string_session

Generate From here

 [![GenerateStringName](https://img.shields.io/badge/repl.it-generateStringName-yellowgreen)](https://replit.com/@XDDeepak/DilseDosti?v=1)

license

(C) @XD-Deepak
Copyright permission under MIT License
License -> https://github.com/XD-Deepak/OFFICIAL-DIL-SE-DOSTI-MUSIC-BOT/blob/master/LICENSE

NOTE: Make sure you have started a VoiceChat in your Group before deploying.

VARS

1. `API_ID` : Get From my.telegram.org
2. `API_HASH` : Get from my.telegram.org
3. `BOT_TOKEN` : @Botfather
4. `SESSION_STRING` : Generate From here [![GenerateStringName](https://img.shields.io/badge/repl.it-generateStringName-yellowgreen)](https://replit.com/@XDDeepak/DilseDosti?v=1)
5. `CHAT` : ID of Channel/Group where the bot plays Music.
6. `LOG_GROUP` : Group to send Playlist, if CHAT is a Group
7. `ADMINS` : ID of users who can use admin commands.
8. `ARQ_API` : Get it for free from [@ARQRobot](https://telegram.dog/ARQRobot), This is required for /dplay to work.
9. `STREAM_URL` : Stream URL of radio station or a youtube live video to stream when the bot starts or with /radio command.
10. `MAXIMUM_DURATION` : Maximum duration of song to play.(Optional)
11. `REPLY_MESSAGE` : A reply to those who message the USER account in PM. Leave it blank if you do not need this feature.
12. `ADMIN_ONLY` : Pass `Y` If you want to make /play and /dplay commands only for admins of `CHAT`. By default /play and /dplay is available for all.

- Enable the worker after deploy the project to Heroku
- Bot will starts radio automatically in given `CHAT` with given `STREAM_URL` after deploy.(24*7 Music even if heroku restarts, radio stream restarts automatically.)
- To play a song use /play as a reply to audio file or a youtube link.
- Use /play <song name> to play song from youtube and /dplay <song name> to play from Deezer.
- Use /help to know about other commands.

FEATURES

- Playlist, queue
- Supports Live streaming from youtube
- Supports both deezer and youtube to search songs.
- Play from telegram file supported.
- Starts Radio after if no songs in playlist.
- Automatically downloads audio for the first two tracks in the playlist to ensure smooth playing
- Automatic restart even if heroku restarts.


text:
# Using the build scripts

Most of our build scripts are docker-based.
(All, except the macOS build, which is a separate beast and always has to be special-cased
at the cost of significant maintenance burden...)

Typically, the build flow is:

- build a docker image, based on debian
  - the apt sources mirror used is `snapshot.debian.org`
    - (except for the source tarball build, which is simple enough not to need this)
    - this helps with historical reproducibility
    - note that `snapshot.debian.org` is often slow and sometimes keeps timing out :/
      (see #8496)
      - a potential alternative would be `snapshot.notset.fr`, but that mirror is missing
        e.g. `binary-i386`, which is needed for the wine/windows build.
    - if you are just trying to build for yourself and don't need reproducibility,
      you can just switch back to the default debian apt sources mirror.
  - docker caches the build (locally), and so this step only needs to be rerun
    if we update the Dockerfile. This caching happens automatically and by default.
    - you can disable the caching by setting envvar `ELECBUILD_NOCACHE=1`. See below.
- create a docker container from the image, and build the final binary inside the container

## Notes about using Docker

- To install Docker:

    This assumes an Ubuntu (x86_64) host, but it should not be too hard to adapt to another similar system.

    ```
    $ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
    $ sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
    $ sudo apt-get update
    $ sudo apt-get install -y docker-ce
    ```

- To communicate with the docker daemon, the build scripts either need to be called via sudo,
  or the unix user on the host system (e.g. the user you run as) needs to be
  part of the `docker` group. i.e.:
  ```
  $ sudo usermod -aG docker ${USER}
  ```
  (and then reboot or similar for it to take effect)

## Environment variables

- `ELECBUILD_COMMIT`

    When unset or empty, we build directly from the local git clone. These builds
    are *not* reproducible.

    When non-empty, it should be set to a git ref. We will create a fresh git clone
    checked out at that reference in `/tmp/electrum_build/`, and build there.

- `ELECBUILD_NOCACHE=1`

    A non-empty value forces a rebuild of the docker image.

    Before we started using `snapshot.debian.org` for apt sources,
    setting this was necessary to properly test historical reproducibility.
    (we were version-pinning packages installed using `apt`, but it was not realistic to
     version-pin all transitive dependencies, and sometimes an update of those resulted in
     changes to our binary builds)

    I think setting this is no longer necessary for building reproducibly.

repository: spesmilo/electrum

gha_language: Python

repo_name: spesmilo/electrum


text:
# Wood Species Classification Using Vibration Signature

Acquire live data from NI data acquisition hardware in MATLAB using the Data Acquisition Toolbox and use the Deep Learning Toolbox to classify 3 different wood species (Mexican Ebony, Hard Maple and Bloodwood) based on vibrational characteristics.
This demo also uses the Wavelet Toolbox to compute continuous wavelet transform (CWT) images of the live acquired data samples. The CWT images were used to train our CNN model.

![](images/classificationGui.png)

## Wood Species

The convolution neural network (CNN) was trained on vibrational data samples acquired from 3 different varieties of wood species known as:

* Mexican Ebony
* Hard Maple
* Bloodwood

![](images/woodSpecies.PNG)

## Hardware Setup

Configure the hardware - Connect NI 9234 data acquisition module with the impact hammer and accelerometers as follows:

* Channel 0 - PCB 086C03 Impact Hammer
* Channel 1 - PCB 352C65 Accelerometer
* Channel 2 - PCB 352C65 Accelerometer
* Channel 3 - PCB 352C65 Accelerometer

Mount the 3 accelerometers on separate wood species blocks (Mexican Ebony, Hard Maple and Bloodwood).

![](images/hardwareSetup.png)

## Data Acquisition

Data Acquisition Toolbox was used to acquire vibrational signals from NI 9234 DAQ module. Data Acquisition Toolbox provides functions for configuring data acquisition hardware and reading data into MATLAB for analysis.
The toolbox supports a variety of DAQ hardware, including USB, PCI, PCI Express®, PXI®, and PXI-Express devices, from National Instruments™ and other vendors.

![](images/overviewDiag.PNG)

Thse following link provides more information about the Data Acquisition Toolbox:

https://www.mathworks.com/products/data-acquisition.html

## Signal Processing

Vibrational data from the accelerometers mounted on wood blocks was acquired using NI 9234 DAQ module in MATLAB. Signal samples were analyzed and preprocessed in MATLAB. Continuous Wavelet Transforms (CWT) were used
to generate the 2-D time-frequency maps of time series data. These time-frequency maps were used as inputs for the deep convolutional neural network (CNN). The ability of the CWT to simultaneously capture steady-state
and transient signal behavior in time series data makes the wavelet-based time-frequency representation particularly robust when paired with deep CNNs.

![](/images/waveletImage.PNG)

For more information about Wavelet Transforms and time-frequency analysis, visit the following link:

https://www.mathworks.com/help/wavelet/time-frequency-analysis.html

## Goal

* Configure Hardware
* Strike wood block with the impact hammer
* Accelerometer captures wood specific vibrational data
* Classification model predicts the type of wood based on impact

## Demo Video

This demo was showcased in MathWorks/NI virtual event. The name of the session was - Data Acquisition and Machine Learning Using MathWorks and NI Tools.
The session provides insights into a typical machine learning workflow and how one can use machine learning to classify materials followed by a live demo showcase.
Link for the virtual session:

https://gateway.on24.com/wcc/eh/2429684/lp/2748276/data-acquisition-and-machine-learning-using-mathworks-and-ni-tools

## Demo Setup

* From a list of MATLAB files in the 'wood classification demo' folder, open and run the demoSetup.m script in MATLAB. This script clears everything in MATLAB editor and sets it up for running the demo.
* To start the demo, please run the startDaq.m script.

[![View Wood-Species-Classification-Using-Vibration-Signature on File Exchange](https://www.mathworks.com/matlabcentral/images/matlab-file-exchange.svg)](https://www.mathworks.com/matlabcentral/fileexchange/89248-wood-species-classification-using-vibration-signature)

Copyright 2021 The MathWorks, Inc.


text:
---
title: Apply for Public Entertainment Licence
permalink: /browse-all-licences/Singapore-Police-Force-(SPF)/Apply-for-Public-Entertainment-Licence
third_nav_title: Singapore Police Force (SPF)
---

## Apply for Public Entertainment Licence

Singapore Police Force (SPF)

{% include button.html text="Apply on GoBusiness Licensing" src="https://licence1.business.gov.sg/feportal/web/frontier/eAdvisor?redirection=true&selectedLicenceIds=50" type="primary" %}

Application Details

Unless exempted, a public entertainment or arts entertainment licence is required under the Public Entertainments (PEA) Act 1958, for any entertainment that is provided in any place to which the public or any class of public has access, whether gratuitously or otherwise. Any person who provides or assists in providing any public entertainment without a license shall be liable on conviction to a fine not exceeding $10,000.

Refer to the SPF's list of exclusions before you apply.

FAQ

    Where can I get more information for Public Entertainment Licence?

More information can be found at the
SPF website

    Who can be an applicant?

If you have just updated ACRA for any changes related to your Company's name or staff listing, Please allow for at least a day before you submit any application in LicenceOne with relation to these changes. This waiting time is required to get the updates synced for LicenceOne system verification.

Entity Type:

Limited Liability Partnership

Eligibility Criteria:

Applicant must be having position:

* PARTNER cum MANAGER

Entity Type:

Company

Eligibility Criteria:

Applicant must be having one of the following position:

* MANAGING DIRECTOR

* SECRETARY

* DIRECTOR

* CHIEF EXECUTIVE OFFICER

Entity Type:

Business (Sole Proprietor/Partnership)

Eligibility Criteria:

Applicant must be having one of the following position:

* OWNER

* AUTHORIZED REPRESENTATIVE

Entity Type:

LP

Eligibility Criteria:

Applicant must be having one of the following position:

* GENERAL PARTNER

* LIMITED PARTNER

Documents Needed

List of Crane/ Game Machines
Documents showing list of crane/game machine

File format: pdf,jpg,gif,doc,docx

Maximum upload per application: 2 MB

Others
Additional Supporting Documents (eg. URA Land Use / HDB lodgement)

File format: pdf,jpg,gif,doc,docx

Maximum upload per application: 2 MB

Requirements

Limited Liability Partnership
Applicant must be having position:
* PARTNER cum MANAGER

Company
Applicant must be having one of the following position:
* MANAGING DIRECTOR
* SECRETARY
* DIRECTOR
* CHIEF EXECUTIVE OFFICER

Business (Sole Proprietor/Partnership)
Applicant must be having one of the following position:
* OWNER
* AUTHORIZED REPRESENTATIVE

LP
Applicant must be having one of the following position:
* GENERAL PARTNER
* LIMITED PARTNER

repository: isomerpages/govtech-gobusiness

branch_name: refs/heads/staging

gha_license_id: NOASSERTION

repo_name: isomerpages/govtech-gobusiness


text:
# Poetical

An application for collaborating on creative writing.

Built using the MERN stack (MongoDB, Express, Node.js & React) and hosted on firebase.

[Back-end (server) source code](https://github.com/ianbaxter/poetical-server).

## Setup

Clone the project:

```
git clone https://github.com/ianbaxter/poetical
```

Navigate to the project directory:

```
cd poetical
```

Install dependencies:

```
npm install
```

To start the app in development mode:

```
npm run dev
```

Then go to http://localhost:3000 in the browser to view the application.

## Deploy

Change the .env file so that REACT_APP_BASE_URL=your_server_URL.

Then deploy to the hosting service of your choice.

repository: ianbaxter/poetical

repo_name: ianbaxter/poetical