text:
<img align="right" src="https://avatars0.githubusercontent.com/u/21360882?v=3&s=200">

[![Gitter](https://img.shields.io/gitter/room/funkia/General.svg)](https://gitter.im/funkia/General)
[![Build Status](https://travis-ci.org/funkia/io.svg?branch=master)](https://travis-ci.org/funkia/io)
[![codecov](https://codecov.io/gh/funkia/io/branch/master/graph/badge.svg)](https://codecov.io/gh/funkia/io)
[![Dependency Status](https://david-dm.org/funkia/io.svg)](https://david-dm.org/funkia/io)
[![npm version](https://badge.fury.io/js/%40funkia%2Fio.svg)](https://badge.fury.io/js/%40funkia%2Fio)

# IO

## Introduction

`IO` is a structure for expressing imperative computations in a pure
way. In a nutshell it gives us the convenience of imperative
programming while preserving some of the properties of a purely
functional programming. Most notable code that uses IO can be tested
in a purely declarative way without actually running side-effects.

## Table of contents

* [Installation](#installation)
* [Tutorial](#tutorial)
* [API](#api)
* [Contributing](#contributing)

## Features

* Provides a declarative and pure way to express code with side-effects
* Has a nice API for easily testing `IO` code without running side-effects
* Ships with both CommonJS and ES2015 modules for tree-shaking
* Is written in TypeScript so comes with full comprehensive type
  definitions

## Installation

IO can be installed from npm. The package ships with both
CommonJS modules and ES6 modules

```
npm install @funkia/io
```

## Tutorial

### Impure functions

Let's say we have a function `fireMissiles` that takes a number `n`
and then fires `n` missiles. If fewer than `n` missiles are available
then only that amount of missiles is fired. The function returns the
amount of missiles that was successfully fired.

```typescript
function fireMissiles(amount: number): number { ... }
```

Certainly that is a very easy way of firing missiles. But
unfortunately it is also impure. This, among other things, will make
it tricky to test code using `fireMissiles` without actually firing
missiles every time the tests are run.

### `IO` turns impure functions into pure ones

To solve the issue `IO` provides a method called `withEffects`. It
converts `fireMissiles` from an imperative procedure, that actually
fires missiles, to a pure function that merely returns a _description_
about how to fire missiles.

```typescript
const fireMissilesIO = withEffects(fireMissiles);
```

`fireMissilesIO` has the type `(amount: number) => IO<number>`. Here
`IO<number>` means an IO-action that does something and then produces
a value of type `number`. The crucial difference about
`fireMissilesIO` is that it has no side-effects and that it always
return an equivalent IO-action when given the same number. It is pure.

 But it
actually allows us to construct imperative computations in a
functional way. To work with IO-actions we can use the fact that `IO`
is a functor, an applicative and a monad. Thus we can for instance use
it with go-notation.

```javascript
const fireMissilesAndNotify = fgo(function*(amount) {
  const n = yield fireMissilesIO(amount);
  yield sendMessage(`${n} missiles successfully fired`);
  return n;
});
```

Here `sendMessage` has the type `(msg: string) => IO<void>`. It takes
a string and returns an IO-action that sends the specified message.

Notice that the above code _looks_ like imperative code. In a sense it
_is_ imperative code. It's a functional way of writing imperative
code. Since `sendMessage` is pure it satisfies referential
transparency. Instead of this:

```javascript
go(function*() {
  yield sendMessage("foo");
  yield sendMessage("foo");
});
```

We can write this:

```javascript
go(function*() {
  const sendFoo = sendMessage("foo");
  yield sendFoo;
  yield sendFoo;
});
```

If `sendMessage` had been impure this refactoring would not have
worked–the side-effect in `sendMessage` would only have been carried
out once. But since it's pure it's totally fine. In the dumb example
above it only made a small difference but in a real program being able
to perform such refactorings can be very beneficial.

### Asynchronous operations

IO-actions can be asynchronous. This makes it possible to express
asynchronous operations very conveniently. Instead of `withEffects` we
can use `withEffectsP` to turn an impure function that returns a
promise into a pure function.

```javascript
const fetchIO = withEffectsP(fetch);
```

This creates a function with the return value `IO<Response>`. If the
promise returned by the wrapped function rejects the IO-computation
will result in an error. Error handling is described in the next
section.

### Error handling

The `IO` monad comes with error handling features. It works through
the functions `throwE` and `catchE`. They resemble `throw` and `catch`
but instead of being language-features they are built into the `IO`
implementation.

A value of `IO<A>` can not only produce a value of type `A`. It may
also produce an error.

To throw an error inside you use `throwE`:

```javascript
const sendFriendlyMessageTo = fgo(function*(name, message) {
  if (message.indexOf(":)") === -1) {
    yield throwE("Please include a friendly smiley :)");
  }
  const exists = yield checkUserExistence(name);
  if (!exists) {
    yield throwE("User does not exist");
  }
  return yield sendMessageTo(name, message);
});
```

Once an error is `yield`ed the rest of the computation isn't being
run. The resulting `IO` value will produce an error instead of a
value.

To catch an error you use `catchE`. As its first argument it takes a
error function handling. As its second argument it takes an `IO`
computation. It returns a new `IO` computation.

```javascript
const sendFriendlyMessageWithUnfriendlyError(name, message) {
  return catchE(
    (error) => "Some error happened. I won't tell you which!",
    sendFriendlyMessageTo(name, message)
  );
}
```

Here is an example of using `fetchIO` with error handling. Since
parsing the body from a `fetch` response as JSON is an asynchronous
operation we define an additional function `responseJson`.

```javascript
const responseJson = withEffectsP((response) => response.json());

const fetchUsersPet = fgo(function*(userId) {
  const response = yield catchE(
    (err) => throwE(`Request failed: ${err}`),
    fetchIO(usersUrl + "/" + userId)
  );
  if (response.states === 404) {
    yield throwE("User does not exist");
  }
  const body: User = yield responseJson(response);
  if (body.pet === undefined) {
    yield throwE("User has no pet");
  } else {
    return body.pet;
  }
});
```

### Running and testing

An IO-action can be run with the function `runIO`. The function
actually performs the operations in the IO-action and returns a
promise that resolves when it is done or rejects is the `IO` produces
and unhandled error. `runIO` is an impure function.

Besides running IO-actions we can also test them. Or "dry-run" them.
To see how this works consider one of the previous examples with a
small bug added in:

```javascript
const fireMissilesAndNotify = fgo(function*(amount) {
  const n = yield fireMissilesIO(amount);
  yield sendMessage(`${amount} missiles successfully fired`);
  return n;
});
```

The error is that we don't send a message about how many missiles
where actually fired. Instead we send the number of missiles that
where requested to be fired. We can test the function with `testIO`:

```javascript
it("fires missiles and sends message", () => {
  testIO(fireMissilesAndNotify(10), [
    [fireMissilesIO(10), 10],
    [sendMessage(`10 missiles successfully fired`), undefined]
  ], 10);
});
```

The first argument to `testIO` is the IO-action to test. The second is
a list of pairs. The first element in each pair is an IO-action that
the code should attempt to perform, the second element is the value
that performing the action should return. The last argument is the
expected result of the entire computation.

However, the test above doesn't uncover the bug. Let's write another
one that does:

```javascript
it("fires missiles and sends message", () => {
  testIO(fireMissilesAndNotify(10), [
    [fireMissilesIO(10), 5],
    [sendMessage(`5 missiles successfully fired`), undefined]
  ], 5);
});
```

Here we specify that when the code attempts to run `fireMissilesIO(10)`
it should get back the response `5`. After this the next line will
throw because our implementation passes a string to `sendMessage` that
mentions `10` instead of `5`. Therefore `testIO` will throw and our
test will fail.

## API

### `IO.of(a: A): IO<A>`

Converts any value into a IO that will return that value.

### `withEffects((...args) => A): IO<A>`

Converts an impure function into an `IO`

### `withEffectsP(p: Promise<A>): IO<A>`

Converts a Promise into an `IO`

### `throwE(error: any): IO<any>`

Once an error is `yield`ed the rest of the computation isn't being
run. The resulting `IO` value will produce an error instead of a
value.

### `catchE(errorHandler: (error: any) => IO<any>, io: IO<any>): IO<any>`

As its first argument it takes a
error function handling. As its second argument it takes an `IO`
computation. It returns a new `IO` computation.

### `testIO<A>(e: IO<A>, arr: any[], a: A): void`

The first argument to `testIO` is the IO-action to test. The second is
a list of pairs. The first element in each pair is an IO-action that
the code should attempt to perform, the second element is the value
that performing the action should return. The last argument is the
expected result of the entire computation.

## Contributing

Contributions are very welcome. Development happens as follows:

Install dependencies.
```
npm install
```

Run tests.
```
npm test
```
Running the tests will generate an HTML coverage report in `./coverage/`.

Continuously run the tests with
```
npm run test-watch
```

We also use `tslint` for ensuring a coherent code-style.

repository: funkia/io

gha_language: TypeScript

repo_name: funkia/io


text:
# Java

Check if Java is already installed

    $ java -version

If you see an output like below then Java is already installed on your machine so skip the next step.

    java version "1.7.0_55"
    Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
    Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)

If you don't see the output like above then you need to install Java on your system. Please download the OS X version from the [Oracle website](http://www.oracle.com/technetwork/java/javase/downloads/jdk7-downloads-1880260.html).

Check if Java is correctly installed by running the `java -version` command again.

Add `JAVA_HOME` to your environment variables by adding the line below to your `env.sh`.

    export JAVA_HOME="`/usr/libexec/java_home -v 1.7`"

You should have JAVA working now. If you use [Eclipse](https://www.eclipse.org/downloads/) as your Java IDE it'll prompt you to install Java 6, go ahead and click Ok.

license: MIT

repository: mrhaki/mac-setup

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: mrhaki/mac-setup


text:
# Ingestion pipeline

* Status: proposed
* Date: 2022-06-16

## Context and Problem Statement

We would like to add functionality for Bulk Upload to enable the submission of RAW TMSIS provider data in order to support existing operations.

## Considered Options

* AWS Lambda + Python script
* AWS EMR + Spark job

## Decision Outcome

Chosen option: "AWS Lambda + Python script", because AWS Lambda and Python are chosen for the implementation of MVP. Given the size of data and light footprint, a decision was made to leave EMR and Spark for later implementation when size of data is significant.

repository: vbaklikov/ReactiveStocks

repo_name: vbaklikov/ReactiveStocks


text:
Magnum is 2D/3D graphics engine written in C++11 and modern OpenGL.

DESIGN GOALS
============

*   **2D is not an ugly stepchild**
    Many engines out there are either purely 2D or 3D and if you want to do
    your next project in 2D only, you have to either relearn another engine
    from scratch or emulate it in 3D, leaving many things overly complicated.
    Magnum treats 2D equivalently to 3D so you can reuse what you already
    learned for 3D and even combine 2D and 3D in one project.

*   **Forward compatibility**
    If newer technology makes things faster, simpler or more intuitive, it is
    the way to go. If you then really need to, you can selectively backport
    some features and it will be easier than maintaining full backward
    compatibility by default. Magnum by default relies on decent C++11 support
    and modern OpenGL features, but compatibility functions for older hardware
    and compatibility branch for older compilers are available if you need
    them.

*   **Intuitive, but not restrictive API**
    Scripting languages are often preferred to C/C++ because they tend to do
    more with less -- less complicated APIs, nicer syntax and less boilerplate
    code. Magnum is designed with scripting language intuitivity in mind, but
    also with speed and static checks that native code and strong typing
    offers. Usually the most common way is the most simple, but if you need
    full control, you can have it.

*   **Extensible and replaceable components**
    If you want to use different mathematical library for specific purposes,
    that new windowing toolkit, your own file formats or another physics
    library, you can. Conversion of data between different libraries can be
    done on top of pre-made skeleton classes, support for file formats is done
    using plugins and platform support is done by writing simple wrapper class.

SUPPORTED PLATFORMS
===================

*   **OpenGL** 2.1 through 4.3, core profile functionality and modern
    extensions
*   **OpenGL ES** 2.0, 3.0 and extensions to match desktop OpenGL functionality
*   **Linux** and embedded Linux (natively using GLX/EGL and Xlib or through
    GLUT or SDL2 toolkit)
*   **Windows** (through GLUT or SDL2 toolkit)
*   **Google Chrome** (through [Native Client](https://developers.google.com/native-client/),
    both `newlib` and `glibc` toolchains are supported)

FEATURES
========

*   Actively maintained Doxygen documentation with tutorials and examples.
    Snapshot is available at http://mosra.cz/blog/magnum-doc/.
*   Vector and matrix library with implementation of complex numbers,
    quaternions and their dual counterparts for representing transformations.
*   Classes wrapping OpenGL and simplifying its usage with direct state access
    and automatic fallback for unavailable features.
*   Extensible scene graph which can be modified for each specific usage.
*   Plugin-based data exchange framework, tools for manipulating meshes,
    textures and images.
*   Pre-made shaders, primitives and other tools for easy prototyping and
    debugging.

INSTALLATION
============

You can either use packaging scripts, which are stored in `package/`
subdirectory, or compile and install everything manually. Note that Doxygen
documentation (see above or build your own using instructions below) contains
more comprehensive guide for building, packaging and crosscompiling.

Minimal dependencies
--------------------

 * C++ compiler with good C++11 support. Currently there are two compilers
   which are tested to support everything needed: **GCC** >= 4.6 and **Clang**
   >= 3.1.
 * **CMake** >= 2.8.8 (needed for `OBJECT` library target)
 * **GLEW** - OpenGL extension wrangler (only if targeting desktop OpenGL)
 * **Corrade** - Plugin management and utility library. You can get it at
   https://github.com/mosra/corrade.

Compilation, installation
-------------------------

The library (for example with support for GLUT applications) can be built and
installed using these four commands:

    mkdir -p build && cd build
    cmake .. \
        -DCMAKE_INSTALL_PREFIX=/usr \
        -DWITH_GLUTAPPLICATION=ON
    make
    make install

See Doxygen documentation for more information about enabling or disabling
additional features and targeting different platforms such as OpenGL ES.

Building and running unit tests
-------------------------------

If you want to build also unit tests (which are not built by default), pass
`-DBUILD_TESTS=ON` to CMake. Unit tests use Corrade's TestSuite framework and
can be run using

    ctest --output-on-failure

in build directory. Everything should pass ;-)

Building documentation
----------------------

The documentation is written in **Doxygen** (version 1.8 with Markdown support
is used, but older versions should do good job too) and additionally uses
**Graphviz** for class diagrams and **TeX** for math formulas. The
documentation can be build by running:

    doxygen

in root directory (i.e. where `Doxyfile` is). Resulting HTML documentation
will be in `build/doc/` directory. You might need to create `build/` directory
if it doesn't exist yet.

PLUGINS AND EXAMPLES
====================

Various importer plugins for image and 3D model formats are maintained in
separate repository, which can be found at https://github.com/mosra/magnum-plugins.

There are also examples of engine usage, varying from simple *Hello World*-like
example to more advanced applications, such as viewer for complex 3D models.
Example repository is at https://github.com/mosra/magnum-examples.

CONTACT
=======

Want to learn more about the library? Found a bug or want to tell me an
awesome idea? Feel free to visit my website or contact me at:

 * Website - http://mosra.cz/blog/
 * GitHub - https://github.com/mosra/magnum
 * E-mail -<EMAIL_ADDRESS> * Jabber -<EMAIL_ADDRESS>
LICENSE
=======

Magnum is licensed under MIT/Expat license, see [COPYING](COPYING) file for
details.

repository: respu/magnum

repo_name: respu/magnum


text:
SAT5P Setup
===========

nectar Deployment
-----------------

### Server creation

Create instance `sat5p-server-1` from nectar official *NeCTAR CentOS 7 x86_64* image, create `sat5p-sites` volume, and attach volume to instance.

Configure access:

* provide SSH key to Nectar and attach to instance, or another user adds manually
* Nectar menu *Compute* > *Access & Security* > default *Manage Rules*
    * add Ingress rules for HTTP and HTTPS with open CIDR (`<IP_ADDRESS>/0`)
    * add an Ingress rule for SSH and the CIDR spec for your institution:
        * JCU: `<IP_ADDRESS>/16`
        * CQU: `??`

Connect via SSH as `ec2-user`, using something like this:

```
ssh<EMAIL_ADDRESS>```

Partition and format attached volume using `fdisk` and `mkfs.ext4`, add to `/etc/fstab` with something like:

```
/dev/vdb1	/mnt/sites	ext4	defaults,noatime	0	2
```

#### Project init

Install git and use it to clone the project's repository:

```
sudo yum install -y git
cd ~
git clone https://github.com/DanielBaird/self-assessment-tool.git
```

#### Web serving

Install `nginx` and set it up to start automatically

```
yum install -y nginx
systemctl enable nginx
```

This config file will try to find a directory in `/mnt/sites/` for any subdomain, so to create a new subdomain, all that is required is to add a subdirectory into `sites`, and add the domain to your [Let's Encrypt](https://letsencrypt.org) / [certbot](https://certbot.eff.org) certificate.

Create directories for the sites we're serving, add default content, and give them to the `nginx` user.

TODO: remember to get a clean "default" set into the repo

```
cd /mnt/sites
mkdir jcu jcu-test cqu cqu-test federation federation-test usc usc-test csu csu-test
sudo cp -r ~/self-assessment-tool/clientside/* /mnt/sites/cqu/
sudo cp -r ~/self-assessment-tool/clientside/* /mnt/sites/cqu-test/
sudo cp -r ~/self-assessment-tool/clientside/* /mnt/sites/jcu/
sudo cp -r ~/self-assessment-tool/clientside/* /mnt/sites/jcu-test/
sudo cp -r ~/self-assessment-tool/clientside/* /mnt/sites/federation/
sudo cp -r ~/self-assessment-tool/clientside/* /mnt/sites/federation-test/
sudo cp -r ~/self-assessment-tool/clientside/* /mnt/sites/usc/
sudo cp -r ~/self-assessment-tool/clientside/* /mnt/sites/usc-test/
sudo cp -r ~/self-assessment-tool/clientside/* /mnt/sites/csu/
sudo cp -r ~/self-assessment-tool/clientside/* /mnt/sites/csu-test/
sudo chown --recursive nginx:nginx /mnt/sites
```

We also need a directory for `certbot` to drop its challenge files.

```
mkdir /usr/share/nginx/html/letsencrypt
mkdir /usr/share/nginx/html/letsencrypt/.well-known
mkdir /usr/share/nginx/html/letsencrypt/.well-known/acme-challenge
```

Copy the nginx configuration files into place, and run Nginx's config tester.  You will need to edit the `sat5psites.conf` file once you have generated your certificates.

```
cp /home/ec2-user/self-assessment-tool/serverside/nginx.conf /etc/nginx/
cp /home/ec2-user/self-assessment-tool/serverside/sat5psites.conf /etc/nginx/conf.d/
nginx -t
```

#### Certificates for `https`

Install `certbot` for Nginx, and run it to generate a certificate

```
yum install -y certbot-nginx

## for sat5p.jcu.io domain..
certbot certonly --webroot --webroot-path /usr/share/nginx/html/letsencrypt --domains sat5p.jcu.io,jcu.sat5p.jcu.io,jcu-test.sat5p.jcu.io,cqu.sat5p.jcu.io,cqu-test.sat5p.jcu.io,federation.sat5p.jcu.io,federation-test.sat5p.jcu.io,usc.sat5p.jcu.io,usc-test.sat5p.jcu.io,csu.sat5p.jcu.io,csu-test.sat5p.jcu.io

## for sat5p.jcu.io domain AND uniprep.net.au domain..
certbot certonly --webroot --webroot-path /usr/share/nginx/html/letsencrypt --domains sat5p.jcu.io,jcu.sat5p.jcu.io,jcu-test.sat5p.jcu.io,cqu.sat5p.jcu.io,cqu-test.sat5p.jcu.io,federation.sat5p.jcu.io,federation-test.sat5p.jcu.io,usc.sat5p.jcu.io,usc-test.sat5p.jcu.io,csu.sat5p.jcu.io,csu-test.sat5p.jcu.io,uniprep.net.au,jcu.uniprep.net.au,jcu-test.uniprep.net.au,cqu.uniprep.net.au,cqu-test.uniprep.net.au,federation.uniprep.net.au,federation-test.uniprep.net.au,usc.uniprep.net.au,usc-test.uniprep.net.au,csu.uniprep.net.au,csu-test.uniprep.net.au

## for uniprep.net.au domain..
certbot certonly --webroot --webroot-path /usr/share/nginx/html/letsencrypt --domains uniprep.net.au,jcu.uniprep.net.au,jcu-test.uniprep.net.au,cqu.uniprep.net.au,cqu-test.uniprep.net.au,federation.uniprep.net.au,federation-test.uniprep.net.au,usc.uniprep.net.au,usc-test.uniprep.net.au,csu.uniprep.net.au,csu-test.uniprep.net.au

##
## enter your email for alerts, agree to Let's Encrypt conditions, etc
##
```

Now edit the `sat5psites.conf` file and un-comment the two lines that point to the certificates certbot just generated for you.

```
vi /etc/nginx/conf.d/sat5psites.conf
# ...un-comment the certificate lines...
```

repository: jcu-eresearch/uniprep

repo_name: jcu-eresearch/uniprep


text:
# Data Source Directives

All of these use Stitch's [parameter injection](./parameter_injection.md) syntax.

## `@rest`

`@rest` fetches data from a REST/HTTP endpoint. Usage examples:

```graphql
type Query {
  allUsers: [User!] @rest(url: "http://user-service/users")

  userById(userId: ID!): User @rest(url: "https://user-service/users/{args.userId}")

  userById(userId: ID!): User
    @rest(url: "https://old-user-service/getUser", query: [{ key: "id", value: "{args.userId}" }])
}

type Mutation {
  createUser(body: UserInput!): User @rest(url: "https://user-service/users", method: "POST", bodyArg: "body")
}
```

Full parameters:

```graphql
input KeyValue {
    key: String!
    value: String!
}

directive @rest(
    url: String!
    method: String      # Defaults to GET
    bodyArg: String     # Defaults to "input"
    query: [KeyValue!]
    headers: [KeyValue!]
    timeoutMs: Int      # Defaults to 10 seconds
)
```

## @gql

`@gql` lets you "embed" a query on a remote GraphQL server into a Stitch resolver. It's not a full federation solution (coming soon!), but it let's you do most things you'd want to with a remote GraphQL endpoint.

Standard GraphQL subselections, aliases, variables, etc are all fully supported (relies on `graphql-tools`'s [Remote Schemas](https://www.apollographql.com/docs/graphql-tools/remote-schemas/))

Examples:

```graphql
# Remote graphql server
type User {
    id: ID!
    name: String!
}

type Query {
    getUsersNamed(name: String!): [User]
}

# Stitch
type Query {
    allUsersNamedAviv: @gql(
        url: "http://remote-user-service/graphql",
        fieldName: "getUsersNamed",
        arguments: {name: "aviv"})

    getUsersByName(userName: String!): @gql(
        url: "http://remote-user-service/graphql",
        fieldName: "getUsersNamed",
        arguments: {name: "{args.userName}"})
}
```

Full parameters:

```graphql
enum GraphQLOperationType {
    Query
    Mutation
}

directive @gql(
    url: String!
    fieldName: String!
    operationType: GraphQLOperationType
    arguments: JSONObject
)
```

## @localResolver

`@localResolver` lets you create a stub resolver, but make no mistake - this can be used with full parameter injection syntax to create complex resolvers.

The optional `mergeStrategy` parameter allows choosing between replacing/merging/deep merging with the existing resolver value for the field. The `Replace` strategy is used by default.

Example of replacing the existing resolver value:

```graphql
type Query {
  isAlive: Boolean @localResolver(value: true)
  jsonEcho(input: JSON!): JSON @localResolver(value: { wrapper: "{args.input}" })
}

type User {
  firstName: String!
  lastName: String!
  fullName: String! @localResolver(value: "{source.firstName} {source.lastName}")
}
```

Example of merging with the existing resolver value:

```graphql
type User {
    firstName: String!
    lastName: String!
    fullName: String // not supplied by the resolver
}

type Query {
    getUser: User! @localResolver(value: { fullName: "${source.firstName} ${source.lastName}" }, mergeStrategy: Merge)
}
```

Full parameters:

```graphql
enum LocalResolverMergeStrategy {
    Replace
    Merge
    MergeDeep
}

directive @localResolver(
    value: JSON!
    mergeStrategy: LocalResolverMergeStrategy = Replace
)
```

## @export

See [Parameter Injection](./parameter_injection.md#exports) for details

## @stub (Deprecated, use @localResolver instead)

`@stub` lets you create a stub resolver, but make no mistake - this can be used with full parameter injection syntax to create complex resolvers. Examples:

```graphql
type Query {
  isAlive: Boolean @stub(value: true)
  jsonEcho(input: JSON!): JSON @stub(value: { wrapper: "{args.input}" })
}

type User {
  firstName: String!
  lastName: String!
  fullName: String! @stub(value: "{source.firstName} {source.lastName}")
}
```

Full parameters:

```graphql
directive @stub(value: JSON!)
```

repository: jefftougas/stitch

gha_license_id: MIT

repo_name: jefftougas/stitch


text:
---
id: 5298
title: Lex I
date: 2021-04-06T19:24:59+00:00
author: Laima
layout: post
guid: https://ukdataservers.com/lex-i/
permalink: /04/06/lex-i/
---

* some text
{: toc}

## Who is Lex I

Part-time YouTuber who posts gaming videos often related to zombies to his channel MrTLexify, where he has over 1.4 million subscribers.

## Prior to Popularity

He was looking for community members to play with online and started to receive YouTube traction in less than 2 years.

## Random data

He frequently posts Call of Duty zombies videos and added Grand Theft Auto 5 videos to his repertoire in 2015.

## Family & Everyday Life of Lex I

He was born in Manitoba, Canada, and has a dog named Patrick.

## People Related With Lex I

His closest partners on YouTube are ToProForUGames and TheSmithPlays.

branch_name: refs/heads/main


text:
Backscratcher
=============

Backscratcher Game from the ITP Show Winter 2013

This is a game for Processing 2.1.

To play in an ideal situation, you will need:

1. An ordinary backscratcher
2. A brightly colored peice of tape to put on the backscratcher
3. A USB webcam with a long cord and/or a USB extension cord, or a mirror, maybe

You don't need all those items to play, but without them, you're just killing spiders with your mouse, which is infinitely less fun.

If you do want to play the game with a backscratcher, set up your camera so it's behind you, so you can see your own back on your computer screen (or projector or monitor).

When you launch the game for the first time, Processing lists the available cameras.  If you're on a laptop, the internal webcam is probably zero.  In my case, external webcams tended to be listed at 15.  You need to manually change the number of the camera in the sketch to the camera you intend to use.

You also need to change the sketch size in the setup loop to match your camera's resolution.

Once you've got your camera up and running, there are two steps to setting up the game to start:

1.  Click and drag from left to right to draw a box around the player's back.  So first click on their left shoulder, and then drag down diagonally to the right.  The program counts mouse clicks, so it's important to only click twice.
2.  Next, have the player hold the backscratcher so you the camera can "see" the colored tape.  Click on that color, and that will be the color that gets tracked and used as a weapon.

The sketch is set up so you can use the mouse in case the color tracker doesn't work.

The color tracker works best with adequate lighting and as few competing colors as possible.  For example, if you put a black dot on the backscratcher and have black hair, the color tracker will jump back and forth from the backscratcher to your hair.  Any black objects also in the frame will cause the color tracker to be inaccurate.

This code (as of Dec. 17, 2013) has some problems, and I hope github can help me out.

repository: ErinFinnegan/Backscratcher

repo_name: ErinFinnegan/Backscratcher


text:
# Tracker Hooks

This library is a collection (so far, just one, post-receive) to help integrate a `git` repository with Pivotal Tracker.

Tracker API: [https://www.pivotaltracker.com/help/api#scm_post_commit](https://www.pivotaltracker.com/help/api#scm_post_commit)

## Installation

1. Anywhere

    ```sh```
    git clone git://github.com/kmayer/tracker-hooks.git

2. In your git repository's hook directory (i.e. `.git/hooks`)

    ```sh```
    cat > post-receive <<-SH
    #!/usr/bin/env sh

    # REQUIRED
    export TRACKER_TOKEN=<your Pivotal Tracker API token>

    # optional
    #   @@REVISION@@ will be replaced with the full git sha
    export REPOS_URL="http://example.com/path/to/your/repos/@@REVISION@@"

    exec /the/path/to/tracker-hooks/bin/post-receive
    SH

Make sure that `post-receive` is `chmod 0755`

## Testing

I use [roundup](https://github.com/ohrite/roundup) for testing:

    git submodule init
    git submodule update
    gem install bundler
    bundle
    vendor/roundup/roundup.sh

Will run the test suite.

There is a [guard](http://github.com/hawx/guard-shell) file, too.

### Integration Testing

There's an integration test that will create a local & remote repository, and confirm that the commits were sent to pivotaltracker.com in the proper order.

If you set:

    TRACKER_TOKEN
    #and optionally
    TRACKER_STORY

To your Pivotal Tracker API token and a test story, respectively, then you will see the test commits post updates to the story.

## Contributing

1. Fork on github
2. Branch
3. Write tests & code
5. Push to github
6. Pull request

repository: kmayer/tracker-hooks

repo_name: kmayer/tracker-hooks


text:
# New Project Steward Required!
### This project needs a new maintainer or someone to continue taking it forward. I put a lot of effort and passion to deliver not just a functional but also a beautifully designed and written piece of code. Unfortunately other commitments have crept up over the years, thus I hope someone just as passionate can take over.

## CLUnit

CLUnit is a Common Lisp unit testing framework. It is designed to be easy to use so that you can quickly start testing.

Author: Tapiwa Gutu

CLUnit provides a rich set of features aimed at improving your unit testing experience:
+ Multiple inheritance for test suites allows you to group tests into hierarchies.
+ Composes the test results of each test run into a single report.
+ Allows redefinition of inline functions and macros without having to redefine your tests.
+ Supports composable test suite fixtures.
+ Allows for an interactive testing process which gives you access to the test environment.
+ Provides visual feedback of the unit test progress.
+ Extensible test reporting. Builtin support for default reporting and [TAP][2] output.
+ Released under MIT license

Check out the comprehensive [CLUnit Tutorial][1].

# Example

```cl
(ql:quickload "clunit")
(use-package :clunit)

;; Test suite for all number operation tests.
(defsuite NumberSuite ())

;; Test suite for floating point operations
(defsuite FloatSuite (NumberSuite))

(defsuite IntegerSuite (NumberSuite))

;; Define a test called TEST-INT1
(deftest test-int1 (IntegerSuite)
    (assert-true  (= 1 1))
    (assert-equalp 4 (+ 2 2)))

;; Define a test called TEST-FLOAT1
(deftest test-float1 (FloatSuite)
    (assert-true (= 1.0 -1.0))
    (assert-equalp 4.0 (+ 2.0 2.0)))

(print (run-suite 'NumberSuite))

```

which produces the output:

```
PROGRESS:
=========

    NUMBERSUITE: (Test Suite)

        INTEGERSUITE: (Test Suite)
            TEST-INT1: ..

        FLOATSUITE: (Test Suite)
            TEST-FLOAT1: F.

FAILURE DETAILS:
================

    NUMBERSUITE -> FLOATSUITE: (Test Suite)
        TEST-FLOAT1: Expression: (= 1.0 -1.0)
                     Expected: T
                     Returned: NIL

SUMMARY:
========
    Test functions:
        Executed: 2
        Skipped:  0

    Tested 4 assertions.
        Passed: 3/4 ( 75.0%)
        Failed: 1/4 ( 25.0%)
```

(if you are entering forms in the REPL, the ``print`` form is not usually needed).

# Tests and assertions

Each test, like ``test-int1`` in the above example, can contain a number of assertions, given in the table below:

| Assertion                                  | Description                                                      |
| ------------------------------------------ | ---------------------------------------------------------------- |
| ``assert-true EXPRESSION``                 | Passes if the expression ``EXPRESSION`` is not ``NIL``           |
| ``assert-false EXPRESSION``                | Passes if ``EXPRESSION`` is ``NIL``                              |
| ``assert-eq VALUE EXPRESSION``             | Passes if ``(EQ VALUE EXPRESSION)`` returns true                 |
| ``assert-eql VALUE EXPRESSION``            | Passes if ``(EQL VALUE EXPRESSION)`` returns true                |
| ``assert-equal VALUE EXPRESSION``          | Passes if ``(EQUAL VALUE EXPRESSION)`` returns true              |
| ``assert-equalp VALUE EXPRESSION``         | Passes if ``(EQUALP VALUE EXPRESSION)`` returns true             |
| ``assert-equality TEST VALUE EXPRESSION``  | Passes if ``(FUNCALL TEST VALUE EXPRESSION)`` returns true       |
| ``assert-equality* VALUE EXPRESSION``      | Passes if  ``(FUNCALL \*clunit-equality-test\* VALUE EXPRESSION)`` returns true. By default *clunit-equality-test* is ``EQUALP`` |
| ``assert-expands EXPANSION EXPRESSION``    | Tests macro expansion, passes if ``(EQUALP EXPANSION (MACROEXPAND-1 EXPRESSION))`` is true        |
| ``assert-condition CONDITION EXPRESSION``  | Passes if ``EXPRESSION`` signals ``CONDITION``                   |
| ``assert-fails FORMAT-STRING``             | Force test to fail, giving a format string for the message       |

All of these tests take optional forms, which are evaluated and printed if the test fails.
These can be used to provide test diagnostics or documentation. For example

```cl

(deftest test-suiteless ()
    (let ((a 1) (b 2) (c 3))
        (assert-true (= a b c) "This assertion is meant to fail." a b c )))

(run-test 'test-suiteless :report-progress nil)
```
produces the output:

```
FAILURE DETAILS:
================
    TEST-SUITELESS: Expression: (= A B C)
                    Expected: T
                    Returned: NIL
                    This assertion is meant to fail.
                    A => 1
                    B => 2
                    C => 3

SUMMARY:
========
    Test functions:
        Executed: 1
        Skipped:  0

    Tested 1 assertion.
        Passed: 0/1 (  0.0%)
        Failed: 1/1 (100.0%)
        Errors: 0/1 (  0.0%)
```

(if not in a REPL, you may have to print the return value of ``run-test``).

[1]: http://tgutu.github.com/clunit  "CLUnit"
[2]: http://en.wikipedia.org/wiki/Test_Anything_Protocol "Test Anything Protocol"

repository: jduhamel/clunit

repo_name: jduhamel/clunit


text:
# Transfer Learning Lab with VGG, Inception and ResNet
[![Udacity - Self-Driving Car NanoDegree](https://s3.amazonaws.com/udacity-sdc/github/shield-carnd.svg)](http://www.udacity.com/drive)

## Overview

We use Keras to explore feature extraction with the VGG, Inception and ResNet architectures. The models used were trained for days or weeks on the [ImageNet dataset](http://www.image-net.org/). Thus, the weights encapsulate higher-level features learned from training on thousands of classes.

To perform feature extration we use two datasets:

1. [German Traffic Sign Dataset](http://benchmark.ini.rub.de/?section=gtsrb&subsection=news)
2. [Cifar10](https://www.cs.toronto.edu/~kriz/cifar.html)

Without a powerful GPU, running feature extraction on these models will take a significant amount of time. To make things easier we precomputed **bottleneck features** for each (network, dataset) pair, this will allow experimenting with feature extraction even on a modest CPU. Because the base network weights are frozen during feature extraction, the output for an image will always be the same. Thus, once the image has already been passed once through the network we can cache and reuse the output.

The training and validation files are encoded as such:

- {network}_{dataset}_bottleneck_features_train.p
- {network}_{dataset}_bottleneck_features_validation.p

Where:

- **network** can be one of 'vgg', 'inception', or 'resnet'

- **dataset** can be on of 'cifar10' or 'traffic'

## Getting Started

The project requires various libraries to be installed in your environment first, in particular:

- Python 3
- TensorFlow
- Keras
- NumPY
- SciPy

You'll also need the bottleneck features for the various networks:

- [VGG Features](http://video.udacity-data.com.s3.amazonaws.com/topher/2016/November/5834b432_vgg-100/vgg-100.zip)
- [ResNet Features](http://video.udacity-data.com.s3.amazonaws.com/topher/2016/November/5834b634_resnet-100/resnet-100.zip)
- [Inception Features](http://video.udacity-data.com.s3.amazonaws.com/topher/2016/November/5834b498_inception-100/inception-100.zip)

## Feature Extraction

The [feature_extraction.py]{./feature_extraction.py} will train feature extraction with the files in input, in particular it accepts the following parameters:

- --training_file: The pickle file to use for training
- --validation_file: The pickle file to use for validation
- --epochs: The number of epochs to train for (default 50)
- --batch_size: The size of the minibatch (default 256)

For example:

```bash
python feature_extraction.py \
--training_file vgg_cifar10_100_bottleneck_features_train.p \
--validation_file vgg_cifar10_bottleneck_features_validation.p
```

Would train the VGG network with the Cifar10 dataset bottleneck features. The 100 in vgg_cifar10_100 indicates this file has 100 examples per class (See [shrink.py](./shrink/py)):

```bash
Epoch 50/50
1000/1000 [==============================] - 0s - loss: 0.2358 - acc: 0.9510 - val_loss: 0.8924 - val_acc: 0.7102
```

Running the same with the inception and the resnet we would get a similar output:

```bash
python feature_extraction.py \
--training_file inception_cifar10_100_bottleneck_features_train.p \
--validation_file inception_cifar10_bottleneck_features_validation.p

Epoch 50/50
1000/1000 [==============================] - 0s - loss: 0.0897 - acc: 1.0000 - val_loss: 1.0422 - val_acc: 0.6608

python feature_extraction.py \
--training_file resnet_cifar10_100_bottleneck_features_train.p \
--validation_file resnet_cifar10_bottleneck_features_validation.p

Epoch 50/50
1000/1000 [==============================] - 0s - loss: 0.0755 - acc: 1.0000 - val_loss: 0.8027 - val_acc: 0.7315

```

We can do the same on the german traffic sign dataset (e.g. in the following using ResNet):

```bash
python feature_extraction.py \
--training_file resnet_traffic_100_bottleneck_features_train.p \
--validation_file resnet_traffic_bottleneck_features_validation.p

Epoch 50/50
4300/4300 [==============================] - 0s - loss: 0.0327 - acc: 1.0000 - val_loss: 0.6112 - val_acc: 0.8103
```

repository: marcomarasca/SDCND-Transfer-Learning

repo_name: marcomarasca/SDCND-Transfer-Learning


text:
# Doorbell via Wemos and optocoupler

This is the new version of my [initial doorbell project](https://github.com/tIsGoud/Doorbell-via-Wemos/).
The main goal is to determine if the doorbell was pressed and perform some actions based on it.

I could have made a version 2.0 of the initial setup but that did not feel right. The hardware and the software are very different.

The setup for this version was inspired by an article in the German c't magazine (2017/17).
In the German magazine an optocoupler is used to separate the doorbell from a Raspberry Pi.

In version 1 I used the analog port(A0) on the Wemos to read out the voltage, this version receives a signal from the optocoupler that is read on a digital port.
A nice galvanic separation between the two circuits, thereby protecting the Wemos.

As in the previous version the main requirements is that I do not want to mess with the existing doorbell installation or have a dependency on extra components.

The standard Dutch doorbell installation:

![Dutch standard doorbell installation](img/standard_doorbell_installation.png)

Once the doorbell-button is pressed, the "signal" is send to the Wemos. The Wemos is connected to MQTT via the local Wi-Fi.
Home Assistant picks up the signal from MQTT. From there it's up to your imagination what you want to do with the input.
For now I send a message to a Slack-bot to notify me.

![From button press to HA via MQTT](img/from_button_to_HA_via_MQTT.png)

## Hardware v2.0

For the initial setup we need the following parts:
- Resistor, 330Ω
- Diode, 1N4148
- Optocoupler, PC817

The resistor lowers the voltage, the diode "flattens" the signal and the optocoupler sends the signal to the Wemos on port(D3/GPIO0).

![Hardware setup v2.0](img/hardware_setup_v2.0.png)

The value read on port D3 is by default 1, pressing the doorbell drops the signal to 0. Not what I initially expected but this is how it works.

Another learning point was how to connect the optocoupler. On the surface there is a "dot", this indicates port 1, the anode that connects to the doorbell. The emitter and collector are connected to the Wemos.

![Optocoupler](img/optocoupler.png)

On the breadbord the setup is nice and simple.

![Breadbord 2.0](img/breadbord_v2.0.jpg)

## Software v2.0

On the Wemos I use [Homie for ESP8266](https://github.com/marvinroger/homie-esp8266) to:
- Connect and stay connected to the Wi-Fi
- Connect and stay connected to MQTT
- Send data to MQTT

The [Wemos D1 mini BasicIO example](https://github.com/wemos/D1_mini_Examples/tree/master/examples/01.Basics/BasicIO) shows how to read the input pin (D3).
In the example the input pin is set to INPUT, this could lead to a "floating" signal. To prevent that we set it to INPUT_PULLUP.

Pressing the doorbell button lights up the Wemos onboard led. A nice visual feedback, convenient during development.

The input pin D3 is read in a loop with a delay defined in the variable "readDelay". Otherwise it would be polling constantly. The readDelay with a value of 50 works fine, with higher values and pressing the button multiple times or constantly somehow destabilizes the system. Annoying, although only temporary.

To prevent multiple triggers when the button is either pressed very long or multiple times I use the "buttonPressDelay" variable. Setting "buttonPressDelay" to a value of 3 to 5 seconds works fine and results in just one trigger.

The readDelay and buttonPressDelay values are set in milliseconds.

## Home Assistant configuration

I use [Home Assistant](https://home-assistant.io/) for home automation.
Below are the parts of the Home Assistent configuration that handle the MQTT message and send me a notification via Slack:

```
automation:
- alias: "Doorbell pressed"
  hide_entity: True
  trigger:
    platform: mqtt
    topic: wemos/doorbell/button/pressed
    payload: 'true'
  action:
    service: notify.Slack
    data:
      message: "Someone at the door!"
      title: "Doorbell says ..."
 ```

 ```
 notify:
  - name: Slack
    platform: slack
    api_key: !secret Slack_API-key
    username: !secret Slack_Username
    default_channel: '#hass'
    icon: ':house:'
```


text:
[![NPM Version](https://img.shields.io/npm/v/@page-libs/page.svg)](https://npmjs.org/package/@page-libs/page)
[![Build Status](https://travis-ci.org/Guseyn/page.svg?branch=master)](https://travis-ci.org/Guseyn/page)
[![codecov](https://codecov.io/gh/Guseyn/page/branch/master/graph/badge.svg)](https://codecov.io/gh/Guseyn/page)

**Page** can be described as a base for any applications on top of it with server and client in Node.js. It provides a lot of features and common scenarios for using web. It's completely based on the [Async Tree Pattern](https://guseyn.com/pdf/Async_Tree_Pattern.pdf) that allows you to customize **Page** in any way you want, you can even throw it away and build other base core for your application.

In another words, **Page** is just an example of how you can build your application using libraries which are based on [cutie](https://github.com/Guseyn/cutie).

# Contents

- [Basic Concepts](#basic-concepts)
- [How to Start (page-cli)](#how-to-start-page-cli)
- [Project Structure](#project-structure)
- [Building Process](#building-process)
- [Running Process](#running-process)
- [Build Project](#build-project)
- [Run Project](#run-project)
- [Test Project](#test-project)
- [List Of Libraries For Page](#list-of-libraries-for-page)
  - [page-cutie](#page-cutie)
  - [page-ajax](#page-ajax-based-on-page-cutie)
  - [page-unit](#page-unit)
  - [page-static-generator](#page-static-generator-based-on-cutie)
  - [page-md2html](#page-md2html-based-on-cutie)
- [Build System](#build-system)
- [Future plans](#future-plans)

# Basic Concepts

1. **Page Is Not a Regular Framework.** Almost every framework is made with assumption that we live in ideal world, but it's very far from the truth. It's not possible to build something big and stable using *magic*, which every framework is based on. Meanwhile, **Page** allows you to control the whole behaviour of your application and apply new changes in a explicit way.

2. **It's Not Easy to Start Quickly.** First of all you need to get acquainted with [Async Tree Pattern](https://github.com/Guseyn/async-tree-patern/blob/master/Async_Tree_Patern.pdf) and it's [implementation](https://github.com/Guseyn/cutie). It allows to build everything using pure approach in OOP.  Also, you must know how [Node.js](https://nodejs.org/en/docs/) works and it's important to understand how non-blockinng i/o works there.

3. **But It's Very Easy to Continue.** Ones you've learnt how to use [Async Tree Pattern](https://github.com/Guseyn/async-tree-patern/blob/master/Async_Tree_Patern.pdf), libraries that are based on [cutie](https://github.com/Guseyn/cutie) and libraries for **Page**, your life will be never like before. You'll able to intoduce new changes into your code extremely fast and painless(unlike in other frameworks).

4. **No Unnecessary Complexity.** Only *html*, *css* and *js* (*server side* and *browser*).

5. **Small Core.** **Page** is almost based on little pieces from different libraries that can be easily combined with each other for building appication. It makes **Page** lightweight and easily extensible.

# How To Start (page-cli)

First of all you need to download this repository to your local machine. You can do it via github or **page-cli**. We suggest you to use the last option, because it also makes building and running of your application much easier.

## Installation Instructions

1. Install [page-cli](https://github.com/Guseyn/page-cli): **`npm install @page-libs/cli -g`**
5.  Create project: **`page create`**
7. Then you'll have to enter some information about your project (`Project name`, `Version`, `Author`, `Description`, `License`), you'll get this repository with changed *package.json* and removed *.git* directory (so you can bind it to your project on github).
8. Go to your project directory: **`cd <projectName>`**
9. Install dependencies: **`npm install`**

## Update Instructions

1. Go to your project directory: **`cd <project_name>`**
2. Update version of framework: **`page update`**, this command just updates versions of components in your *package.json*
3. Install new dependencies: **`npm install`**

## Test Instructions

1. Go to your project directory: **`cd <project_name>`**
2. Run tests: **`page test`** (it runs **`npm test`**)

## Build Instructions

**`page build [environment]`** or **`page b [environment]`** (`environment` is `local` by default)

## Run Instructions

**`page run [environment]`** or **`page r [environment]`** (`environment` is `local` by default)

## Build&Run

**`page br [environment]`** (`environment` is `local` by default)

# Project Structure

```bash
├── ProjectName
│   ├── async
│   ├── pages
│   │   ├── **/*.js
│   ├── server
│   │   ├── async
│   │   ├── endpoints
│   │   ├── events
│   │   ├── api.js
│   │   ├── run.js
│   │   ├── tunedWatchers.js
│   ├── static
│   │   ├── css
│   │   │   ├── **/*.css
│   │   ├── html
│   │   │   ├── **/*.html
│   │   ├── image
│   │   │   ├── **/*.{jpg,png,..}
│   │   ├── js
│   │   │   ├── **/*.js
│   │   ├── txt
│   │   │   ├── **/*.txt
│   │   ├── ...
│   ├── templates
│   │   ├── **/*.html
│   ├── test
│   ├── ├── server
│   ├── ├── ├── files
│   ├── ├── ├── ├── **/*.{html, js}
├── ├── ├── ├── **/*.js
│   ├── .babelrc
│   ├── .eslintrc.json
│   ├── build.js
│   ├── .gitignore
│   ├── config.json
│   ├── Gruntfile.js
│   ├── LICENSE
│   ├── package-lock.json
│   ├── package.json
│   ├── README.md
│   ├── test.js

```

## `async` directory

This directory contains async objects for the whole application.

## `pages` directory

This directory contains js scripts that generate static html pages(they are based on [page-static-generator library](https://github.com/Guseyn/page-static-generator)).

## `server` directory

This directory contains server part of the application. It contains [build script](https://github.com/Guseyn/page/blob/master/server/app/build.js) and [run script](https://github.com/Guseyn/page/blob/master/server/app/run.js).

## `server/async` directory

This directory contains async objects that we use in `server/build.js` and `server/run.js`.

## `server/endpoints`

This directory contains endpoints for REST API.

## `server/events`

This directory contains events for different purposes.

## `static` directory

This directory contains static files, each type of files is stored in the corresponding subdirectory(`html`, `js` and so on). You can also add subdirectories for different extensions. Just don't forget to configure it in the [running process](https://github.com/Guseyn/page/blob/master/server/app/run.js).

## `templates` directory

This directory contains html tepmlates(components) for generating pages.

## `test` directory

This directory contains tests on async objects in `server` directory.

## `config.json`

`config.json` contains all settings of **Page**. Use following async composition for retrieving values from config in the code:

```js
const { ParsedJSON, Value } = require('@cuties/json')
const { ReadDataByPath } = require('@cuties/fs')

new ParsedJSON(
  new ReadDataByPath('./config.json')
).as('config').after(
  /*
    now you can use following composition
      for retrieving concrete value from config
  */
  new Value(as('config'), 'somePropertyName')
).call()

```

### Properties in `config.json`

#### page

```json
"page": {
  "version": "1.0.0",
  "logoText": "./static/txt/logo.txt",
  "logoImage": "./static/image/logo.png",
  "logoImageSrc": "/../image/logo.png"
}
```

This property contains object with information about **Page**: current version, path to the logo in the text format and image format, also image address of the logo.

#### index, indexHref

These properties point to the index page. `index` is for location of the index page in the file system and `indexHref` is for link address of the index page.

#### static

This property is for location of the directory of static files.

#### staticGenerators

This property is for location of the directory with static genrators.

#### templates

This property is for location of the directory with templates.

#### staticHtml

This property is for location of the directory of static files with `html` extension.

#### staticJs

This property is for location of the directory of static files with `js` extension (*es6*).

#### outStaticJs

This property is for location of the directory of static files with `js` extension(for using in a browser).

#### bundle

This property is for location of the bundle file that is generated from `outStaticJs` directory.

#### bundleHref

This property is for link of the bundle file.

#### minBundle

This property is for location of the minified version of the bundle file.

#### minBundleHref

This property is for link of the minified bundle file.

#### enviroments(local, prod, dev, stage, prod)

Every environment property includes `protocol, port, host, clusterMode`. You can also add your own environments and environment properties (for example, if you use `https` for `protocol`, you might need `cert` and `key` properties).

```json
"local": {
  "protocol": "http",
  "port": 8000,
  "host": "<IP_ADDRESS>",
  "clusterMode": true
},
"dev": {
  "protocol": "http",
  "port": 8000,
  "host": "<IP_ADDRESS>",
  "clusterMode": true
},
"test": {
  "protocol": "http",
  "port": 8000,
  "host": "<IP_ADDRESS>",
  "clusterMode": true
},
"stage": {
  "protocol": "http",
  "port": 8000,
  "host": "<IP_ADDRESS>",
  "clusterMode": true
},
"prod": {
  "protocol": "http",
  "port": 8000,
  "host": "<IP_ADDRESS>",
  "clusterMode": true
}

```

## `.eslintrc.json`

It's a default config for eslint. You can customize it via command: `./node_modules/.bin/eslint --init`

## `Gruntfile.js`

Default cofiguration for grunt build system. You can find more information [in this section](#build-system).

## `test.js`

This script executes all tests in the `test` directory using [this library](https://github.com/Guseyn/node-test-executor).

# Building Process

The declaration of this process is in [server/build.js](https://github.com/Guseyn/page/blob/master/build.js) script. Here we execute static analysis (for `pages`, `server`, `static/js/es6` and `test` packages), test coverage of [test](https://github.com/Guseyn/page/blob/master/test.js) script and [grunt build](https://github.com/Guseyn/page/blob/master/Gruntfile.js) (you can use other build system). After grunt tasks are executed we generate static pages. And that's it, you can also add some other steps in your building process.

```js
// build.js

const { as } = require('@cuties/cutie')
const { Value } = require('@cuties/json')
const { ExecutedScripts } = require('@cuties/scripts')
const { SpawnedCommand } = require('@cuties/spawn')
const { ExecutedLint, ExecutedTestCoverage, ExecutedTestCoverageCheck } = require('@cuties/wall')
const Config = require('./async/Config')
const PrintedStage = require('./async/PrintedStage')
const env = process.env.NODE_ENV || 'local'

new Config('./config.json').as('config').after(
  new Config('./package.json').as('packageJSON').after(
    new PrintedStage(as('config'), as('packageJSON'), `BUILD (${env})`).after(
      new ExecutedLint(process, './pages', './server', './static/js/src', './test').after(
        new ExecutedTestCoverageCheck(
          new ExecutedTestCoverage(process, './test.js'),
          { 'lines': 100, 'functions': 100, 'branches': 100 }
        ).after(
          new SpawnedCommand('grunt').after(
            new ExecutedScripts(
              'node', 'js', new Value(as('config'), 'staticGenerators')
            )
          )
        )
      )
    )
  )
).call()

```

## Static analysis and test coverage (wall)

You can find information about configuring async composition of static analysis and test coverage [here](https://github.com/Guseyn/wall).

Also you can customize eslint config via command **`./node_modules/.bin/eslint --init`**. Default configuration you can find [here](https://github.com/Guseyn/wall/blob/master/.eslintrc.json).

# Running Process

The declaration of this process is in [server/run.js](https://github.com/Guseyn/page/blob/master/server/run.js) script.

## Backend (server)

For building backend server with REST API we use here [cutie-rest](https://github.com/Guseyn/cutie-rest):

```js
// server/async/LaunchedBackend.js

const { Backend } = require('@cuties/rest')
const { Value } = require('@cuties/json')
const Api = require('./Api')
const env = process.env.NODE_ENV || 'local'

module.exports = class {
  constructor (config) {
    return new Backend(
      new Value(config, `${env}.protocol`),
      new Value(config, `${env}.port`),
      new Value(config, `${env}.host`),
      new Api(config)
    )
  }
}

```

Where `Api` object is for our REST API, which is defined in the `./server/async/Api.js` script:

```js
// server/async/Api.js

const { RestApi, ServingFilesEndpoint, CachedServingFilesEndpoint } = require('@cuties/rest')
const { Value } = require('@cuties/json')
const { Created } = require('@cuties/created')
const CustomIndexEndpoint = require('./../endpoints/CustomIndexEndpoint')
const CustomNotFoundEndpoint = require('./../endpoints/CustomNotFoundEndpoint')
const CustomInternalServerErrorEndpoint = require('./../endpoints/CustomInternalServerErrorEndpoint')
const UrlToFSPathMapper = require('./UrlToFSPathMapper')
const env = process.env.NODE_ENV || 'local'
const headers = env === 'prod' ? { 'Cache-Control': 'cache, public, max-age=86400' } : {}
const servingFilesEndpoint = env === 'prod' ? CachedServingFilesEndpoint : ServingFilesEndpoint

class CreatedCustomNotFoundEndpoint {
  constructor (config) {
    return new Created(
      CustomNotFoundEndpoint,
      new RegExp(/^\/not-found/),
      new Value(config, 'notFoundPage')
    )
  }
}

module.exports = class {
  constructor (config) {
    return new RestApi(
      new Created(
        CustomIndexEndpoint,
        new Value(config, 'index'),
        new CreatedCustomNotFoundEndpoint(config)
      ),
      new Created(
        servingFilesEndpoint,
        new RegExp(/^\/(css|html|image|js|txt)/),
        new UrlToFSPathMapper(
          new Value(config, 'static')
        ),
        headers,
        new CreatedCustomNotFoundEndpoint(config)
      ),
      new CreatedCustomNotFoundEndpoint(config),
      new CustomInternalServerErrorEndpoint(new RegExp(/^\/internal-server-error/))
    )
  }
}

```

More information about declaration REST API you can find in the docs [cutie-rest](https://github.com/Guseyn/cutie-rest).

## The Whole Declaration

I believe that the declarative code below is self-explainable, but you can anyway [submit an issue](https://github.com/Guseyn/page/issues), if something is not clear. However, it requires some knowledge in such modules like: [cutie](https://github.com/Guseyn/cutie), [cutie-if-else](https://github.com/Guseyn/cutie-if-else), [cutie-cluster](https://github.com/Guseyn/cutie-cluster), [cutie-json](https://github.com/Guseyn/cutie-json), [cutie-rest](https://github.com/Guseyn/cutie-rest), [cutie-fs](https://github.com/Guseyn/cutie-fs).

```js
// server/run.js

const cluster = require('cluster')
const { as } = require('@cuties/cutie')
const { If, Else } = require('@cuties/if-else')
const { IsMaster, ClusterWithForkedWorkers, ClusterWithExitEvent } = require('@cuties/cluster')
const { Value } = require('@cuties/json')
const Config = require('./../async/Config')
const PrintedStage = require('./../async/PrintedStage')
const ReloadedBackendOnFailedWorkerEvent = require('./events/ReloadedBackendOnFailedWorkerEvent')
const LaunchedBackend = require('./async/LaunchedBackend')
const TunedWatchers = require('./async/TunedWatchers')

const numCPUs = require('os').cpus().length
const env = process.env.NODE_ENV || 'local'
const devEnv = env === 'local' || env === 'dev'

new Config('./config.json').as('config').after(
  new Config('./package.json').as('packageJSON').after(
    new If(
      new IsMaster(cluster),
      new PrintedStage(as('config'), as('packageJSON'), `RUN (${env})`).after(
        new If(
          devEnv,
          new TunedWatchers(as('config'))
        ).after(
          new If(
            new Value(as('config'), `${env}.clusterMode`),
            new ClusterWithForkedWorkers(
              new ClusterWithExitEvent(
                cluster,
                new ReloadedBackendOnFailedWorkerEvent(cluster)
              ), numCPUs
            ),
            new Else(
              new LaunchedBackend(as('config'))
            )
          )
        )
      ),
      new Else(
        new LaunchedBackend(as('config'))
      )
    )
  )
).call()

```

In few words, here running process runs a server with REST API (in the cluster mode by default) and attaches [fs watchers](https://nodejs.org/dist/latest/docs/api/fs.html#fs_fs_watch_filename_options_listener) on `pages`, `static`, `templates` directories(in `local` and `dev` environments). FS watchers are declared by `TunedWatchers` object which is defined in [this script](https://github.com/Guseyn/page/blob/master/server/async/TunedWatchers.js). Also in the cluster mode failed processes restart automatically.

As you can see here, we get some parameters like `post` and `host` from `config.json`. Also, you can notice that it's possible to run server in [cluster mode](https://nodejs.org/dist/latest/docs/api/cluster.html).

It's just an example of how it could be built and worked. But, of course, you can configure it differently due to your requirements (it's quite configurable code).

# Build Project

For building use command: **`page build [environment]`** or **`page b [environment]`**. `environment` is one of the following values: `local`, `prod`, `dev`, `stage`, `prod` (`local` is the default environment).

# Run Project

For running use command: **`page run [environment]`** or **`page r [environment]`**. `environment` is one of the following values: `local`, `prod`, `dev`, `stage`, `prod` (`local` is the default environment).

# Test Project

You can do it via **`page test`** or just **`npm test`**.

# List of Libraries For Page

All these libraries are available on **npm** under `@page-libs` scope.

## page-cutie

[This library](https://github.com/Guseyn/page-cutie) is analogue of [cutie](https://github.com/Guseyn/cutie) for using [Async Tree Pattern](https://github.com/Guseyn/async-tree-patern/blob/master/Async_Tree_Patern.pdf) in browser.

You can use async object from **page-cutie** with async objects from **cutie** on the server(Node.js programm) with no problems. But if you want to use mixed async objects in the browser, you must transform **cutie** async objects to **page-cutie** async objects. Use following function:

```js
const { browserified } = require('@page-libs/cutie')
const { AsyncObject1, AsyncObject2, AsyncObject3 } = browserified(require('@cuties/some-lib'))

// Now you can use AsyncObject1, AsyncObject2, AsyncObject3 which are based on @cuties/cutie
// with async objects which are based on @page-libs/cutie in the browser

```

## page-ajax (based on *page-cutie*)

[This library](https://github.com/Guseyn/page-cutie) allows you to use ajax in very conviniet way. It works like external request objects in [cutie-http](https://github.com/Guseyn/cutie-http) or [cutie-https](https://github.com/Guseyn/cutie-https).

### Example

```js
new ResponseBody(
  new ResponseFromAjaxRequest({
    url: 'http://localhost:8000/html/res.html',
    method: 'GET'
  })
).call()

```

So, as you can see here, it's possible wrap async request with just one object using [Async Tree Pattern](https://github.com/Guseyn/async-tree-patern/blob/master/Async_Tree_Patern.pdf).

## page-unit

[This library](https://github.com/Guseyn/page-unit) allows you to represent *html code* as *js code*, so you can encapsulate entire behaviour of DOM elements in objects.

### Example

We can represent following html code:

```html
<div id="user-form">
  <input id ="name">
  <input id ="password">
  <button id="submit">Sign in</button>
</div>

```

like this composition:

```js
new UserForm(
  document.getElementById('user-form'),
  new NameInput(document.getElementById('name')),
  new PasswordInput(document.getElementById('password')),
  new SubmitButton(document.getElementById('submit'))
)

```
Full example [here](https://github.com/Guseyn/page-unit#example).

## page-static-generator (based on *cutie*)

[This library](https://github.com/Guseyn/page-static-generator) is simple tool for generating *html* pages from different templates combining them.

### Example

We can build *html* page from these two templates:

```html
<!-- outer.html -->
<div class="outer">
   {{ text }}
  <div class="place-for-inner-template">
    {{ innerTemplate }}
  </div>
</div>

```

```html
<!-- inner.html -->
<div class="inner">
   {{ text }}
</div>

```

using following composition:

```js

const { SavedPage, PrettyPage, Page, Head, Body, Script, Style, TemplateWithParams, Template } = require('@page-libs/static-generator')

new SavedPage(
  'page.html',
  new PrettyPage(
    new Page(
      'xmlns="http://www.w3.org/1999/xhtml" lang="en"',
      new Head(
        new Script('script1.js', 'type="text/javascript"'),
        new Script('script2.js', 'type="text/javascript"'),
        new Style('main.css', 'type="text/css"'),
        new Style('mobile.css', 'type="text/css"')
      ),
      new Body(
        'class="main"',
        new TemplateWithParams(
          new Template('outer.html'),
          'text in outer template',
          new TemplateWithParams(
            new Template('inner.html'),
            'text in inner template'
          )
        )
      )
    )
  )
).call()

```

The result is

```html
<!-- page.html -->
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" lang="en">

  <head>
    <script src="script1.js" type="text/javascript"></script>
    <script src="script2.js" type="text/javascript"></script>
    <link rel="stylesheet" href="main.css" type="text/css">
    <link rel="stylesheet" href="mobile.css" type="text/css">
  </head>

  <body class="main">
    <div class="outer">
      text in outer template
      <div class="place-for-inner-template">
        <div class="inner">
          text in inner template
        </div>

      </div>
    </div>
  </body>

</html>

```

You can find more information about usage [here](https://github.com/Guseyn/page-static-generator#usage).

## page-md2html (based on *cutie*)

[This library](https://github.com/Guseyn/page-static-generator) is simple tool for transforming text from *markdown* to the *html*.
Based on [this lib](https://github.com/showdownjs/showdown).

### Example

```js

new HtmlFromMd(markdownText).call();

```
## page-dom (based on *page-cutie*)

[This library](https://github.com/Guseyn/page-dom) is set of async objects for creating DOM elements.

### Example

This simple example just shows the way of declaration in this lib:

```js
new ElementWithAppendedChildren(
  document.createElement('div'),
  div('class="div" id="div1"')(
    h1()(),
    a('href="guseyn.com"')(),
    div('class="div" id="div2"')(
      img('src="image.png"')(),
      p('', 'text')()
    )
  )
).call()

```

[Here](https://github.com/Guseyn/page-dom#async-objects) you can find more examples.

### Common Sense

I don't think that it makes sense to wrap every static function in browser js with objects. In my opinion, it's overhead. It's better to use [page-unit](https://github.com/Guseyn/page-unit) with procedural code in events(like in `onclick` methods). Actually, procedural code is clear, if amount of it is not big. Probably some *heavy* stuff will be written in OOP style in other libs for *Page*, but for simple things it's better use good old procedural js.

However, this example is not the case, obviously. I think that creating element in DOM in declarative style is much better than the same code in procedural style.

# Build System

**Page** uses [grunt](https://gruntjs.com/). If you look at [Gruntfile.js](https://github.com/Guseyn/page/blob/master/Gruntfile.js), you'll see 3 tasks: `babel`, `browserify`, `uglify`.

## `babel`

Babel takes code from `static/js/src`, convert it into JavaScript that browsers can understand and put it in `static/js/out`.

## `browserify`

We need this step because browsers don't understand `require()`. Using browserify we make module system work in browser, so use also can use `node_modules` in your project. It generates `static\js\bundle.js`.

## `uglify`

It just minifies `static\js\bundle.js` into `static\js\bundle.min.js`.

## It's Your Choice

Obviously, you can choose any other build system for your browser js code you want. It's just an example of how it could be.

# Future plans

Just to create more little useful libs for **Page**.

repository: marechalbati/page

repo_name: marechalbati/page


text:
# 5.5 Synchronizers

## Latches

* A latch is a synchronizer that can delay the progress of threads until it reaches its terminal state
* A latch acts as a gate - until the latch reaches the terminal state, the gate is closed and no thread can pass, and in the terminal state, the gate opens, allowing all threads to pass
* Latches can be used to ensure that certain activities do not proceed until other one-time activities complete like
  * Ensuring a computation does not proceed until the resources it needs have been initialized
  * Ensuring that a service does not start until other services which it depends on have started
* `CountDownLatch` allows one or more threads to wait for a set of events to occur
  * Counter, initialized to a positive integer` counts down the number of events to wait for
  * `await` methods wait for the counter to reach zero, which happens when all events have occurred
    * `await` will block until counter reaches zero, the waiting thread is interrupted, or the wait times out

```java
public class TestHarness {
  public long timeTasks(int nThreads, final Runnable task) throws InterruptedException {
    final CountDownLatch startGate = new CountDownLatch(1);
    final CountDownLatch endGate = new CountDownLatch(nThreads);

    for (int i = 0l i < nThreads; i++) {
      Thread t = new Thread() {
        public void run() {
          try {
            startGate.await();
            try {
              task.run();
            } finally {
              endGate.countDown();
            }
          } catch (InterruptedException ignored) {}
        }
      }

      t.start();
    }

    long start = System.nanoTime();
    startGate.countDown();
    endGate.await();
    long end = System.nanoTime();
    return end - start;
  }
```

* `TestHarness` creates a number of threads that can run a task concurrently
* The starting gate latch, initialized with a count of one, makes all the threads wait on it so that none of them start working until they are all ready to start
  * The starting gate is counted down, and this executes the underlying task
* The ending gate allows the master thread to wait efficiently until all of the worker threads have finished (since the worker threads count down)

## `FutureTask`

* `FutureTask` implements `Future` which describes an abstract result-bearing computation
* A computation represented by a `FutureTask` is implemented with a `Callable`, the result-bearing equivalent of `Runnable`
  * Is either waiting to run, running, or completed
  * Completion can be "normal" completion, cancellation, or an exception
  * Once completed, it stays in that state forever
* `Future.get` will return immeditately if the task is completed
  * If not completed, it will block until the task transitions to completed and will return the result or throw an exception
* `FutureTask` conveys the result from the thread executing the computation to the thread(s) retrieving the result

```java
public class Preloader {
  private final FutureTask<ProductInfo> future = new FutureTask<ProductInfo>(new Callable<ProductInfo>() {
    public ProductInfo call() throws DataLoadException {
      return loadProductInfo();
    }
  }

  private final Thread thread = new Thread(future);

  public void start() {
    thread.start();
  }

  public ProductInfo get() throws DataLoadException, InterruptedException {
    try {
      return future.get();
    } catch (ExcecutionException e) {
      Throwable cause = e.getCause();
      if (cause instanceof DataLoadException) {
        throw (DataLoadException) cause;
      } else {
        throw launderThrowable(cause);
      }
    }
  }
}
```

* Tasks described by `Callable` can throw checked and unchecked exceptions
* Whatever is thrown is wrapped in an `ExecutionException` and rethrown from `Future.get`
* There are three categories of `ExecutionException`s - checked exceptions thrown by the `Callable`, `RuntimeException` or an `Error`
* `launderThrowable` checks if error is `Runtime` if so, it returns the exception
  * If it's an `Error`, throws it, else throws `IllegalStateException`

## Semaphores

* Counting semaphores are used to control the number of activities that can access a certain resource or perform a given action at the same time
* A semaphore manages a set of virtual permits
* Activities can acquire permits and release permits when they are done with them
* If no permit is available, the `acquire` method blocks until one is (or until interrupted or the operation times out)
* `release` returns a permit to the semaphore
* Binary semaphore (i.e. a semaphore with a count of 1) is used as a mutex with nonreentrant locking semantics
  * Whoever holds the sole permit holds the mutex
* Semaphores are useful for implementing resource pools such as database connection pools
  * Can use the semaphore to block if the pool is empty and unblock whn it becomes nonempty again by acquiring a permit before accessing a resource from the pool and releasing the permit after putting a resource back into the pool
* Can use semaphores to turn any collection into a blocking bounded collection
  * A bounded `HashSet` can be implemented by adding logic in the `add` operation to acquire a permit before adding an item to the underlying collection
  * If the `add` operation does not actually add anything, the permit is released immediately
  * A successful remove operation releases a permit allowing more elements to be added

## Barriers

* Barriers are similar to latches in that they block a group of threads until some event has occurred
* All the threads must come together at a barrier point at the same time in order to proceed
* Latches wait for events while barriers wait for other threads
* "Everyone meet at McDonald's at 6PM - once you get there, stay there until everyone shows up, and then we'll figure out what we're going to do next"
* Barriers are often used in simulations, where the work to calculate one step can be done in parallel but all the work associated with a given step must complete before advancing to the next step
  * For n-body particle simulations, each step pcalculates an update to the position of each particle based on the locations and other attributes of the other particles
  * Waiting on a barrier between each update ensures that all updates for step `k` have completed before moving on to the next step
* Another form of barrier is `Exchanger`, a two-party barrier in which the parties exchange data at the barrier point
  * When one thread fills a buffer with data and the other thread consumes the data from the buffer, these threads could use an `Exchanger` to meet and exchange a full buffer for an empty one
  * Simplest approach might be for the filling task to exchange when the buffer is full and the emptying task exchanges when the buffer is empty
    * This minimizes number of exchanges but can delay processing of some data if the arrival rate of new data is unpredictable
  * Another approach is that the thread that fills the buffer exchanges when the buffer is full, but also when the buffer is partially filled and a certain amount of time has elapsed

url: https://raw.githubusercontent.com/jaebradley/notes/b9cb0fac012e61205d12ed8d139bbc494319e392/Software Engineering/Languages/java/Java Concurrency In Practice/Chapter 5/5 Synchronizers.md

repository: jaebradley/notes

filename: 5 Synchronizers.md

repo_name: jaebradley/notes


text:
---
layout: post
title:      "Function Expression vs. Function Declaration"
date:       2020-08-21 19:43:20 +0000
permalink:  function_expression_vs_function_declaration
---

I would get confused any time I heard either function expression or function declaration. I didn't know which was which, or how they differed. So here is an example of what they might look like.

Function expression:
```
let doSomething = function() {
  return something
}

let doSomething = () => {
  return something
}

let doSomething = function name(){
  return something
}
```

As you can see, we are creating a variable and assigning a function as its value. Function declarations look a little bit different.

Function declaration:
```
function doSomething() {
  return something
}
```

One of the biggest differences, and most important things to keep in mind when working with either of these, is how they can, and can't be used in your program.

With function declarations, you could do something like this:
```
doSomething(); // --> something

function doSomething(){
  return something
}
 ```

Function declarations are hoisted. If you tried to do this:

```
doSomething()

let doSomething = function() {
  return something
}
```

It just would not work. Happy Coding!

extension: markdown


text:
# sra-cloud

These are use contributed ways to search and access SRA data in the cloud. To contribute to this repository, fork it using the fork button above, make some changes, add your name, and then submit a PR for those changes.

Be sure to add your name so you can get credit. If you want to provide more information or help, email [Rob Edwards](https://edwards.sdsu.edu/research/)

# Big Table Queries

Use the [Google-NCBI BigTable Query Creator](https://console.cloud.google.com/bigquery) to try out your queries and run them

## More documentation

- [The BigQuery Metadata Table](https://www.ncbi.nlm.nih.gov/sra/docs/sra-bigquery-metadata-table/) column definitions

## Commonly used field mappings

Field | Contents | Abbreviation
--- | --- | ---
`acc` | Run | SRR######
`sample_acc` | Sample Accession | SRS########
`biosample` | BioSample ID | SAMN########
`sra_study` | Study Accession | SRP########
`bioproject` | BioProject Accession | PRJNA########

## Counting all runs associated with a study accession
Submitted by: Rob Edwards

Run accession: [SRP216273](https://trace.ncbi.nlm.nih.gov/Traces/study/?acc=SRP216273&o=acc_s%3Aa)

```
select count(acc) from `nih-sra-datastore.sra.metadata` where sra_study = 'SRP216273';
```

repository: linsalrob/sra-cloud

repo_name: linsalrob/sra-cloud


text:
# bad data

    Code
      rec %>% step_bsmote(x) %>% prep()
    Error <recipes_error_step>
      Error in `step_bsmote()`:
      Caused by error in `prep()`:
      ! `x` should be a factor variable.

---

    Code
      rec %>% step_bsmote(class, id) %>% prep()
    Error <recipes_error_step>
      Error in `step_bsmote()`:
      Caused by error in `prep()`:
      ! The selector should select at most a single variable

# errors if character are present

    Code
      recipe(~., data = df_char) %>% step_bsmote(x) %>% prep()
    Error <recipes_error_step>
      Error in `step_bsmote()`:
      Caused by error in `prep()`:
      ! All columns selected for the step should be double, or integer.

# NA in response

    Code
      recipe(Job ~ Age, data = credit_data) %>% step_bsmote(Job) %>% prep()
    Error <recipes_error_step>
      Error in `step_bsmote()`:
      Caused by error in `prep()`:
      ! Cannot have any missing values. NAs found ind: Job.

# empty printing

    Code
      rec
    Message <cliMessage>

      -- Recipe ----------------------------------------------------------------------

      -- Inputs
      Number of variables by role
      outcome:    1
      predictor: 10

      -- Operations
      * BorderlineSMOTE based on: <none>

---

    Code
      rec
    Message <cliMessage>

      -- Recipe ----------------------------------------------------------------------

      -- Inputs
      Number of variables by role
      outcome:    1
      predictor: 10

      -- Training information
      Training data contained 32 data points and no incomplete rows.

      -- Operations
      * BorderlineSMOTE based on: <none> | Trained

# printing

    Code
      print(rec)
    Message <cliMessage>

      -- Recipe ----------------------------------------------------------------------

      -- Inputs
      Number of variables by role
      outcome:   1
      predictor: 2

      -- Operations
      * BorderlineSMOTE based on: class

---

    Code
      prep(rec)
    Message <cliMessage>

      -- Recipe ----------------------------------------------------------------------

      -- Inputs
      Number of variables by role
      outcome:   1
      predictor: 2

      -- Training information
      Training data contained 400 data points and no incomplete rows.

      -- Operations
      * BorderlineSMOTE based on: class | Trained

repository: tidymodels/themis

gha_language: R

gha_license_id: NOASSERTION

repo_name: tidymodels/themis


text:
Quite a few things to process here. Some facts:

- Calling `GetHashCode` on an `int` will not allocate anything on the heap.
- Calling `RuntimeHelpers.GetHashCode` invokes a generic hashcode algorithm that will allocate intermediary reference type instances on the heap.
- Given a list of structs, accessing an element and trying to mutate it will only mutate a copy of it, so the actual element stored in the list remains unchanged.
- `IsByRef` property on `typeof(string)` will return `false` even if strings are reference types in C#. This member doesn't indicate that the type is a reference type or a value type.
- `int` is a simple alias in the C# language for the `System.Int32` type.

Now it's just basic logic...


text:
# IIS360 - Simplify Development of SAP Fiori Apps with OData V4

[![REUSE status](https://api.reuse.software/badge/github.com/SAP-samples/teched2020-IIS360)](https://api.reuse.software/info/github.com/SAP-samples/teched2020-IIS360)

## Description

This repository contains the material for the SAP TechEd 2020 session\
**IIS360 - Simplify Development of SAP Fiori Apps with OData V4**.

## Overview

This session introduces attendees to the creation of a SAP Fiori elements Floorplans for OData V4 app.\
You will start in the SAP Business Application Studio with a sample service (based on the SAP Cloud Application Programming Model for nodeJS), and make usage of the SAP Fiori tools in order to generate and extend the app.\
More detailed information about SAP Fiori elements and SAP Fiori tools can be found in [this presentation](exercises/2020-12%20SAP_TechEd_2020_SAP_Fiori_elements_SID1120%20(IIS360).pdf).

## Requirements

There are no special requirements to follow the exercises in this repository.

## Exercises

- [Getting Started - Setting up your Development Environment](exercises/ex0#getting-started---setting-up-your-development-environment)
  - [Setting up SAP Business Application Studio in an SAP Cloud Platform Trial Account](exercises/ex0#setting-up-sap-business-application-studio-in-an-sap-cloud-platform-trial-account)
    - [New Trial Users](exercises/ex0#new-trial-users)
    - [Existing Trial Users](exercises/ex0#existing-trial-users)
    - [Accessing SAP Business Application Studio](exercises/ex0#accessing-sap-business-application-studio)
  - [Creating the Development Space](exercises/ex0#creating-the-development-space)
  - [Getting the Sample Scenario](exercises/ex0#getting-the-sample-scenario)
  - [Reopening the Exposed Port](exercises/ex0#reopening-the-exposed-port)

- [Exercise 1 - Generating an SAP Fiori Elements App](exercises/ex1#exercise-1---generating-an-sap-fiori-elements-app)
  - [Exercise 1.1 Using the SAP Fiori tools Application Generator](exercises/ex1#exercise-11-using-the-sap-fiori-tools-application-generator)
  - [Exercise 1.2 Starting the App](exercises/ex1#exercise-12-starting-the-app)

- [Exercise 2 - Switching to Flexible Column Layout](exercises/ex2#exercise-2---switching-to-flexible-column-layout)

- [Exercise 3 - Configuring the App](exercises/ex3#exercise-3---configuring-the-app)
  - [Exercise 3.1 Enable Data Load During Start of the App](exercises/ex3#exercise-31-enable-data-load-during-start-of-the-app)
  - [Exercise 3.2 Enable Control Level Variant Management](exercises/ex3#exercise-32-enable-control-level-variant-managment)
  - [Exercise 3.3 Configure Editable Object Page Header](exercises/ex3#exercise-33-configure-editable-object-page-header)
  - [Exercise 3.4 Enable Tab Based Section Layout](exercises/ex3#exercise-34-enable-tab-based-section-layout)

- [Exercise 4 - Adding a Custom Page](exercises/ex4#exercise-4---adding-a-custom-page)
  - [Exercise 4.1 Copy Over the Sample Custom Page](exercises/ex4#exercise-41-copy-over-the-sample-custom-page)
  - [Exercise 4.2 Adding a Custom Page via SAP Fiori Page Map](exercises/ex4#exercise-42-adding-a-custom-page-via-sap-fiori-page-map)
  - [Exercise 4.3 Custom Page: Testing the App](exercises/ex4#exercise-43-custom-page-testing-the-app)

- [Exercise 5 - Adding a Custom Section](exercises/ex5#exercise-5---adding-a-custom-section)
  - [Custom Sections Overview](exercises/ex5#custom-sections-overview)
  - [Exercise 5.1 Enhancing the Language Model](exercises/ex5#exercise-51-enhancing-the-language-model)
  - [Exercise 5.2 Adding a Custom Section via Page Map](exercises/ex5#exercise-52-adding-a-custom-section-via-page-map)

- [Exercise 6 - Enhance the UI with Annotations](exercises/ex6#exercise-6---enhance-the-ui-with-annotations)
  - [Exercise 6.1 Adding a Field Group](exercises/ex6#exercise-61-adding-a-field-group)
  - [Exercise 6.2 Adding a Reference Facet Annotation](exercises/ex6#exercise-62-adding-a-reference-facet-annotation)
  - [Exercise 6.3 Adding a new Table Column with Criticality Highlighting](exercises/ex6#exercise-63-adding-a-new-table-column-with-criticality-highlighting)

- [Exercise 7 - Adding a Contact Card Showing Data from SAP S/4 HANA](exercises/ex7#exercise-7---adding-a-contact-card-showing-data-from-sap-s4-hana)
  - [Exercise 7.1 Get the Business Partner EDMX File](exercises/ex7#exercise-71-get-the-business-partner-edmx-file)
  - [Exercise 7.2 Adding the EDMX File and Local Data to your Project](exercises/ex7#exercise-72-adding-the-edmx-file-and-local-data-to-your-project)
  - [Exercise 7.3 Adding Associations to the Incidents Service Entities](exercises/ex7#exercise-73-adding-associations-to-the-incidents-service-entities)
  - [Exercise 7.4 Adding an Annotation for a Contact Card](excercises/ex7#exercise-74-adding-an-annotation-for-a-contact-card)
  - [Exercise 7.5 Fetching Business Partner Data from an SAP S/4 HANA Cloud system](exercises/ex7#exercise-75-fetching-business-partner-data-from-an-sap-s4-hana-cloud-system)

## How to obtain support

Support for the content in this repository is available during the actual time of the online session for which this content has been designed. Otherwise, you may request support via the [Issues](../../issues) tab.

## License
Copyright (c) 2020 SAP SE or an SAP affiliate company. All rights reserved. This file is licensed under the Apache Software License, version 2.0 except as noted otherwise in the [LICENSE](LICENSES/Apache-2.0.txt) file.


text:
## Splashscreens and Icons

If you have experienced developing hybrid applications, you know that creating splashscreens and icons is a pain! There are so many parameters that come into play:

* Width and Height
* Density
* OS
* Device
* Landscape / Portrait

If you want to correctly address those parameters you will end up creating a dozen splashscreens and icons per OS. By experience do not even try to do it yourself (e.g using Photoshop), it is a waste of time.

There are some online tools that can help you generating splashscreens and icons but Ionic is also here to help!

### install

```
sudo npm install ionic -g
```

### Create templates

Create two files (either .psd, .ai or .png) within the ```resources``` directory. One named ```icon``` that needs to follow [this template](http://code.ionicframework.com/resources/icon.psd) and the other named ```splash``` that needs to follow [this template](http://code.ionicframework.com/resources/splash.psd)

### Run

```
# generate both icons and splashscreens
ionic resources

# generate only icons
ionic resources --icon

# generate only splashscreens
ionic resources --splash
```

It will upload your files to Ionic’s servers and create everything for you (create the correct platforms folders and even edit the ```config.xml``` file).

repository: Intraktio/hybrid

gha_language: JavaScript

repo_name: Intraktio/hybrid


text:
  îles — french word for "islands"

Islands of interactivity with <samp>Vue</samp> in <samp>Vite.js</samp>

[îles]: https://github.com/ElMassimo/iles
[docs]: https://iles-docs.netlify.app
[twitter]: https://twitter.com/ilesjs
[follow me]:  https://twitter.com/MaximoMussini

[guide]: https://iles-docs.netlify.app/guide/introduction
[configuration reference]: https://iles-docs.netlify.app/config

[blog]: https://the-vue-point-with-iles.netlify.app/

[partial hydration]: https://iles-docs.netlify.app/guide/hydration
[Batteries Included]: https://iles-docs.netlify.app/guide/development#components
[Multi-Framework]: https://iles-docs.netlify.app/guide/frameworks
[markdown]: https://iles-docs.netlify.app/guide/markdown
[routing]: https://iles-docs.netlify.app/guide/routing
[devtools]: https://user-images.githubusercontent.com/1158253/133314267-f0ba784c-ff64-4ee8-b2bf-97ecffc2facd.jpg
[hydration timeline]: https://user-images.githubusercontent.com/1158253/133314279-1edc22d1-3ffb-414e-b994-212cb316593b.jpg

[stackblitz]: https://stackblitz.com/fork/iles?file=src%2Fcomponents%2FWelcome.vue

## Features ✨

- 🏝 **[Partial Hydration]** - zero JS by default, hydrates the interactive bits
- 🔌 **[Batteries Included]** - layouts, components, site-wide data
- 🧱 **[Multi-Framework]** - vue, preact, svelte, solid
- 📖 **[Markdown]** - use components in markdown and viceversa
- 🛣 **[Routing]** - automatically configured from files
- 🛠 **[Devtools][devtools]** - debug panel and [hydration timeline]
- ⚡ **[Fast][Vite]** - instant reloading powered by [Vite]

## Demos 🚀

__[Documentation Website][docs]__

__[Official Vue.js Blog][blog]__

## Try it Online ⚡

[![](https://developer.stackblitz.com/img/open_in_stackblitz.svg)][stackblitz]

## Installation 💿

```bash
pnpm init iles@next # or npm or yarn
```

## Documentation 📖

Visit the [documentation website][docs] to check out the [guides][guide] and searchable [configuration reference].

## News 🗞

[Follow me] or the [official îles account][twitter] on [Twitter].

## Acknowledgements 🙇♂

- [Vite] and [Vue]: for enabling an amazing development experience
- [Astro](https://astro.build): for sharing a novel way to define islands
- [xdm]: provides amazing flexibility when processing Markdown
- [vue-router], [@vueuse/head], and [vite-plugin-pages]: the backbone of this library
- [unplugin-vue-components]: allows you to avoid the boilerplate
- [Vitepress] and [vite-ssg]: for their different ideas on SSR

[Vite]: https://vitejs.dev/
[Vue]: https://v3.vuejs.org/
[xdm]: https://github.com/wooorm/xdm
[Astro]: https://docs.astro.build/core-concepts/component-hydration
[vite-plugin-pages]: https://github.com/hannoeru/vite-plugin-pages
[unplugin-vue-components]: https://github.com/antfu/unplugin-vue-components
[Vitepress]: https://vitepress.vuejs.org/
[vite-ssg]: https://github.com/antfu/vite-ssg
[vue-router]: https://next.router.vuejs.org/
[@vueuse/head]: https://github.com/vueuse/head

repository: tomtev/iles

repo_name: tomtev/iles


text:
---
# Documentation: https://sourcethemes.com/academic/docs/managing-content/

title: "High-accuracy GNSS Positioning on Portable Smartphone"
summary: "Developed an algorithm which achieved high-accuracy and reliable positioning of smartphones under complex environment using GNSS-IMU fusion."
authors: []
tags: ["GNSS","PDR","Smartphone"]
categories: []
date: 2017-09-24T23:29:34+08:00

# Optional external URL for project (replaces project detail page).
external_link: ""

# Featured image
# To use, add an image named `featured.jpg/png` to your page's folder.
# Focal points: Smart, Center, TopLeft, Top, TopRight, Left, Right, BottomLeft, Bottom, BottomRight.
image:
  caption: ""
  focal_point: ""
  preview_only: false

# Custom links (optional).
#   Uncomment and edit lines below to show custom links.
links:
 - name: RawMeaLogger(Android app)
   url: https://github.com/milkytipo/RawMeaLogger
   icon_pack: fab
   icon: github
 - name: PDR+RTD(matlab)
   url: https://github.com/milkytipo/PDR_coupled_GNSS
   icon_pack: fab
   icon: github
 - name: RTD(java)
   url: https://github.com/milkytipo/DDKalmanFitlerManager
   icon_pack: fab
   icon: github
 - name: paper(RTD)
   url: "files/ION.pdf"
   icon_pack: fas
   icon: file-pdf
 - name: slides(PDR/GNSS)
   url: "files/csnc_slides.pdf"
   icon_pack: fas
   icon: file-pdf

url_code: ""
url_pdf: ""
url_slides: ""
url_video: ""

# Slides (optional).
#   Associate this project with Markdown slides.
#   Simply enter your slide deck's filename without extension.
#   E.g. `slides = "example-slides"` references `content/slides/example-slides.md`.
#   Otherwise, set `slides = ""`.
slides: ""
---

Google released Android Nougat (version 7.0) in 2016, which opens the possibility to use raw data to achieve high precision  solutions on low-cost smart devices. Due to the poor performance of the low-cost antenna and crystal oscillator of smartphone,  the accuracy of traditional single point positioning can only reach about 10 meters. However, IMU, the interoceptive sensor which never care about the interference outside, enable to assist GNSS to achieve robust and continuous localization.  Therefore, this project aimed to develop an algorithm which achieved high-accuracy and reliable positioning of smartphones under complex environment using GNSS-IMU fusion.

We developed an Android application to obtain the raw GNSS chips data and parsed it into generic format RINEX 3.02. During the analysis, we found that phone horrible oscillator existed intermittent 256ns drift. Then the pseudorange double-difference (PDD) was performed to eliminate the atmosphere, satellite, and phone clock error, as well as decoupled the pseudorange and velocity measurements based on the short-baseline hypothesis.

Furthermore, the joint heading estimation using Pedestrian Dead Reckoning (PDR) and GNSS Doppler was also presented, the result shows that this algorithm calibrated the PDR gait length loss and heading drift in the long-term, and maintained high smooth and accuracy in the short-term.


text:
If you have updated the OpenAPI definition, please update the server code using the makefile.

### Simple steps

Install [oapi-codegen](https://github.com/deepmap/oapi-codegen).
```
$ go get github.com/deepmap/oapi-codegen/cmd/oapi-codegen
```

Run makefile script.

```
$ make codegen
```

repository: cam-inc/viron

branch_name: refs/heads/develop

repo_name: cam-inc/viron