text:
# Functions Coding Standards

Table of Contents:
- [Introduction](#introduction)
- [What Is In Scope?](#what-is-in-scope)
- [What Is Out Of Scope?](#what-is-out-of-scope)
- [Coding Standards](#coding-standards)

## Introduction

Practically of our executable code lives in _functions_ and _methods_. Without them, our types aren't _safe_, they're just types.

Any changes we make to _functions_ and _methods_ after they have shipped run the risk of breaking backwards-compatibility. It's important that we get them _right first time_ as much as possible.

Not all _functions_ and _methods_ are equal. Some of them do very specific jobs, and they need additional coding standards to cover that. We've added categories for each of these.

## What Is In Scope?

Currently in-scope are:

* all general points about function design and implementation
* all general points about method design and implementation

## What Is Out Of Scope?

Currently out-of-scope are:

* general points about our preferred coding style; these are covered in the [Coding Conventions][coding-conventions] category
* anything about specific types of function (they get their own, individual categories)

## Coding Standards

Priority | ID | Category | Criteria | Impacts
---------|----|----------|----------|--------
Major | [2.8.1][2.8.1] | Functions | All function signatures must follow the same pattern. | [Adoption][ADOPTION], [Correctness][CORRECTNESS], [Robustness][ROBUSTNESS], [Testability][TESTABILITY]
Major | [2.8.2][2.8.2] | Functions | Functions should use dependency injection. | [Adoption][ADOPTION], [Testability][TESTABILITY]
Major | [2.8.3][2.8.3] | Functions | Every mandatory dependency must be a named function parameter. | [Correctness][CORRECTNESS]
Major | [2.8.4][2.8.4] | Functions | Every user-supplied input must be a named parameter. | [Adoption][ADOPTION], [Correctness][CORRECTNESS]
Major | [2.8.5][2.8.5] | Functions | Avoid optional user-supplied inputs. | [Adoption][ADOPTION], [Project Maintenance][PROJECT-MAINTENANCE], [Testability][TESTABILITY]
Major | [2.8.6][2.8.6] | Functions | User-supplied options must be a single options parameter. | [Project Maintenance][PROJECT-MAINTENANCE]
Major | [2.8.7][2.8.7] | Functions | Every property of the _user-supplied options_ parameter must be optional. | [Project Maintenance][PROJECT-MAINTENANCE]
Major | [2.8.8][2.8.8] | Functions | Ever user-supplied option must have a default value. | [Adoption][ADOPTION], [Testability][TESTABILITY]
Major | [2.8.9][2.8.9] | Functions | Functional options must be captured as a rest parameter. | [Adoption][ADOPTION]
Major | [2.8.10][2.8.10] | [Functions][functions] | Define `DEFAULT_OPTIONS` for every function that cannot meet [2.8.7][2.8.7].
Minor | [3.8.1][3.8.1] | Functions | Create a type for your function's user-supplied options. | [Adoption][ADOPTION]
Minor | [3.8.2][3.8.2] | Functions | Limit user-supplied options to optional dependencies. | [Correctness][CORRECTNESS], [Project Maintenance][PROJECT-MAINTENANCE], [Testability][TESTABILITY]
Minor | [3.8.3][3.8.3] | [Functions][functions] | Use `DEFAULT_DATA_PATH` for all optional data path parameters. | [Adoption][ADOPTION]

[ADOPTION]: ../../impacted-areas/ADOPTION.md
[CONTRIBUTIONS]: ../../impacted-areas/CONTRIBUTIONS.md
[CORRECTNESS]: ../../impacted-areas/CORRECTNESS.md
[GOVERNANCE]: ../../impacted-areas/GOVERNANCE.md
[PROJECT-MAINTENANCE]: ../../impacted-areas/PROJECT-MAINTENANCE.md
[ROBUSTNESS]: ../../impacted-areas/ROBUSTNESS.md
[SECURITY]: ../../impacted-areas/SECURITY.md
[TESTABILITY]: ../../impacted-areas/TESTABILITY.md
[coding-conventions]: ../coding-conventions/README.md
[data-guarantees]: ../data-guarantees/README.md
[data-guards]: ../data-guards/README.md
[documentation]: ../documentation/README.md
[errors]: ../errors/README.md
[functions]: ../functions/README.md
[naming-conventions]: ../naming-conventions/README.md
[package-management]: ../package-management/README.md
[protocols-extensions]: ../protocols-extensions/README.md
[type-guarantees]: ../type-guarantees/README.md
[type-guards]: ../type-guards/README.md
[types]: ../types/README.md
[unit-tests]: ../unit-tests/README.md
[Base Class]: ../../glossary/base-class.md
[Branded Type]: ../../glossary/branded-type.md
[Caller]: ../../glossary/caller.md
[CQRS]: ../../glossary/CQRS.md
[Data Bag]: ../../glossary/data-bag.md
[Data Guarantee]: ../../glossary/data-guarantee.md
[Data Guard]: ../../glossary/data-guard.md
[Default Value]: ../../glossary/default-value.md
[Defensive Programming]: ../../glossary/defensive-programming.md
[Dependency]: ../../glossary/dependency.md
[Dependency Injection]: ../../glossary/dependency-injection.md
[Docblock]: ../../glossary/docblock.md
[End-User]: ../../glossary/end-user.md
[Entity]: ../../glossary/entity.md
[Exported Item]: ../../glossary/exported-item.md
[Extension]: ../../glossary/extension.md
[Flavoured Type]: ../../glossary/flavoured-type.md
[Function Prefix]: ../../glossary/function-prefix.md
[Function Signature]: ../../glossary/function-signature.md
[Hard-Coded]: ../../glossary/hard-coded.md
[Identity]: ../../glossary/identity.md
[Identity Function]: ../../glossary/identity-function.md
[Identity Type]: ../../glossary/identity-type.md
[Immutability]: ../../glossary/immutability.md
[Inherited Method]: ../../glossary/inherited-method.md
[Instantiable Type]: ../../glossary/instantiable-type.md
[Mandatory Dependency]: ../../glossary/mandatory-dependency.md
[No-Op]: ../../glossary/no-op.md
[Nominal Typing]: ../../glossary/nominal-typing.md
[Optional Input]: ../../glossary/optional-input.md
[Overridden Method]: ../../glossary/overridden-method.md
[Plain Object]: ../../glossary/plain-object.md
[Primitive Type]: ../../glossary/primitive-type.md
[Protocol]: ../../glossary/protocol.md
[Refined Type]: ../../glossary/refined-type.md
[Rest Parameter]: ../../glossary/rest-parameter.md
[Reusability]: ../../glossary/reusability.md
[Side Effects]: ../../glossary/side-effects.md
[Smart Constructor]: ../../glossary/smart-constructor.md
[Structural Typing]: ../../glossary/structural-typing.md
[Type Alias]: ../../glossary/type-alias.md
[Type Casting]: ../../glossary/type-casting.md
[Type Guarantee]: ../../glossary/type-guarantee.md
[Type Guard]: ../../glossary/type-guard.md
[Type Inference]: ../../glossary/type-inference.md
[Type Predicate]: ../../glossary/type-predicate.md
[User-Supplied Functional Options]: ../../glossary/user-supplied-functional-options.md
[User-Supplied Input]: ../../glossary/user-supplied-input.md
[User-Supplied Options]: ../../glossary/user-supplied-options.md
[User-Supplied Optional Dependencies]: ../../glossary/user-supplied-optional-dependencies.md
[Value]: ../../glossary/value.md
[Value Object]: ../../glossary/value-object.md
[2.8.1]: ./2.8.1.md
[2.8.2]: ./2.8.2.md
[2.8.3]: ./2.8.3.md
[2.8.4]: ./2.8.4.md
[2.8.5]: ./2.8.5.md
[2.8.6]: ./2.8.6.md
[2.8.7]: ./2.8.7.md
[2.8.8]: ./2.8.8.md
[2.8.9]: ./2.8.9.md
[2.8.10]: ./2.8.10.md
[3.8.1]: ./3.8.1.md
[3.8.2]: ./3.8.2.md
[3.8.3]: ./3.8.3.md

repository: SafelyTyped/ts-coding-standards

repo_name: SafelyTyped/ts-coding-standards


text:
---
type: post
title: "Change Analysis"
tags: [developers, teleport]
date: 2019-11-13 17:00:00
author: Sajay Antony
---

# Change Analysis with ACR

You can enable change analysis service on your subscription in the [Azure Portal](https://docs.microsoft.com/en-us/azure/azure-monitor/app/change-analysis) or using the following command

```sh
az provider register  -n 'Microsoft.ChangeAnalysis'
```

Once this has been enabled you can view changes on your registry.

For e.g. you can see that the `adminUserEnabled` boolean has been changed on the registry.

![](./change-analysis-screenshot.png)

license: MIT

repository: Azure/acr

branch_name: refs/heads/main

extension: md

gha_license_id: NOASSERTION

license_type: permissive

repo_name: Azure/acr


text:
# DEPRECATED

This package is no longer in-use. There is no recommended alternative.

## CWP CMS Recipe

[![Build Status](https://api.travis-ci.com/silverstripe/cwp-recipe-cms.svg?branch=2)](https://travis-ci.com/silverstripe/cwp-recipe-cms)
[![SilverStripe supported module](https://img.shields.io/badge/silverstripe-supported-0071C4.svg)](https://www.silverstripe.org/software/addons/silverstripe-commercially-supported-module-list/)

Extra CMS functionality recipe for a [CWP 2](https://www.cwp.govt.nz) installation. This includes the following core
SilverStripe and CWP modules:

 * [silverstripe/recipe-cms](https://github.com/silverstripe/recipe-cms): Recipe containing CMS, versioned, asset-admin, etc
 * [cwp/cwp-recipe-core](https://github.com/silverstripe/cwp-recipe-core): CWP core functionality recipe
 * [cwp/cwp](https://github.com/silverstripe/cwp): Additional CMS functionality, page types, configuration
 * [cwp/cwp-pdfexport](https://github.com/silverstripe/cwp-pdfexport): Add PDF exporting to pages
 * [silverstripe/html5](https://github.com/silverstripe/silverstripe-html5): Add HTML5 support to the CMS
 * [symbiote/silverstripe-gridfieldextensions](https://github.com/symbiote/silverstripe-gridfieldextensions): Extra
   feature components for GridFields

This can be either added to an existing project or used as a project base for creating a
basic CWP install.

## Get started

You can create a project using Composer:

```
composer create-project cwp/cwp-recipe-cms ./cwp2-cms ^2
```

## More information

See the [recipe plugin](https://github.com/silverstripe/recipe-plugin) page for instructions on how
SilverStripe recipes work.

repository: silverstripe/cwp-recipe-cms

repo_name: silverstripe/cwp-recipe-cms


text:
# Walkthrough: Fuzzing an example program with Winnie

In this guide, I'll explain how to use Winnie to fuzz a toy example program. The code for this guide can be found in `samples/toy_example`. You can build it with Visual Studio. There are 3 projects in the solution:

 - toy_example: this builds the main .exe we will fuzz
 - example_library: this is a .dll containing some buggy functionality that we want to target with our fuzzer
 - harness: this provides a bare-bones example harness to use with Winnie.

To set up the fuzzer, copy the target application (toy_example.exe and example_library.dll) to the Winnie directory (so it's next to afl-fuzz.exe). AFL needs seed inputs, so copy the seed input file (in\input). Lastly, Winnie needs a fuzzing harness to call the target, so copy our fuzzing harness `harness.dll` next to afl-fuzz.exe as well.

At this point, your directory structure should look like this:

![dir.png](./dir.png)

Winnie collects coverage using *full-speed* instrumentation. Full-speed instrumentation essentially puts a breakpoint on each basic block. Thus, Winnie needs a list of the addresses of basic blocks we want to cover per module. This list is called the *bb-file* and it's specified with the `-bbfile` parameter. We can automatically generate this file with the IDAPython script `scripts/ida_basic_blocks.py` if you have IDA Pro. (There is also a script for Ghidra.) For more about the bbfile file format, check the README.

At this point, you should also have `basicblocks.bb` in the directory too. Now we can start fuzzing.

`afl-fuzz -i in -o out -t 1000 -I 1000 -- -bbfile basicblocks.bb -- -harness harness.dll -no_minidumps -- toy_example.exe @@`

**Breakdown of the command-line:**

1. `afl-fuzz -i in -o out -t 1000 -I 1000` Standard AFL parameters `-i` and `-o` for input/output dirs, execution timeout (`-t`) of 1000ms, initialization timeout (`-I`) of 1000ms.

2. `--` End of AFL options and start of fullspeed instrumentation options

3. `-bbfile basicblocks.bb` (Required) Use the basic blocks specified in the bbfile `basicblocks.bb`.

4. `--` End of the fullspeed options and start of the forkserver options

5. `-harness harness.dll` (Required) Use our fuzzing harness specific to toy_example.

6. `-no_minidumps` Disable minidumps for speed since toy_example tends to crash a lot during fuzzing. See README for more info.

7. `--` End of forkserver options and start of target argv

8. `toy_example.exe @@` Call toy_example.exe and pass the input filename as argv[1].

### Troubleshooting

If you encounter errors, check out the README for more info on debugging or make an issue.

repository: leocstone/winnie

branch_name: refs/heads/master

repo_name: leocstone/winnie


text:
# webmessagesRMI
Library enabling RMI like interaction across window/iframe of a webpage using webmessages

# Description

The library exposes the global variable **wmRMI**, which is the unique entrypoint of the library and allows to subscribe to library produced events, connect to a "remote" window, disconnect from a window.

Here the exposed interface:

- **eventHook():DOMElement**: gets an object (DOMElement) usable to subcribe to library produced events
- **connect(wnd[, origin="\*"]):promise-like**: starts the connection to another window (_wnd_) providing its origin. Returns a promise-like object. The resolution callback will have the connection object as its first argument.
- **disconnect(obj):void**: disconnects the library invalidating all produced object wrapper. _obj_ can be a connection object or a window object.
- **on(obj, eventName, callback)**: adds the event handler _callback_ of _eventName_ from the object _obj_. The object must be a DOMElement or an object with an _eventHook()_ methods which returns a DOMElement.
- **off(obj, eventName, callback)**: removes the event handler _callback_ of _eventName_ from the object _obj_.

# Usage

Here are a usage example of an iframe coomunicating with its parent window.
Every page loads the jquery library and the webmessageRMI library.

Main window:

	$(wmRMI.eventHook()).on("connected",function(res){
		var wmRMI = res.detail.wmRMI;
		window.x = wmRMI;
		var a={};
		var b={};
		wmRMI.bind("a",a);
		wmRMI.bind("b",b);

		wmRMI.rmiCall("root","listBoundObjects")
		.done(function(data){
			console.log(data);
		});

		window.wmRMI.on(wmRMI,"object-bound", function(name){
			//args:c
			console.log("event [object-bound]: args:"+name);

			wmRMI.getWrappedObject("c")
			.done(function(p){
				p.mt1_sync(10).join(function(res){
					//res.value===16
					console.log(res.value);
				});

				$(p.eventHook()).on("test", function(e){
					//event [c::test]: args:3,"valore"
					console.log("event [c::test]: args:"+e.detail.arguments);
				});
				//same as
				window.wmRMI.on(p,"test", function(a,b){
					//event [c::test]: args:3,"valore"
					console.log("event [c::test]: args:"+a+","+b);
				});
			})
			.fail(function(e){
				console.log(e);
			});
		});
	});

IFrame window:

	var c={
		val:3,
		mt1:function(){
			return this.val;
		},
		mt2:function(val){
			return this.val*2+val;
		},
		obj:{}
	};

	wmRMI.connect(window.parent,"*")
	.done(function(wmRMI){
		console.log("connected");

		wmRMI.bind("c",c);

		wmRMI.rmiCall("root","listBoundObjects")
		.done(function(data){
			console.log(data);
		});

		setTimeout(function(){
			wmRMI.rmiTriggerEvent("c","test", 3, "valore");
		},2000);
	});

The IFrame window inits the connection while the main window listen to connection notifications.
After the connection has been established, both sides register some local objects for remote expositions and query the remote peer to get a list o exposed objects.

After that the main window get a wrapper object of the "c" object exsposed by the IFrame and calls its mt2_\_sync_ method variant.

# API

### connection object

Through the connection object is possible to expose local objects to remote call, perform remote call on remote objects, get o trigger remote events from or to the remote peer, get information on the currently exposed objects and get wrappers of remote objects exsposed by the linked peer.

Here the exposed interface:

- **eventHook():DOMElement**: gets an object (DOMElement) usable to subcribe to remote events
- **triggerEvent(eventName[,...]):void**: trigger a remote event of type _eventName_. Every further argument will be passed in the event detail.
- **bind(objName, obj):void**: expose a local object to remote invaocation by _objName_ name. The connection object is always exposed with the **"root"** name. The event **object-bound** with the object binding name is triggered.
- **unbind(objName):void**: revokes the local by _objName_ identified object exposition. The event **object-unbound** with the object binding name is triggered.
- **rmiCall(objName,mtName[,...]):promise-like**: invokes the method named _mtName_ on the remote _objName_ named object. Every further argument will be passed as an argument of the remote method. Return a promise-like object. The resolution callback will have the method result as its first argument.
- **listBoundObjects():array**: gets an array of remotely exposed object names.
- **listBoundObjectMethods(objName):array**: gets an array of method names exposed by _objName_.
- **getWrappedObject(objName):promise-like**: produce an object wrapper of the remote _objName_. Returns a promise-like object the resolve callback of which will have the wrapper object as its first argument.
- **dispose():void**: Destroys the connection object and triggers the "disposed" remote event, destroying its remote peer.
- **isDisposed():bool**: Returns true if the objects has been disposed.
- **isConnected():bool**: Returns true if the connection hand-shake has benn concluded.

### wrapper object

The wrapper object is an object with all the methods exposed by the remote object and for each one a copy with the suffix __sync_.

The normal methods will return a promise-like object, the same as the one returned by the method _rmiCall_.

The _\*\_sync_ methods will return an object with the following interface:
- **hasValue():bool**: returns true if the object has a _value_ property.
- **value:object**: the result of the invocation. The value is meaningfull and set only when the _hasValue()_ method returns true.
- **join(callback):void**: register a callback to be called at the setting of the _value_ attribute at the conclusion of the remote method invocation. The object will be passed as the first argument of the callback.

The object has also a **eventHook()** method which exposes the hook on which remote events from the paired window will be triggered and can be listened to.

### promise-like object

The "prmise-like object" is an object that resembles the interface of a jquery promise. On it is possible to call the chianable methods:

- **done(callabck):self**
- **fail(callback):self**
- **always(callback):self**
- **then(resolve, reject):promise-like**

### call context object

The call context object is attached to the exposed methods during a remote call setting the funcion attribute **\_\_wmRMI_ctx**.

The object is used to singal the outcome to the remote calling peer.

Here the exposed interface:

- **call(obj, mt, args):object**: starts a controlled execution of the method _mt_ on the object _obj_ with the arguments in the_args_ array.
- **resolve(result):void**: signal the successfull conclusion of the invocation, sending _result_ as the outcome.
- **reject(error):void**: signal the unsuccessfull conclusion of the invocation, sending _error_ as the outcome.

# Exposing an object

Every object can be exposed. The unique limitations are those imposed by the HTML5 webmessages specification: every exchanged object must be _Transferrable_.

It's possibe to influence the behaviour of the exposed methods and their visbility, decorating the function object with the attribute **\_\_wmRMI_attributes**.

Setting the attribute **notpublic=true** of the **\_\_wmRMI_attributes** object hides the method from the remote peer insepction and invocation.
Setting the attribute **async=true** of the **\_\_wmRMI_attributes** object blocks the automatic call of the _callContext.resolve()_ method, enabling the asynchronous managing of the call.

The asynchronous managing can also be enforced by the method itself. Every remotely called method will have the attribute **\_wmRMI_ctx** set with the current callContext object. Setting the attribute **\_wmRMI_ctx.async=true**, blocks the automatic resolve call and allows the caller to handle result signlaing.


text:
# codecard

[![license](https://img.shields.io/badge/license-MIT-blue)](LICENSE)

Bootstrap cards to display information about your code repositories. This may be useful for your own personal
website or portfolio.

## Using

You will need

* [Bootstrap](https://getbootstrap.com/)
* [Font Awesome](https://fontawesome.com/)

Use it as a [script from jsdelivr](https://www.jsdelivr.com/package/gh/ravenlab/codecard) or download, we are not on npm yet.

repository: ravenlab/codecard

repo_name: ravenlab/codecard


text:
# Kubernetes on CenturyLink Cloud
These scripts handle the creation, deletion and expansion of kubernetes clusters on CenturyLink Cloud.

You can accomplish all these tasks with a simple single command. And, for those interested in what's under the covers, we used Ansible to perform these tasks and we have made these Ansible playbooks available as well.

## Find Help
If you run into any problems or want help with anything, we are here to help. Reach out to use via any of the following ways:
- Submit a github issue
- Send an email to kubernetes AT ctl DOT io
- Visit http://info.ctl.io/kubernetes

## Clusters of VMs or Physical Servers, your choice.
- We support Kubernetes clusters on both Virtual Machines or Physical Servers. If you want to use physical servers for the worker nodes (minions), simple use the --minion_type=bareMetal flag.
- For more information on physical servers, visit: [https://www.ctl.io/bare-metal/](https://www.ctl.io/bare-metal/))
- Physical serves are only available in the VA1 and GB3 data centers.
- VMs are available in all 13 of our public cloud locations

## Requirements
The requirements to run this script are:
- A linux administrative host (tested on ubuntu and OSX)
- python 2 (tested on 2.7.11)
  - pip (installed with python as of 2.7.9)
- git
- A CenturyLink Cloud account with rights to create new hosts
- An active VPN connection to the CenturyLink Cloud from your linux host

## Script Installation
After you have all the requirements met, please follow these instructions to install this script.

1) Clone this repository and cd into it.

```
git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc
```

2) Install all requirements, including
  * Ansible
  * [CenturyLink Cloud SDK](https://github.com/CenturyLinkCloud/clc-python-sdk)
  * Ansible Modules

```
sudo pip install -r requirements.txt
```

3) Create the credentials file from the template and use it to set your ENV variables

```
cp ansible/credentials.sh.template ansible/credentials.sh
vi ansible/credentials.sh
source ansible/credentials.sh

```

4) Make sure the computer you are working on has access to the CenturyLink Cloud
network. This is done by using a VM inside the CenturyLink Cloud network or
having an active VPN connection to the CenturyLink Cloud network. To find out
how to configure the VPN connection, [visit here](https://www.ctl.io/knowledge-base/network/how-to-configure-client-vpn/)

#### Script Installation Example: Ubuntu 14 Walkthrough

If you use an ubuntu 14, for your convenience we have provided a step by step
guide to install the requirements and install the script.

```
  # system
  apt-get update
  apt-get install -y git python python-crypto
  curl -O https://bootstrap.pypa.io/get-pip.py
  python get-pip.py

  # installing this repository
  mkdir -p ~home/k8s-on-clc
  cd ~home/k8s-on-clc
  git clone https://github.com/CenturyLinkCloud/adm-kubernetes-on-clc.git
  cd adm-kubernetes-on-clc/
  pip install -r requirements.txt

  # getting started
  cd ansible
  cp credentials.sh.template credentials.sh; vi credentials.sh
  source credentials.sh
```

## Cluster Creation

To create a new Kubernetes cluster, simply run the kube-up.sh script. A complete
list of script options and some examples are listed below.

```
export CLC_CLUSTER_NAME=[name of kubernetes cluster]
cd ./adm-kubernetes-on-clc
bash kube-up.sh -c="$CLC_CLUSTER_NAME"
```

It takes about 15 minutes to create the cluster. Once the script completes, it
will output some commands that will help you setup kubectl on your machine to
point to the new cluster.

When the cluster creation is complete, the configuration files for it are stored
locally on your administrative host, in the directory

> CLC_CLUSTER_HOME=$HOME/.clc_kube/$CLC_CLUSTER_NAME/

#### Cluster Creation: Script Options

```
Usage: kube-up.sh [OPTIONS]
Create servers in the CenturyLinkCloud environment and initialize a Kubernetes cluster
Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
order to access the CenturyLinkCloud API

All options (both short and long form) require arguments, and must include "="
between option name and option value.

     -h (--help)                   display this help and exit
     -c= (--clc_cluster_name=)     set the name of the cluster, as used in CLC group names
     -t= (--minion_type=)          standard -> VM (default), bareMetal -> physical]
     -d= (--datacenter=)           VA1 (default)
     -m= (--minion_count=)         number of kubernetes minion nodes
     -mem= (--vm_memory=)          number of GB ram for each minion
     -cpu= (--vm_cpu=)             number of virtual cps for each minion node
     -phyid= (--server_conf_id=)   physical server configuration id, one of
                                      physical_server_20_core_conf_id
                                      physical_server_12_core_conf_id
                                      physical_server_4_core_conf_id (default)
     -etcd_separate_cluster=yes    create a separate cluster of three etcd nodes,
                                   otherwise run etcd on the master node
```

## Cluster Expansion

To expand an existing Kubernetes cluster, run the add-kube-node.sh
script. A complete list of script options and some examples are listed below.
This script must be run from the same hose that created the cluster (or a host
that has the cluster artifact files stored in ~/.clc_kube/$cluster_name).

```
cd ./adm-kubernetes-on-clc
bash add-kube-node.sh -c="name_of_kubernetes_cluster" -m=2
```

#### Cluster Expansion: Script Options

```
Usage: add-kube-node.sh [OPTIONS]
Create servers in the CenturyLinkCloud environment and add to an
existing CLC kubernetes cluster

Environment variables CLC_V2_API_USERNAME and CLC_V2_API_PASSWD must be set in
order to access the CenturyLinkCloud API

     -h (--help)                   display this help and exit
     -c= (--clc_cluster_name=)     set the name of the cluster, as used in CLC group names
     -m= (--minion_count=)         number of kubernetes minion nodes to add

```

## Cluster Deletion
There are two ways to delete an existing cluster:

1) Use our python script:

```
python delete_cluster.py --clc_cluster_name=clc_cluster_name --datacenter=DC1

```

2) Use the CenturyLink Cloud UI. To delete a cluster, log into the CenturyLink
Cloud control portal and delete the parent server group that contains the
Kubernetes Cluster. We hope to add a scripted option to do this soon.

## Examples
Create a cluster with name of k8s_1, 1 master node and 3 worker minions (on physical machines), in VA1

```
 bash kube-up.sh --clc_cluster_name=k8s_1 --minion_type=bareMetal --minion_count=3 --datacenter=VA1
```

Create a cluster with name of k8s_2, an ha etcd cluster on 3 VMs and 6 worker minions (on VMs), in VA1

```
 bash kube-up.sh --clc_cluster_name=k8s_2 --minion_type=standard --minion_count=6 --datacenter=VA1 --etcd_separate_cluster=yes
```

Create a cluster with name of k8s_3, 1 master node, and 10 worker minions (on VMs) with higher mem/cpu, in UC1:

```
  bash kube-up.sh --clc_cluster_name=k8s_3 --minion_type=standard --minion_count=10 --datacenter=VA1 -mem=6 -cpu=4
```

## Cluster Features and Architecture
We configue the Kubernetes cluster with the following features:

* KubeDNS: DNS resolution and service discovery
* Heapster/InfluxDB: For metric collection. Needed for Grafana and auto-scaling.
* Grafana: Kubernetes/Docker metric dashboard
* KubeUI: Simple web interface to view kubernetes state
* Kube Dashboard: New web interface to interact with your cluster

We use the following to create the kubernetes cluster:

* Kubernetes 1.1.7
* Unbuntu 14.04
* Flannel 0.5.4
* Docker 1.9.1-0~trusty
* Etcd 2.2.2

## Optional add-ons

* Logging: We offer an integrated centralized logging ELK platform so that all
  kubernetes and docker logs get sent to the ELK stack. To install the ELK stack
  and configure kubernetes to send logs to it, follow this documentation: [log
  aggregation](log_aggregration.md). Note: We don't install this by default as
  the footprint isn't trivial.

## Cluster management

The most widely used tool for managing a kubernetes cluster is the command-line
utility _kubectl_.  If you do not already have a copy of this binary on your
administrative machine, you may run the script _install_kubectl.sh_ which will
download it and install it in _/usr/bin/local_.

The script requires that the environment variable CLC_CLUSTER_NAME be defined

_install_kubectl.sh_ also writes a configuration file which will embed the necessary
authentication certificates for the particular cluster.  The configuration file is
written to the  ${CLC_CLUSTER_HOME}/kube directory

```
export KUBECONFIG=${CLC_CLUSTER_HOME}/kube/config
kubectl version
kubectl cluster-info
```

### Accessing the cluster programmatically

It's possible to use the locally-stored client certificates to access the api server
```
curl \
   --cacert ${CLC_CLUSTER_HOME}/pki/ca.crt  \
   --key ${CLC_CLUSTER_HOME}/pki/kubecfg.key \
   --cert ${CLC_CLUSTER_HOME}/pki/kubecfg.crt  https://${MASTER_IP}:6443
```
But please note, this *does not* work out of the box with the curl binary
distributed with OSX

### Accessing the cluster with a browser

We install two UIs on kubernetes. The orginal KubeUI and the newer kube
dashboard. When you create a cluster, the script should output URLs for these
interfaces like this:

KubeUI is running at https://${MASTER_IP}:6443/api/v1/proxy/namespaces/kube-system/services/kube-ui
kubernetes-dashboard is running at https://${MASTER_IP}:6443/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard

Note on Authentication to the UIs: The cluster is set up to use basic
authentication for the user _admin_.   Hitting the url at
https://${MASTER_IP}:6443 will require accepting the self-signed certificate
from the apiserver, and then presenting the admin password written to file at

> _${CLC_CLUSTER_HOME}/kube/admin_password.txt_

### Configuration files

Various configuration files are written into the home directory *CLC_CLUSTER_HOME* under
_.clc_kube/${CLC_CLUSTER_NAME}_ in several subdirectories. You can use these files
to access the cluster from machines other than where you created the cluster from.

* _config/_: ansible variable files containing parameters describing the master and minion hosts
* _hosts/_: hosts files listing access information for the ansible playbooks
* _kube/_: kubectl configuration files, and the basic-authentication password for admin access to the kubernetes api
* _pki/_: public key infrastructure files enabling TLS communication in the cluster
* _ssh/_: ssh keys for root access to the hosts

## _kubectl_ usage examples

There are a great many features of _kubectl_.  Here are a few examples

List existing nodes, pods, services and more, in all namespaces, or in just one
```
kubectl get nodes

kubectl get --all-namespaces services

kubectl get --namespace=kube-system replicationcontrollers

```

The kubernetes api server exposes services on web urls, which are protected by requiring
client certificates.  If you run a kubectl proxy locally, kubectl will provide
the necessary certificates and serve locally over http.
```
kubectl proxy -p 8001
```
and then access urls like http://<IP_ADDRESS>:8001/api/v1/proxy/namespaces/kube-system/services/kube-ui/
without the need for client certificates in your browser.

## What Kubernetes features do not work on CenturyLink Cloud

- At this time, there is no support services of the type 'loadbalancer'. We are
  actively working on this and hope to publish the changes soon.
- At this time, there is no support for persistent storage volumes provided by
  CenturyLink Cloud. However, customers can bring their own persistent storage
  offering. We ourselves use Gluster.

## Ansible Files
If you want more information about our ansible files, please [read this file](ansible/README.md)

## License
The project is licensed under the [Apache License v2.0](http://www.apache.org/licenses/LICENSE-2.0.html).

repository: rothgar/adm-kubernetes-on-clc

repo_name: rothgar/adm-kubernetes-on-clc


text:
# Day 46 - Rails Tutorial

## Random Rails Tips

* Doing *resource: :farm* will give you all the routes of *resources: :farms* without the ":id" routes
* You can do custom, non-REST routes like "get '/pages', to 'pages#about'
* a single "Pages" controller is usually a good way to get static pages like "About" set up
* Never edit schema.rb directly. You need to write a migration to create/change/delete tables
* If you make a mistake in a migration, make a new migration to fix the error. (Or if you're 100% sure no one has pulled the error, roll back and fix the migration)
* By default, Rails does server-side rendering. If you want to use a separate front-end framework like React, you can instead create a Rails app with:

```
rails new my_api --api
```
* Or to modify an existing Rails app to be API-only, put this in the Application class:
```ruby
config.api_only = true
```
* This will generate a Rails app without "views". You will only have the ActiveRecord/models part of the app
* Then, when you need to send data to the front end, do:
```ruby
render json: @object_name
```
This will send JSON in response to any HTTP request at that route

repository: sherwin-kwan/lighthouse-web-notes

repo_name: sherwin-kwan/lighthouse-web-notes


text:
[![Download](https://api.bintray.com/packages/dmcg/oneeyedmen-mvn/minutest.dev/images/download.svg)](https://bintray.com/dmcg/oneeyedmen-mvn/minutest.dev/_latestVersion)
[![Build Status](https://travis-ci.org/dmcg/minutest.svg?branch=master)](https://travis-ci.org/dmcg/minutest)

# Minutest

JUnit multiplied by Kotlin

## Why Another Test Framework?

JUnit is great for quickly writing and running tests as part of a TDD workflow, but try to do anything unusual and you have to reach for the documentation and specially written annotations.

Minutest extends JUnit with a simple model that allows you to solve your own problems with plain Kotlin.

For example

### Conditionally running a test

JUnit has a special annotation

```kotlin
@Test
@EnabledIfEnvironmentVariable(named = "ENV", matches = "staging-server")
fun onlyOnStagingServer() {
    // ...
}
```

Minutest is just Kotlin

```kotlin
if (getenv("ENV") == "staging-server" ) test("only on staging server") {
    // ...
}
```

### Parameterised tests

JUnit has three annotations

```kotlin
@DisplayName("Fruit tests")
@ParameterizedTest(name = "{index} ==> fruit=''{0}'', rank={1}")
@CsvSource("apple, 1", "banana, 2", "'lemon, lime', 3")
fun testWithCustomDisplayNames(fruit: String, rank, String) {
    // ...
}
```

Minutest is just Kotlin

```kotlin
context("Fruit tests") {
    listOf("apple" to 1, "banana" to 2, "lemon, lime" to 3).forEachIndexed { index, (fruit, rank) ->
        test("$index ==> fruit='$fruit', rank=$rank") {
            // ...
        }
    }
}
```

### Nested Tests

JUnit needs more annotations

[start-insert]: <../core/src/test/kotlin/dev/minutest/examples/StackExampleTestsJUnit.kt>
```kotlin
@DisplayName("A stack")
class TestingAStackDemo {

    var stack: Stack<Any> = Stack()

    @Nested
    @DisplayName("when new")
    inner class WhenNew {

        @Test
        fun `is empty`() {
            assertTrue(stack.isEmpty())
        }
    }

    @Nested
    @DisplayName("after pushing an element")
    inner class AfterPushing {

        var anElement = "an element"

        @BeforeEach
        fun pushAnElement() {
            stack.push(anElement)
        }

        @Test
        fun `it is no longer empty`() {
            assertFalse(stack.isEmpty())
        }
    }
}
```
[../core/src/test/kotlin/dev/minutest/examples/StackExampleTestsJUnit.kt](../core/src/test/kotlin/dev/minutest/examples/StackExampleTestsJUnit.kt)

[end-insert]: <>

Minutest is just Kotlin

[start-insert]: <../core/src/test/kotlin/dev/minutest/examples/StackExampleTests.kt>
```kotlin
class StackExampleTests : JUnit5Minutests {

    fun tests() = rootContext<Stack<Any>> {

        given { Stack() }

        context("when new") {

            test("is empty") {
                assertTrue(it.isEmpty())
            }
        }

        context("after pushing an element") {

            beforeEach {
                it.push("an element")
            }

            test("it is no longer empty") {
                assertFalse(it.isEmpty())
            }
        }
    }
}
```
[../core/src/test/kotlin/dev/minutest/examples/StackExampleTests.kt](../core/src/test/kotlin/dev/minutest/examples/StackExampleTests.kt)

[end-insert]: <>

Minutest brings the power of Kotlin to JUnit, providing

* A clean DSL to define nested contexts and tests
* Generation and manipulation of tests at runtime
* Much easier reuse of test code

For more information on how why Minutest is like it is, see [My New Test Model](http://oneeyedmen.com/my-new-test-model.html) .

## Installation

[Instructions](installation.md)

## Moving from JUnit to Minutest

Here is a version of the JUnit 5 [first test case](https://junit.org/junit5/docs/current/user-guide/#writing-tests), converted to Kotlin.

[start-insert]: <../core/src/test/kotlin/dev/minutest/examples/MyFirstJUnitJupiterTests.kt>
```kotlin
class MyFirstJUnitJupiterTests {

    private val calculator = Calculator()

    @Test
    fun addition() {
        calculator.add(2)
        assertEquals(2, calculator.currentValue)
    }

    @Test
    fun subtraction() {
        calculator.subtract(2)
        assertEquals(-2, calculator.currentValue)
    }
}
```
[../core/src/test/kotlin/dev/minutest/examples/MyFirstJUnitJupiterTests.kt](../core/src/test/kotlin/dev/minutest/examples/MyFirstJUnitJupiterTests.kt)

[end-insert]: <>

In Minutest it looks like this

[start-insert]: <../core/src/test/kotlin/dev/minutest/examples/MyFirstMinutests.kt>
```kotlin
// Mix-in JUnit5Minutests to run Minutests with JUnit 5
//
// (JUnit 4 support is also available, see [JUnit4Minutests].)
class MyFirstMinutests : JUnit5Minutests {

    // tests are grouped in a context
    fun tests() = rootContext<Calculator> {

        // We need to tell Minutest how to build the fixture
        given { Calculator() }

        // define a test with a test block
        test("addition") {
            // inside tests, the fixture is `it`
            it.add(2)
            assertEquals(2, it.currentValue)
        }

        // each new test gets its own new fixture
        test("subtraction") { calculator ->
            subtract(2)
            assertEquals(-2, calculator.currentValue)
        }
    }
}
```
[../core/src/test/kotlin/dev/minutest/examples/MyFirstMinutests.kt](../core/src/test/kotlin/dev/minutest/examples/MyFirstMinutests.kt)

[end-insert]: <>

Most tests require access to some state. The collection of state required by the tests is called the test fixture. In JUnit we use the fields of the test class as the fixture - in this case just the calculator. JUnit uses a fresh instance of the test class for each test method run, which is why the state of calculator after `addition` does not affect the result of `subtraction`.

Minutest does not create a fresh instance of the test class for each test, instead it invokes a `fixture` block in a context and passes the result into tests as `this`.

Tests for cooperating components will typically have more state than just the thing we are testing. In this case make the fixture hold all the state.

[start-insert]: <../core/src/test/kotlin/dev/minutest/examples/fixtures/CompoundFixtureExampleTests.kt>
```kotlin
class ControlPanel(
    private val beep: () -> Unit,
    private val launchRocket: () -> Unit
) {
    private var keyTurned: Boolean = false

    fun turnKey() {
        keyTurned = true
    }

    fun pressButton() {
        if (keyTurned)
            launchRocket()
        else
            beep()
    }
    val warningLightOn get() = keyTurned
}

class CompoundFixtureExampleTests : JUnit5Minutests {

    // The fixture consists of all the state affected by tests
    class Fixture {
        var beeped = false
        var launched = false

        val controlPanel = ControlPanel(
            beep = { beeped = true },
            launchRocket = { launched = true }
        )
    }

    fun tests() = rootContext<Fixture> {
        given { Fixture() }

        context("key not turned") {
            test("light is off") {
                assertFalse(controlPanel.warningLightOn)
            }
            test("cannot launch when pressing button") {
                controlPanel.pressButton()
                assertTrue(beeped)
                assertFalse(launched)
            }
        }

        context("key turned") {
            beforeEach {
                controlPanel.turnKey()
            }
            test("light is on") {
                assertTrue(controlPanel.warningLightOn)
            }
            test("launches when pressing button") {
                controlPanel.pressButton()
                assertFalse(beeped)
                assertTrue(launched)
            }
        }
    }
}
```
[../core/src/test/kotlin/dev/minutest/examples/fixtures/CompoundFixtureExampleTests.kt](../core/src/test/kotlin/dev/minutest/examples/fixtures/CompoundFixtureExampleTests.kt)

[end-insert]: <>

Understanding fixtures is key to Minutest - [read more](fixtures.md)

## Run Code to Make Tests

The key to Minutest is that by separating the fixture from the test code, both are made available to manipulate as data.

For example, parameterised tests require [special handling](https://junit.org/junit5/docs/current/user-guide/#writing-tests-parameterized-tests) in JUnit, but not in Minutest.

[start-insert]: <../core/src/test/kotlin/dev/minutest/examples/ParameterisedExampleTests.kt>
```kotlin
class ParameterisedExampleTests : JUnit5Minutests {

    fun tests() = rootContext {

        context("palindromes") {

            // Creating a test for each of multiple parameters is as easy as
            // calling `test()` for each one.
            listOf("a", "oo", "racecar", "able was I ere I saw elba").forEach { candidate ->
                test("$candidate is a palindrome") {
                    assertTrue(candidate.isPalindrome())
                }
            }
        }
        context("not palindromes") {
            listOf("", "ab", "a man a plan a canal pananma").forEach { candidate ->
                test("$candidate is not a palindrome") {
                    assertFalse(candidate.isPalindrome())
                }
            }
        }

        // Minutest will check that the following tests are run
        willRun(
            "▾ tests",
            "  ▾ palindromes",
            "    ✓ a is a palindrome",
            "    ✓ oo is a palindrome",
            "    ✓ racecar is a palindrome",
            "    ✓ able was I ere I saw elba is a palindrome",
            "  ▾ not palindromes",
            "    ✓  is not a palindrome",
            "    ✓ ab is not a palindrome",
            "    ✓ a man a plan a canal pananma is not a palindrome"
        )
    }
}

fun String.isPalindrome(): Boolean =
    if (length == 0) false
    else (0 until length / 2).find { index -> this[index] != this[length - index - 1] } == null
```
[../core/src/test/kotlin/dev/minutest/examples/ParameterisedExampleTests.kt](../core/src/test/kotlin/dev/minutest/examples/ParameterisedExampleTests.kt)

[end-insert]: <>

## Reuse Tests

More complicated scenarios can be approached by writing your own function that returns a test or a context.

If you want to reuse the same tests for different concrete implementations, define a context with a function and call it for subclasses. Some people call this a contract.

[start-insert]: <../core/src/test/kotlin/dev/minutest/examples/ContractsExampleTests.kt>
```kotlin
// To run the same tests against different implementations, first define a ContextBuilder extension function
// that defines the tests you want run.
fun ContextBuilder<MutableCollection<String>>.behavesAsMutableCollection() {

    context("behaves as MutableCollection") {

        test("is empty when created") {
            assertTrue(isEmpty())
        }

        test("can add") {
            add("item")
            assertEquals("item", first())
        }
    }
}

// Now tests can supply the fixture and invoke the function to create the tests to verify the contract.
class ArrayListTests : JUnit5Minutests {

    fun tests() = rootContext<MutableCollection<String>> {
        given {
            ArrayList()
        }

        behavesAsMutableCollection()
    }
}

// We can reuse the contract for different collections.
class LinkedListTests : JUnit5Minutests {

    fun tests() = rootContext<MutableCollection<String>> {
        given {
            LinkedList()
        }

        behavesAsMutableCollection()
    }
}
```
[../core/src/test/kotlin/dev/minutest/examples/ContractsExampleTests.kt](../core/src/test/kotlin/dev/minutest/examples/ContractsExampleTests.kt)

[end-insert]: <>

## Structure Tests

When your tests grow so that they need more structure, Minutest has extensions to support Given When Then blocks

[start-insert]: <../core/src/test/kotlin/dev/minutest/examples/scenarios/ScenariosExampleTests.kt>
```kotlin
class ControlPanel(
    private val beep: () -> Unit,
    private val launchRocket: () -> Unit
) {
    private var keyTurned: Boolean = false

    fun turnKey() {
        keyTurned = true
    }

    fun pressButton(): Boolean =
        when {
            keyTurned -> {
                launchRocket()
                true
            }
            else -> {
                beep()
                false
            }
        }

    val warningLightOn get() = keyTurned
}

class ScenariosExampleTests : JUnit5Minutests {

    class Fixture {
        var beeped = false
        var launched = false

        val controlPanel = ControlPanel(
            beep = { beeped = true },
            launchRocket = { launched = true }
        )
    }

    fun tests() = rootContext<Fixture> {

        // Scenario defines a nested context
        Scenario("Cannot launch without key switch") {

            // GivenFixture sets up the fixture for the scenario
            GivenFixture("key not turned") {
                Fixture()
            }.Then("warning light is off") {
                // Then can check the setup
                assertFalse(controlPanel.warningLightOn)
            }

            // When performs the operation
            When("pressing the button") {
                controlPanel.pressButton()
            }.Then("result was false") { result ->
                // Then has access to the result
                assertFalse(result)
            }.And("it beeped") {
                // And makes another Thens with checks
                assertTrue(beeped)
            }.And("rocket was not launched") {
                assertFalse(launched)
            }
        }

        Scenario("Will launch with key switch") {
            GivenFixture("key turned") {
                Fixture().apply {
                    controlPanel.turnKey()
                }
            }.Then("warning light is on") {
                assertTrue(controlPanel.warningLightOn)
            }

            When("pressing the button") {
                controlPanel.pressButton()
            }.Then("result was true") { result ->
                assertTrue(result)
            }.And("it didn't beep") {
                assertFalse(beeped)
            }.And("rocket was launched") {
                assertTrue(launched)
            }
        }
    }
}
```
[../core/src/test/kotlin/dev/minutest/examples/scenarios/ScenariosExampleTests.kt](../core/src/test/kotlin/dev/minutest/examples/scenarios/ScenariosExampleTests.kt)

[end-insert]: <>

## Other Features

The [Cookbook](Cookbook.md) shows other ways to use Minutest.

## Evolution

We're pretty happy with the core Minutest language and expect not to make any breaking changes without a major version update. Features like JUnit 4 support and test annotations are public but experimental - if you use anything in an `experimental` package you should expect it to change between minor releases, and move completely once adopted into the stable core.

Note that we aim for source and not binary compatibility. Some implementation may move from  methods to extension functions, or from constructors to top level or companion-object functions.

## Support

The best bet for feedback and help is the [#minutest channel on the Kotlin Slack](https://kotlinlang.slack.com/messages/CCYE00YM6). See you there.

repository: dmcg/minutest

gha_language: Kotlin

repo_name: dmcg/minutest


text:
# Train an object classifier on [ImageNet](http://image-net.org/download-images) using multiple gpus in Torch7

This repo shows how to train a object classifier over ImageNet/Cifar10/Cifar100/MNIST using a multi-threaded, multi-gpu approach.

## Features

- Several types of networks like AlexNet, Overfeat, VGG, Googlenet, etc. are available for training;
- Multi-GPU support;
- Data loading/processing using multiple threads;
- Easily apply data augmentation;
- Integration with the `dbcollection` package.

## Requirements

- NVIDIA GPU with compute capability 3.5+ (2GB+ ram)
- [torch7](http://torch.ch/docs/getting-started.html#_)
- [torchnet](https://github.com/torchnet/torchnet)
- [dbcollection](https://github.com/dbcollection/dbcollection)

## Running the code

The main script comes with several options which can be listed by running the script with the flag --help
```bash
th main.lua --help
```

To train a network using the default settings, simply do:
```bash
th main.lua
```

> Note: You must have the ImageNet ILSVRC2012 dataset (or any other dataset) setup before running this script. For more information about how to setup your datasets using `dbcollection` see [here](https://github.com/dbcollection/dbcollection).

By default, the script trains theAlexNet model on 1 GPU with the CUDNN backend and loads data from disk using 4 CPU threads.

To run an alexnet model using two or more GPUs, set `nGPU` to the number of GPUs you want to use (in this example only two are used):
```bash
th main.lua -nGPU 2 -netType alexnet
```

In case you want to specify which gpus do use, do the following:
```bash
CUDA_VISIBLE_DEVICES=0,1 th main.lua -nGPU 2 -netType alexnet
```

> Note: this will select the first two GPUs detected in your system.

To use more threads for data loading/processing, use the `nThreads` flag to specify the number of threads you want to use.

```bash
th main.lua -nThreads 2
```

For a complete list of available options, please see the `opts.lua` file or run `th main.lua --help` in the command line.

## Data loading benchmark comparison

For most datasets, loading the necessary metadata (filenames, labels, etc.) from disk should carry a very small, almost  insignificant overhead compared to loading metadata from memory.

To showcase this, some scripts under `benchmark/` for the ImageNet ILSVRC2012 and Cifar10 datasets are available for benchmarking this. Here it is used the average time for 1000 data fetches with `batchsize=128` and `nThreads=4`.

The `train` scores use more data augmentation preprocessing compared to the `test` scores which uses less data augmentation techniques.

Dataset | train | test
--- | --- | ---
Cifar10 *(disk)* | 0.01509s | 0.00953s
Cifar10 *(ram)* | **0.00772s**  | **0.00557s**
ILSVRC2012 *(disk)* | 0.34635 | **0.35729**
ILSVRC2012 *(ram)* | **0.34553** | 0.36107

> Note: This tests were done using a 6-core Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz, 32GB ram, 2TB SSHD and Ubuntu 14.04. Note that the overhead is very small when using datasets with bigger images like the Imagenet, meaning that the overhead can be hidden by using enough cores or a faster disk.

## Code Description

- `main.lua` (~250 lines) - Script using torchnet's api for training and testing a network over ImageNet.

- `utils.lua` (~125 lines) - Multi-gpu functions for loading/storing/setting a model.

- `transforms.lua` (~500 lines) - Data augmentation functions, mostly derived from [here](https://github.com/facebook/fb.resnet.torch/blob/master/datasets/transforms.lua) and [here](https://github.com/NVIDIA/DIGITS/pull/777).

- `configs.lua` (~200 lines) - Setup configurations (options, model, logger, etc.)

- `statistics.lua` (~100 lines) - Computes the dataset's mean/std statistics for 10000 samples and stores it to `./cache` dir.

- `model.lua` (~40 lines) - Creates/Loads a model from training/testing.

- `data.lua` (~110 lines) - Contains the methods to featch/load data of the available datasets.

## License

MIT license (see the LICENSE file)

## Disclamer

This code has been inpired on torchnet's [mnist training example](https://github.com/torchnet/torchnet/blob/master/example/mnist.lua), soumith's [multi-gpu ImageNet training code](https://github.com/soumith/imagenet-multiGPU.torch) and @karandwivedi42 [multigpu-torchnet](https://github.com/karandwivedi42/imagenet-multiGPU.torchnet).

repository: farrajota/multi-gpu-torchnet

repo_name: farrajota/multi-gpu-torchnet


text:
# Simple Keyring [![CircleCI](https://circleci.com/gh/MetaMask/eth-simple-keyring.svg?style=svg)](https://circleci.com/gh/MetaMask/eth-simple-keyring)

A simple JS class wrapped around [ethereumjs-wallet](https://github.com/ethereumjs/ethereumjs-wallet) designed to expose an interface common to many different signing strategies to be used in a `KeyringController`; such as the one used in [MetaMask](https://metamask.io/)

## The Keyring Class Protocol

One of the goals of this class is to allow developers to easily add new signing strategies to MetaMask. We call these signing strategies Keyrings, because they can manage multiple keys.

### Keyring.type

A class property that returns a unique string describing the Keyring.
This is the only class property or method, the remaining methods are instance methods.

### constructor( options )

As a Javascript class, your Keyring object will be used to instantiate new Keyring instances using the new keyword.  For example:

```
const keyring = new YourKeyringClass(options);
```

The constructor currently receives an options object that will be defined by your keyring-building UI, once the user has gone through the steps required for you to fully instantiate a new keyring.  For example, choosing a pattern for a vanity account, or entering a seed phrase.

We haven't defined the protocol for this account-generating UI yet, so for now please ensure your Keyring behaves nicely when not passed any options object.

## Keyring Instance Methods

All below instance methods must return Promises to allow asynchronous resolution.

### serialize()

In this method, you must return any JSON-serializable JavaScript object that you like. It will be encoded to a string, encrypted with the user's password, and stored to disk. This is the same object you will receive in the deserialize() method, so it should capture all the information you need to restore the Keyring's state.

### deserialize( object )

As discussed above, the deserialize() method will be passed the JavaScript object that you returned when the serialize() method was called.

### addAccounts( n = 1 )

The addAccounts(n) method is used to inform your keyring that the user wishes to create a new account. You should perform whatever internal steps are needed so that a call to serialize() will persist the new account, and then return an array of the new account addresses.

The method may be called with or without an argument, specifying the number of accounts to create. You should generally default to 1 per call.

### getAccounts()

When this method is called, you must return an array of hex-string addresses for the accounts that your Keyring is able to sign for.

### signTransaction(address, transaction)

This method will receive a hex-prefixed, all-lowercase address string for the account you should sign the incoming transaction with.

For your convenience, the transaction is an instance of ethereumjs-tx, (https://github.com/ethereumjs/ethereumjs-tx) so signing can be as simple as:

```
transaction.sign(privateKey)
```

You must return a valid signed ethereumjs-tx (https://github.com/ethereumjs/ethereumjs-tx) object when complete, it can be the same transaction you received.

### signMessage(address, data)

The `eth_sign` method will receive the incoming data, already hashed, and must sign that hash, and then return the raw signed hash.

### getEncryptionPublicKey(address)

This provides the public key for encryption function.

### decryptMessage(address, data)

The `eth_decryptMessage` method will receive the incoming data in array format that returns `encrypt` function in `eth-sig-util` and must decrypt message, and then return the raw message.

### exportAccount(address)

Exports the specified account as a private key hex string.

### removeAccount(address)

removes the specified account from the list of accounts.

license: ISC

gha_language: JavaScript

gha_license_id: ISC


text:
---
title: "Parameter Estimation and Comparative Analysis of Control Design Techniques for BLDC Hub Motor"
authors:
- Akshit Patel
- Shivanand Pal
- Aditya Jabade
- Kartheek Miduthuru
- B. A. Botre
- Gaurav Sahu
date: "2020-11-11T00:00:00Z"
doi: ""

# Schedule page publish date (NOT publication's date).
publishDate: "2020-11-T00:00:00Z"

# Publication type.
# Legend: 0 = Uncategorized; 1 = Conference paper; 2 = Journal article;
# 3 = Preprint / Working Paper; 4 = Report; 5 = Book; 6 = Book section;
# 7 = Thesis; 8 = Patent
publication_types: ["1"]

# Publication name and optional abbreviated publication name.
publication: In *17th IEEE India Council International Conference*
publication_short: In *STC*

abstract: "Brushless DC (BLDC) motors have become the optimal choice for high-precision controller implementation in industrial applications. This paper presents a detailed analysis of a hub BLDC motor used in low power electric vehicles right from parameter estimation to the implementation of speed control techniques. The parameter estimation is followed by the development of the mathematical model of the BLDC motor. The conventional PID technique and the genetic algorithm-based tuning are applied to the mathematical model. Further physical model of the motor is constructed and simulated for broadly
3 control methods- Conventional PID, Genetic algorithm, and self-tuning Fuzzy logic method. The purpose of the research is to provide a comparative analysis of these control strategies and to identify the optimal one for speed-control of the BLDC hub motor. Results show that the proposed, adaptive Fuzzy logic technique is the best control design for practical implementation."

# Summary. An optional shortened abstract.
summary: In this research, I and my coauthors present a detailed analysis of BLDC-hub motor. The main purpose of this is to provide a comprehensive comparison of conventional, genetic algorithm and self-tuning fuzzy logic PID methods for motor control design.

tags:
- Conference Paper
- IEEE 2020
- BLDC
- Fuzzy Logic
- Genetic Algorithm
featured: true

# links:
# - name: Custom Link
#   url: http://example.org
url_pdf: https://drive.google.com/file/d/1AlPitpcK1fWuT3GuUhN4k3sk7cHXuMFC/view
# url_code: '#'
# url_dataset: '#'
# url_poster: '#'
# url_project: ''
# url_slides: ''
# url_source: '#'
# url_video: '#'

# Featured image
# To use, add an image named `featured.jpg/png` to your page's folder.
image:
  # caption: 'Image credit: [**Unsplash**](https://unsplash.com/photos/pLCdAaMFLTE)'
  caption: '**Motor Model Designed**'
  focal_point: ""
  preview_only: false

# Associated Projects (optional).
#   Associate this publication with one or more of your projects.
#   Simply enter your project's folder or file name without extension.
#   E.g. `internal-project` references `content/project/internal-project/index.md`.
#   Otherwise, set `projects: []`.
projects:
- internal-project

# Slides (optional).
#   Associate this publication with Markdown slides.
#   Simply enter your slide deck's filename without extension.
#   E.g. `slides: "example"` references `content/slides/example/index.md`.
#   Otherwise, set `slides: ""`.
slides: example
---
<!--
{{% alert note %}}
Click the *Cite* button above to demo the feature to enable visitors to import publication metadata into their reference management software.
{{% /alert %}}

{{% alert note %}}
Click the *Slides* button above to demo Academic's Markdown slides feature.
{{% /alert %}}

Supplementary notes can be added here, including [code and math](https://sourcethemes.com/academic/docs/writing-markdown-latex/). -->

repository: Akshit-Patel/Akshit-Patel

repo_name: Akshit-Patel/Akshit-Patel


text:
# Lemon Parser Generator language support

Adds syntax highlighting to [Lemon Parser Generator](http://www.hwaci.com/sw/lemon) files in Atom.

## Notes

This package may conflict with the [language-bison](https://atom.io/packages/language-bison) package for file-type 'y'.

repository: kyursen/language-lemon

repo_name: kyursen/language-lemon


text:
# gdx-mellow-demo

A libGDX demo showcasing a custom shader to achieve sub-pixel perfect smooth scrolling for upscaled 2D games.

For a description, read [my blog post](http://code-disaster.com/2016/02/subpixel-perfect-smooth-scrolling.html).

The tileset used is ["Outdoor tiles, again"](http://opengameart.org/content/outdoor-tiles-again) by [Michele "Buch" Bucelli](http://opengameart.org/users/buch).

repository: jngrow/gdx-mellow-demo

repo_name: jngrow/gdx-mellow-demo