text:
---
title: Install node.js on Ubuntu 20.04
lang: en-US
---

# Install node.js on Ubuntu

Ref : <https://github.com/nodesource/distributions/blob/master/README.md>

You can install ```node.js``` of LTS version in Ubuntu using the commands below. If do you want installation ```node.js``` of other
version that you can refer the [NodeSource Node.js Binary Distributions page](<https://github.com/nodesource/distributions/blob/master/README.md>).

```shell
# Using Ubuntu
curl -fsSL https://deb.nodesource.com/setup_lts.x | sudo -E bash -
sudo apt-get install -y nodejs
```

gha_language: Python


text:
# MWSE-Harder-Barter
Harder Barter
by mort
1.1

Place in Data Files\MWSE\mods\HarderBarter\

Requires MWSE 2.1 beta https://nullcascade.com/mwse/mwse-dev.zip

Uses mwse to dynamically adjust merchant buy prices.
Price = Price / log(baseprice)
This means expensive items are much less valuable and cheap items are more or less the same price.

1.1 update fixes items less than 10 gold value being worthless

Requires MWSE-Lua

Licensing: use whenever, wherever, for anything

Thanks to: nullcascade for mwse

license: MIT

repository: MortimerMcMire/MWSE-Harder-Barter

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: MortimerMcMire/MWSE-Harder-Barter


text:
# Challenge Summary
First-in, First out Animal Shelter.

## Challenge Description
Create a class called AnimalShelter which holds only dogs and cats. The shelter operates using a first-in, first-out approach.
Implement the following methods:
enqueue(animal): adds animal to the shelter. animal can be either a dog or a cat object.
dequeue(pref): returns either a dog or a cat. If pref is not "dog" or "cat" then return null.

## Approach & Efficiency
For the enqueue(animal) method time big O(1), space big O(1) For the dequeue(pref) method time big O(n), space big O(n)

## Solution
[Whiteboard](assets/animial_shelter.png)

gha_license_id: MIT


text:
# Getting Help

*Nov 11, 2015*

*Docs, Reference*

To see all available commands and their options use the `--help` option:

```
$ litepub --help
LitePub 0.5.6 [github.com/mirovarga/litepub]
Copyright (c) 2021 Miro Varga [mirovarga.com<EMAIL_ADDRESS>@mirovarga]

Usage:
  litepub create [<dir>] [-s, --skeleton] [-q, --quiet]
  litepub build  [<dir>] [-q, --quiet]
  litepub serve  [<dir>] [-R, --rebuild] [-p, --port <port>] [-w, --watch] [-q, --quiet]

Arguments:
  <dir>  The directory to create the blog in or look for; it will be created if
         it doesn't exist (only when creating a blog) [default: .]

Options:
  -s, --skeleton     Don't create sample posts and templates
  -R, --rebuild      Rebuild the blog before serving
  -p, --port <port>  The port to listen on [default: 2703]
  -w, --watch        Rebuild the blog when posts or templates change
  -q, --quiet        Show only errors
  -h, --help         Show this screen
  -v, --version      Show version
```

repository: mirovarga/litepub

gha_language: Go

repo_name: mirovarga/litepub


text:
STL Volume Model Calculator
===========================

This code is a volume calculator for STL Model in Python.
The script calculates how much material is needed for printing a 3D models.

Usage in a terminal:
  python mesure_volume.py torus.stl

"torus.stl" is any STL binary model of the object you want to calculate the volume.

Please report any error you may find to me (mar.canet@gmail.com).

Author: Mar Canet(http://var-mar.info) - Twitter: mcanet

If someone is looking for some explanation about volume calculator i recommend read this blog post: http://n-e-r-v-o-u-s.com/blog/?p=4415


text:
# vcluster

## **[GitHub](https://github.com/loft-sh/vcluster)** • **[Website](https://www.vcluster.com)** • **[Quickstart](https://www.vcluster.com/docs/getting-started/setup)** • **[Documentation](https://www.vcluster.com/docs/what-are-virtual-clusters)** • **[Blog](https://loft.sh/blog)** • **[Twitter](https://twitter.com/loft_sh)** • **[Slack](https://slack.loft.sh/)**

Create fully functional virtual Kubernetes clusters - Each vcluster runs inside a namespace of the underlying k8s cluster. It's cheaper than creating separate full-blown clusters and it offers better multi-tenancy and isolation than regular namespaces.

## Prerequisites

- Kubernetes 1.18+
- Helm 3+

## Get Helm Repository Info

```bash
helm repo add loft-sh https://charts.loft.sh
helm repo update
```

See [helm repo](https://helm.sh/docs/helm/helm_repo/) for command documentation.

## Install Helm Chart

```bash
helm upgrade [RELEASE_NAME] loft-sh/vcluster -n [RELEASE_NAMESPACE] --create-namespace --install
```

See [vcluster docs](https://vcluster.com/docs) for configuration options.

See [helm upgrade](https://helm.sh/docs/helm/helm_upgrade/) for command documentation.

## Connect to the vcluster

In order to connect to the installed vcluster, please install [vcluster cli](https://www.vcluster.com/docs/getting-started/setup) and run:

```bash
vcluster connect [RELEASE_NAME] -n [RELEASE_NAMESPACE]
```

## Uninstall Helm Chart

```bash
helm uninstall [RELEASE_NAME]
```

This removes all the Kubernetes components associated with the chart and deletes the release.

See [helm uninstall](https://helm.sh/docs/helm/helm_uninstall/) for command documentation.

### Why Virtual Kubernetes Clusters?

- **Cluster Scoped Resources**: much more powerful than simple namespaces (virtual clusters allow users to use CRDs, namespaces, cluster roles etc.)
- **Ease of Use**: usable in any Kubernetes cluster and created in seconds either via a single command or [cluster-api](https://github.com/loft-sh/cluster-api-provider-vcluster)
- **Cost Efficient**: much cheaper and efficient than "real" clusters (single pod and shared resources just like for namespaces)
- **Lightweight**: built upon the ultra-fast k3s distribution with minimal overhead per virtual cluster (other distributions work as well)
- **Strict isolation**: complete separate Kubernetes control plane and access point for each vcluster while still being able to share certain services of the underlying host cluster
- **Cluster Wide Permissions**: allow users to install apps which require cluster-wide permissions while being limited to actually just one namespace within the host cluster
- **Great for Testing**: allow you to test different Kubernetes versions inside a single host cluster which may have a different version than the virtual clusters

Learn more on [www.vcluster.com](https://vcluster.com).

![vcluster Intro](https://github.com/loft-sh/vcluster/raw/main/docs/static/media/vcluster-comparison.png)

Learn more in the [documentation](https://vcluster.com/docs/what-are-virtual-clusters).

repository: loft-sh/vcluster

branch_name: refs/heads/main

repo_name: loft-sh/vcluster


text:
# [Assignment 08](@id assignment08)

[![Assignment 08 - Due](https://img.shields.io/badge/Due-7%2F17%2F2020-orange?style=for-the-badge&logo=open%20badges)](@ref assignment08)

## Check list

There are a lot of different tasks introduced in this assignment,
and you will not have automated tests to tell you when you're done.
Here's a checklist to help you keep track,
which Kevin will add to your github repo once you've created it and shared it with him.

- [ ] Code repo (from Assignment 7), renamed and in public repo
  - [ ] tests still passing
- [ ] Analysis repo complete
  - [ ] README has heading 1 title and bold author line
  - [ ] `Project.toml` with code repo, `Revise`, `DataFrames`, and `Plots` as dependencies
  - [ ] `data/` directory with explanation for how to download data
    - [ ] `cov-sequences.fasta`
  - [ ] `notebooks/` directory with `1-sequence-stats.md`
    - [ ] Including code and description for calculating mean and standard deviations
          for sequence length and gc content

## Wrapping up Assignment07 Package

In the [previous assignment](@ref assignment07),
we created a julia package that you're going to be re-using
for the rest of the course.
But it doesn't have a very good name,
and at the moment, your assignments are in private repos,
which makes some stuff (like using it for automated tests) harder.

!!! warning
    Before continuing, make sure that you've successfully completed
    assignment 7 and all of the tests are passing

First, let's make a new, public home for your bioinformatics package.

1. On github, create a new repository:

   ![Create repo](../assets/img/new-repo.png)
2. Give it a good name - Julia package names usually end with `.jl`.
   Be sure that the repo is set to `public`.
   ![Create repo](../assets/img/repo-name.png)
3. Copy the url of the repository

   ![Create repo](../assets/img/clone-repo.png)
4. On your computer, navigate to your `Assignment07-<username>` directory.
   We are now going to point `git` to this new location,
   so that when you make new changes in the future,
   they will go there instead.

   In the terminal,

   ```sh
   $ git remote set-url origin <paste URL here>
   $ git push -u origin trunk
   Enumerating objects: 61, done.
   Counting objects: 100% (61/61), done.
   Delta compression using up to 12 threads
   Compressing objects: 100% (46/46), done.
   Writing objects: 100% (61/61), 76.07 KiB | 1.46 MiB/s, done.
   Total 61 (delta 21), reused 24 (delta 7), pack-reused 0
   remote: Resolving deltas: 100% (21/21), done.
   To github.com:kescobo/BioinformaticsBISC195.jl.git
    * [new branch]      trunk -> trunk
   Branch 'trunk' set up to track remote branch 'trunk' from 'origin'.
   ```
5. Now let's rename the module in the julia code.
   Open the assignment _directory_ in VS Code.
   There are a few places that the module name currently exists -
   use `cmd+shift+F` (`ctrl+shift+F` on Windows) to open the search panel
   (you can also click the magnifying glass icon in the sidebar)
   and search for `Assignment07`.

   Replace `Assignment07` with whatever you named your module,
   and then rename the main module file at `src/Assignment07.jl`.
6. Commit and push your changes.
7. Back on github, click on the `Settings` tab for your repository,
   then on `Manage access`, and add Kevin (`@kescobo`) as a collaborator.

## Building an analysis repository

Now, we'll create a new project to handle our analyses of SARS-CoV2 genomes.
While it is possible to keep everything in the same directory,
it's a good idea to keep code that may be useful in many projects
(such as your bioinformatics functions)
separate from code that is used for one specific purpose.

1. Open a terminal, and create a new directory with `mkdir` for CoV2 analysis
   (you can put it in the same directory as your other assignments,
   but don't put it _inside_ any of those assignments).
   Use `cd` to make this new directory your working directory,
   then enter `git init` to make this into a git repository.
2. On github, create a new repository, copy its url,
   and use `git remote add` to set this as `origin`
   (refer [back to lesson 1](@ref git-version-control) if you need
   a reminder about how these commands work).

   ```sh
   $ git remote add origin <url>
   ```

   Don't forget to add Kevin as a collaborator.
3. Create a directory inside this repo called `notebooks`,
   and another called `data`.
4. Open the analysis directory in VS Code.
   Create a file called `README.md`,
   give it a title (use markdown to make the title Heading 1 format),
   and add `By <your name>` under the title in bold.
5. Commit and push your changes.
   Remember, the first time you push, you need to say _where_ to push:

   ```sh
   $ git push --set-upstream origin master
   ```

   Take a look at the repo on github -
   your README should show up, correctly formatted,
   but the directories won't show up until there are committed files in them.
6. Add a file called `data.md` to the `data/` directory -
   This is where we'll describe how to get the data that we're going to analyze,
   but you can leave it blank for now
7. Add a file called `1-sequence-stats.md` to the `notebooks` directory.
   Also ok to leave this file blank for now.
8. Commit and push your changes.

At this point, you should have a git repo with the following structure:

```
./MyAnalysis
├── data
│   └── data.md
├── notebooks
│   └── 1-sequence-stats.md
└── README.md
```

## Getting the data

An enormous amount of data has already been generated
on SARS-CoV2 (the virus) and COVID-19 (the disease caused by CoV2).
You can get links to much of it [on NCBI](https://www.ncbi.nlm.nih.gov/sars-cov-2/) -
the National Center for Biotechnology Information.

We're particularly interested in the genome sequences
of SARS-related corona viruses.
Go to the [Virus search page](https://www.ncbi.nlm.nih.gov/labs/virus/vssi/#/virus?SeqType_s=Nucleotide&VirusLineage_ss=SARS-CoV-2,%20taxid:2697049),
and use the search function to see all of the genomes of
SARS-CoV (Severe accute respiratory syndrom-related Coronavirus),
MERS-CoV (Middle East repiratory syndrom-related Coronavirus),
and SARS-CoV2 (the virus that causes COVID19).

Refine the search a bit by selecting only complete genomes
(under "Nucleotide completeness").
At the time I write this, there are just under 7300 such records,
though there may be more by the time you search.

The search parameters you enter are stored in the url.
Copy the url and put it into your `data/data.md` file,
explaining what it is.
It's always a good idea to keep track of where data comes from
so that your work is reproducible by someone else.

Click "download", make sure "FASTA Nucleotide" is selected,
and download all records.
When it asks about the FASTA definition line (the header),
build a custom header and be sure to include the Accession number
(this is a unique identifier),
the species, and the Geo location.

Download the sequences, and put them into your `data/` directory
with a more descriptive name than `sequences.fasta`.
Be sure to describe what you did in `data/data.md`.

!!! tip
    Usually, it's not a good idea to add and commit large files
    like genome sequences to the git repository,
    especially if those files are likely to change often
    (since `git` stores a record of all of the different versions).

    In this case, our file is not going to change, and it's not **that** big,
    so it's ok to commit it, but if you want to avoid commiting it,
    and to make `git` forget about trying to track it,
    you can create a file called `.gitignore` inside your repo,
    and put `data/<filename>` in it.
    Be sure to add and commit the `.gitignore` file!

## Setting up julia project

Open a julia REPL in your analysis directory
(you can do this from VS Code
or by opening a new REPL and using `cd()`).

Now, activate the environment from the Pkg REPL,
and use `dev` (short for `develop`)
to install your bioinformatics project.
To do this, you can use the path (relative or absolute)
to the bioinformatics project directory.

For example, if it is in your `Documents/` directory,
you might enter

```
pkg> dev /Users/<username>/Documents/BioinformaticsBISC195
```

!!! note
    As with `$` in shell prompts, the `pkg>` is an indicator
    that you should be using the Pkg REPL (accessible by pressing `]`),
    and isn't part of the actual command.

Once you've done this, you will be able to do `using BioinformaticsBISC195`
in your julia code, as long as this julia project is active.

In addition, use `add` to install the packages
`Revise`, `Plots`, and `DataFrames`.
We'll use those a bit more later.

Add and commit the `Project.toml` and `Manifest.toml` files,

## Using the notebook

In the `notebooks/1-sequence-stats.md` file,
write julia code to calculate the mean and standard deviation
of the lengths and gc content of your coronavirus genomes,
as you did in [Assignment 6](@ref assignment06).
Include a title (with header format)
and a description of what your code is doing.

Remember, you can use the code you've written
in your bioinformatics package just by doing `using <PackageName>`.
Also remember,
in markdown files, julia code should go in "code fences."
Eg.

````md
# Some Coronavirus Analysis

Here's some description of what I'm doing.
I downloaded coronavirus geneomes from NCBI
(see `data/data.md` for more details)

Etc.

```julia
using BioinformaticsBISC195

genomes = parse_fasta("../data/cov2_sequences.fasta")
```

Now I have the genomes, and need to do stats.
Note - your descriptions should be... more descriptive.

```julia
using Statistics
#more code...

```

etc..
````

If you're using VS Code to edit your markdown,
and have both the `julia` and `markdown julia` extensions installed,
you can execute code within code fences
in exactly the same way as you've been doing in `.jl` files.

## No tests

There are no automated tests for your analysis code -
this is research, I don't know what the right answer is!

But this means that it's extra important that you add extra checks
to make sure the code is doing what you intend.

gha_language: Julia


text:
# I18n::Transformers

[![Build Status](https://travis-ci.org/timsly/i18n-transformers.svg?branch=master)](https://travis-ci.org/timsly/i18n-transformers)

Transformers for `I18n` ruby library

`I18n::Transformers` is a `I18n` ruby library plugin that allows transform translations.

`I18n::Transformers` can be used if some or even all translations keys require some transformation.
For example parsing markdown or replacing some symbol.

## Installation

Add this line to your application's Gemfile:

```ruby
gem 'i18n-transformers'
```

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install i18n-transformers

## Usage

The core of this library is `I18n.transformers.register` method.
It can be used to register various transformers or reset all available transformers.
It is designed to register transformers globally.
It returns transformer instance that can be later used with `before`/`after` options.

If some transformers have to be applied only for some set of keys
then this logic has to implemented in the transformer class itself.
Also, it is very important to return original value in this case(see [Transformers chain section](#transformers-chain))

The gem comes with a few built-in transformers:

* generic transformer
* markdown transformer

If symbol was passed as the first argument to `.register` call
it will search thought built-in transformers and try to register it.
If there is no match generic adapter will be used.

### Generic transformer

Generic transformer is designed to handle custom transformers defined as a block.
It is useful for simple transformations.

To register generic transformer call:

```ruby
I18n.transformers.register do |key, value|
  "transformered-#{value}"
end
```

`I18n.translate` key and translation value will be passed to the block.

Each transformer has its name that helps to register transformer after or before some specific transformer.
By default generic transformer generates unique name for each transformer,
but it can be also explicitly specified by passing name as the first argument.

```ruby
I18n.transformers.register 'my_transformer' do |key, value|
  "transformered-#{value}"
end
```

All transformers can be registered before, after or at specific position.
`before`, `after` and `at` options are used for that.

```ruby
I18n.transformers.register 'my_transformer' do |key, value|
  "transformered1-#{value}"
end

another_transformer = I18n.transformers.register after: 'my_transformer' do |key, value|
  "transformered2-#{value}"
end

I18n.transformers.register before: another_transformer, do |key, value|
  "transformered3-#{value}"
end

I18n.transformers.register at: 1, do |key, value|
  "transformered4-#{value}"
end
```

### Markdown transformer

To register built-in markdown transformer use:

```ruby
I18n.transformers.register :markdown
```

Currently it supports [`redcarpet`](https://github.com/vmg/redcarpet) and [`kramdown`](https://github.com/gettalong/kramdown) markdown parsers.

It uses first available adapter so if both are available `redcarpet` will be picked.
To specify adapter use:

```ruby
I18n.transformers.register :markdown, adapter: :redcarpet
```

Markdown transformer is designed to be triggered only for some set of keys.
By default it triggers only for keys ended with `_md` and `.md`.

So specify custom key pattern use:

```ruby
I18n.transformers.register :markdown, key_pattern: /_markdown$/
```

In the example above markdown transformer will be triggered only if key ended with `_markdown`.

If block was specified it will be used instead.
It can be useful to override default transformation behavior.

```ruby
I18n.transformers.register :markdown do |key, value|
  MyMarkdownParser.parse(value)
end
```

Please note that it will be still running only if key matches `key_pattern` option.

Markdown transformer always uses the same name - `'markdown'` - so to register some transformer after/before it use

```ruby
I18n.transformers.register :markdown

I18n.transformers.register 'my_custom_transformer', after: 'markdown' do |key, value|
  Smth.transform(key, value)
end
```

It is designed to be registered only once that's why `name` is always `markdown`.

### Custom transformers

To register custom transformer use:

```ruby
I18n.transformers.register MyCustomTransformer
```

`MyCustomTransformer` has to be inherited from `I18n::Transformers::Collection::Base` class.
Also, to not break transformers chain(see [Transformers chain section](#transformers-chain)),
it is responsible for returning correct value if it needs to be applied only for some set of keys

All options except `before`, `after` and `at` will be passed as the first argument to `.new` call.

Transformer instance can be passed too:

```ruby
I18n.transformers.register MyCustomTransformer.new(:val1, :val2)
```

### Transformers chain

It is very important to return some value from either block or `#transform` method from the custom transformer class
otherwise transformers chain will be broken.

Here is the bad example of custom transformer:

```ruby
I18n.transformers.register do |key, value|
  if key.to_s.start_with? 'key_prefix'
    value.gsub('^symbol^', 'REPLACED_SYMBOL')
  end
end
```

The code above most likely will be broken for all keys that don't start with `key_prefix`.
To fix that we should always fallback to the original value

```ruby
I18n.transformers.register do |key, value|
  if key.to_s.start_with? 'key_prefix'
    value.gsub('^symbol^', 'REPLACED_SYMBOL')
  else
    value
  end
end
```

### Reseting transformers

This library is designed to register all transformers globally.
In a rails app it can be done in initializer.
But if there is a need to reset all transformers `.reset` method can be used.

```ruby
I18n.transformers.reset
```

## Example

To illustrate how this gem works let's assume the following setup

```yaml
en:
  key: my key1 value ^symbol^
  key_md: '**Text with ^symbol^**'
  key_markdown: '*^symbol^*'
```

```ruby
I18n.transformers.register :markdown # let's assume redcarpet gem is available

I18n.transformers.register do |key, value|
  value.gsub('^symbol^', 'REPLACED_SYMBOL')
end
```

Then
```ruby
I18n.translate :key # => my key1 value REPLACED_SYMBOL

I18n.translate :key_md # => <p><strong>Text with REPLACED_SYMBOL</strong></p>

I18n.translate :key_markdown # => *REPLACED_SYMBOL*
```

## Development

After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.

To install this gem onto your local machine, run `bundle exec rake install`. To release a new version, update the version number in `version.rb`, and then run `bundle exec rake release`, which will create a git tag for the version, push git commits and tags, and push the `.gem` file to [rubygems.org](https://rubygems.org).

## TODO

* Think more about missing translations and find a nice way to handle them

## Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/timsly/i18n-transformers.

## License

The gem is available as open source under the terms of the [MIT License](http://opensource.org/licenses/MIT).


text:
---
title: "Anti-Dilution Clause May Prevent Company from Issuing Additional Shares"
author<EMAIL_ADDRESS>tags: ["Term Sheet","Letter of Intent","Representations and Warranties","Subscription Agreement","Company Formation","Rajah","Share Purchase Agreement","Investor Term Sheet","Memorandum of Understanding"]
date: 2015-07-17 00:00:00
description: "When subscribing to shares of a company, consider negotiating an anti-dilution provision in your subscription agreement to avoid having your equity holding in the company significantly diluted."
---

The representation that the company may issue additional shares in the future means that the company may dilute the shares of the subscriber at will. A subscriber who does not wish to give the issuer the ability to dilute their shareholding may require that anti-dilution provisions to be included in the subscription agreement.

The largest shareholder *(Caitlyn Limited) of Azumah Resources* holding 13% of the shares, reinvested $2.1 million. As part of the investment, the subscription agreement contained an anti-dilution clause where the shareholder was to maintain its 13% equity holding for 12 months.

[Read the article here.](http://www.proactiveinvestors.com.au/companies/news/57606/azumah-resources-cornerstone-investor-adds-to-holdings-at-premium-57606.html?)

**Take away:**

- When subscribing to shares of a company, consider negotiating an anti-dilution provision in your subscription agreement to avoid having your equity holding in the company significantly diluted.

repository: clausehound/clausehound-blog

gha_language: TypeScript

repo_name: clausehound/clausehound-blog


text:
# nbnet

nbnet is a single header C (C99) library to implement client-server network code for games, it is more precisely designed for fast paced action games.
nbnet is based on this [great series of articles](https://gafferongames.com/) by Glenn Fiedler.

**Disclaimer**: nbnet is in the early stages of his development and is first and foremost a learning project of mine as I explore online game development. If you are looking for a profesionnal production ready library, this is not the one.

The library currently implements the following features:

- Connection management
- Sending/Receiving both reliable ordered and unreliable ordered messages
- Sending/Receiving messages larger than MTU via a message fragmentation system
- Serialization of integers (signed and unsigned), floats, booleans and byte arrays (at bit level to reduce bandwith usage)
- Simulates bad network conditions for testing purposes (ping, jitter, packet loss, packet duplication and out of order packets)
- Estimates of ping, bandwith (upload and download) and packet loss
- WebRTC support

What is not *yet* implemented but will be in the future:

- Encrypted packets
- Secure authentification system

nbnet does not directly implement any low level "transport" code and rely on the concept of *drivers*. A driver is a set of function definitions that live outside nbnet header and provide a transport layer implementation that will be used by the library to send and receive packets.

nbnet comes with two drivers:

- UDP : work with a single UDP socket, designed for desktop games
- WebRTC : work with a single unreliable/unordered data channel, designed for web browser games

You can see it in action [in this video](https://www.youtube.com/watch?v=BJl_XN3QJhQ&ab_channel=NathanBIAGINI).

## Portability

nbnet is developed with portability in mind. I tested (and will continue to do so) the library on the following systems:

- Windows
- OSX
- Linux

## How to use

In *exactly one* of your source file do:

```
#define NBNET_IMPL

#include "nbnet.h"
```

You also need to provide a driver implementation, if you decide to use the nbnet UDP driver just add:

```
#include "net_drivers/udp.h"
```

after including the nbnet header in the same source file where you defined `NBNET_IMPL`.

nbnet uses two slightly different APIs, one for client code and the other one for server code, you have to use a pair of macros to let nbnet know what API to use: `NBN_GAME_CLIENT` and `NBN_GAME_SERVER`.
What you want to do is define the former when compiling your client code and the later when compiling your server code, with gcc it would look something like:

`gcc -DNBN_GAME_CLIENT client.c -o client`

`gcc -DNBN_GAME_SERVER server.c -o server`

nbnet does not provide any logging capacibilities so you have to provide your own using a bunch of macros:

```
#define NBN_LogInfo(...) SomeLoggingFunction(__VA_ARGS__)
#define NBN_LogError(...) SomeLoggingFunction(__VA_ARGS__)
#define NBN_LogDebug(...) SomeLoggingFunction(__VA_ARGS__)
#define NBN_LogTrace(...) SomeLoggingFunction(__VA_ARGS__)
```

Same thing for memory allocation and deallocation:

```
#define NBN_Allocator malloc
#define NBN_Deallocator free
```

From here I suggest you hop into the examples. If you are interested in using the WebRTC driver, read below.

## WebRTC

nbnet lets you implement web browser online games in C without writing any JS code.

In order to do that you need to compile your code with [emscripten](https://emscripten.org/). You can either use the
`emcc` command directly or use CMake, the examples demonstrate how to do both.

The following emscripten options are mandatory and must always be added to your compilation command line or CMakeLists.txt.

emscripten does not provide a C API for WebRTC so it has to be implemented in JS. nbnet does that for and all you have to
do is add:

`--js-library "net_drivers/webrtc/js/api.js"`

The nbnet JS API uses a bunch of async functions that you need to let emscripten know about:

`-s ASYNCIFY`

`-s ASYNCIFY_IMPORTS="[\"__js_game_client_start\", \"__js_game_client_close\", \"__js_game_server_start\\"]"`

nbnet connection simulation run in a separate thread so if you want to use it you need to compile with:

`-s USE_PTHREADS=1`

If you want to run your code in a web browser you also need to provide a shell file with:

`--shell-file <PATH TO YOUR SHELL FILE>`

To learn about what a shell file is: https://emscripten.org/docs/tools_reference/emcc.html

You can also look at the `shell.html` from the raylib example.

Apart from that you will probably want to add:

`-s ALLOW_MEMORY_GROWTH=1` and `-s EXIT_RUNTIME=1`

For more information: https://emscripten.org/docs/tools_reference/emcc.html

### NodeJS

Most of the time you will want your server code to run in NodeJS. You can get it from [here](https://nodejs.org/en/download/).

Once it's installed you also need to create a `package.json` file. For more information about what this file is:

https://docs.npmjs.com/creating-a-package-json-file

You can check out the `package.json` files used for the echo and raylib examples.

In order to run your server you need to install the needed node packages by running:

`npm install`

from the directory containing your `package.json` file.

Then to run your server:

`node server.js`

`server.js` being the JS file generated by emscripten.

### Web browser

Unless your client is a non graphical application, you will want your client code to run in a web browser.

With the correct options emscripten will output an HTML file, rom here all you need to do is run an HTTP server that serves
this file and open the correct URL in your web browser.

For testing purposes I personally recommend using Python [SimpleHTTPServer](https://docs.python.org/2/library/simplehttpserver.html).

Just run:

`python -m SimpleHTTPServer 8000`

in the directory containing your HTML file. Then, assuming the HTML file is named `client.html`, open `http://localhost:8000/client.html` in your web browser.

One major diffrence with running JS code in a web browser compared to running it in NodeJS is that you cannot use the NodeJS
packaging system. The thing is that the nbnet WebRTC code has some NodeJS packages as dependencies, so in order for nbnet to
run in a web browser we need to "bundle" those packages in something that can be served to a browser.

This seems complicated but it's really not, I personally recommend using [browserify](https://github.com/browserify/browserify).

Once installed you can simply run:

`browserify net_drivers/webrtc/js/nbnet.js -o nbnet_bundle.js`

and include the generated `nbnet_bundle.js` script to your HTML:

`<script src="nbnet_bundle.js"></script>`

See the raylib example.

repository: MSylvia/nbnet

repo_name: MSylvia/nbnet


text:
---
layout: page
title: "Phoenix Framework"
---

Creating a new Phoenix project:

{% highlight bash %}
# Needs node >= 5.0
nvm install 5.4

# Install phoenix
mix local.hex
mix archive.install https://github.com/phoenixframework/phoenix/releases/download/v1.1.2/phoenix_new-1.1.2.ez

# Create phoenix project
mix phoenix.new test_app
cd test_app
mix phoenix.server
{% endhighlight %}

- [Phoenix 1.2.x to 1.3.0 Upgrade Instructions](https://gist.github.com/chrismccord/71ab10d433c98b714b75c886eff17357)

## Open source codebases

- [Evercam](https://github.com/evercam/evercam-server)
  ([deep dive into the codebase](https://hackernoon.com/elixir-deep-dive-evercam-a-10k-loc-phoenix-app-bd84bc20345d))
- [ElixirStatus](https://github.com/rrrene/elixirstatus-web)

## Deployment

- [Elixir Phoenix App deployed into a Load Balanced DigitalOcean setup](http://www.akitaonrails.com/2016/12/23/elixir-phoenix-app-deployed-into-a-load-balanced-digitalocean-setup)
- [Deploying Phoenix on Ubuntu with Gatling](https://dennisreimann.de/articles/phoenix-deployment-gatling-ubuntu-digital-ocean.html)

## Bookmarks

* [Phoenix Guides](http://www.phoenixframework.org/docs/overview)
* [Let's Build a Web App With Phoenix and Ecto](http://www.elixirdose.com/post/elixirdose_intro_to_phoenix)
* [A hands-on intro to building modern web applications with Elixir and Phoenix](http://phoenix.thefirehoseproject.com)
* [Build and test a blazing fast JSON API with Phoenix, an Elixir framework](https://robots.thoughtbot.com/testing-a-phoenix-elixir-json-api)

## Example apps

* [Simple Chat Example, by Chris McCord](https://github.com/chrismccord/phoenix_chat_example)
* [Blox - a simple blog application](https://github.com/drewolson/blox)
* [Phoenix demo app with authentication, admin/user scopes and a websocket chat](https://github.com/pmontrasio/phoenix-demo-app)
* [A simple CRUD application using Elixir and the Phoenix framework](https://github.com/gogogarrett/phoenix_crud)
* [Gaze](https://github.com/ericmj/gaze) - Phoenix with React
* [phoenix-flux-react - An experiment with Phoenix Channels, GenEvents, React and Flux](http://github.com/fxg42/phoenix-flux-react)

gha_language: HTML


text:
# Lightning-Redux [![Build Status](https://travis-ci.org/madmax983/lightning-redux.svg?branch=master)](https://travis-ci.org/madmax983/lightning-redux)

[Redux](http://redux.js.org/) bindings for the [Lightning Component Framework](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm)

## Usage
The new version of Lightning-Redux simplifies the previous iteration down to a single Redux component. It serves as a wrapper around Redux itself, along with a few helper methods specific to Lightning.

### Component Methods
####
**createStore(name, reducer, initialState, middleware):** create the Redux store.

name: The name of the slice of state for the reducer creating the store.

reducer: Initial root reducer

initialState: You can specify an initial shape to your store's shape.

middleware: You can include redux middleware like redux-thunk here. Lightning-Redux automatically wraps this with Redux compose.

**dispatch(action):** Works like you would expect. Dispatches the action to the Redux store. Fun fact: connect also sets a dispatch expando on the connected component for convenience.

**subscribe(listener):** This shouldn't be needed to be implemented, but is provided in case you want to write a custom connect method. The listener callback will be called on store updates.

**replaceReducer(nextReducer):** Wraps Redux's replaceReducer function. Replaces the reducer function in the redux store.

**registerReducer(name, reducer):** Adds the specified reducer function to the redux store with the specificed name as it's slice of state.

**connect(mapStateToAttributes, target):** mapStateToAttributes either a key pair object where the key is the attribute on the component you want set, and the value is either the value in the redux state graph, or a callback function. mapStateToAttributes can also be a function that returns this key pair value. This function receives the state and component to compute the value. You can pass the component you want connected, but if it isn't populated, it will get populated by event.getSource(). It also sets a dispatch expando for convenience in the component's controller methods.

**getState():** Retrieves the store state.

## Installation
Lightning-Redux Unmanaged Packaged (Redux Component, redux, redux-thunk, and reselect static resource): https://login.salesforce.com/packaging/installPackage.apexp?p0=04t50000000M7R0

Lightning-Redux-Examples (Counter and Todo Examples unmanaged package): https://login.salesforce.com/packaging/installPackage.apexp?p0=04t50000000M7RA

Otherwise, you can use the SFDX CLI to convert the source and do a metadata deploy.

## Resources
Redux Documentation: http://redux.js.org/

Awesome Redux: https://github.com/xgrommx/awesome-redux

Lightning Components Developer Guide: https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/intro_framework.htm

Awesome Lightning: https://github.com/mailtoharshit/awesome-lighting

Awesome Salesforce: https://github.com/mailtoharshit/awesome-salesforce


text:
# This is the Documentation for selfup-rejs

### Things to consider:

##### As [cite-reader](https://github.com/cite-reader) mentioned in this [issue](https://github.com/selfup/rejs/issues/13):

##### This database is only as strong as the `fs.writeFileSync` method provided by the `fs` module API
##### This means that if there is a power failure during a table update/write event, your data will more than likely be gone!

* If you can read javascript tests, skip the docs and just go read the tests!
* They are pretty verbose and will get you up to speed on how things work.
* If you like videos, here is a link to the quick demo vid from the README: [vid](https://www.youtube.com/watch?v=dVTePMkw9EE&feature=youtu.be&a)
* If you are not familiar with Javascript Testing Frameworks keep reading!

# How this DB works:

* (POST)   Create a table: `rejs.createTable('tablename')`
* (POST)   Create Multiple Tables: `rejs.createTables('one', 'two', 'three')`
* (POST)   Add data to table: `rejs.newData('tablename', dataObject)`
* **(POST)   Add data to Multiple Tables:**
```
rejs.newDatas(
  ['firstTable', {test: "data"}],
  ['secondTable', {test: "data"}],
  ['thirdTable', {test: "data"}]
)
```
* (DELETE) Delete data by ID in a table: `rejs.deleteById('tablename', '2')`
* (DELETE) Drop a table: `rejs.dropTable('tablename')`
* (DELETE) Multi-Table Drop: `rejs.dropTables('firstTable', 'secondTable')`
* (PUT)    Replace/Overwrite a table: `rejs.updateTable('tablename', dataObject)`
* **(PUT)    Replace/Overwrite Multiple tables:**
```
rejs.updateTables(
  ['firstTable', {test: "new data"}],
  ['secondTable', {test: "new data"}],
  ['thirdTable', {test: "new data"}]
)
```
* (GET)    Table Object Query: `rejs.getTable('tablename')`
* (GET)    Multi-Table Query: `rejs.getTables('table', 'table2', 'table3')`
* (GET)    Find by ID: `rejs.findId('tablename', 'id')`
* (GET)    Where/Select: `rejs.where('tablename', 'any value in a flat object')`

# Examples below:

*In each example, I call a `createTable('someTableName')` to mimic developer behavior. However I don't always call `rejs.dropTable('someTableName')` because each example is to be considered a new, independent example.*

*I create the data for each example so that the steps needed for each method is clear.*

How to have access to the package:

```
const Selfup = require('selfup-rejs')
const rejs = new Selfup
```

This will make the `selfup-rejs` library available in your program.

**createTable**

`rejs.createTable('exampleOne')`

There will now be a folder called 'selfup-rejs'
This folder will now contain a file with no extension named: exampleOne

Create table will not re-create a new table if it already exist!

Inside of this file will be some basic metadata about the table
You will find an example like so: `'0': { table: 'testOne', nextId: 3 }`

This is to never be deleted. This data is required for the database to function.
It also makes your life easier!

**createTables**

`rejs.createTables('one', 'two', 'three')`

There will now be a folder called 'selfup-rejs'
This folder will now contain three files with no extension named:

one, two, and three

Create tables will not re-create new tables if they already exist!

**newData**

```
rejs.createTable('exampleOne')
rejs.newData('exampleOne', {exampleData: "some example stuff"})
```

Now your exampleData table will have the new object appended to the table.
A new ID will point to the object you appended. These ID's are event logs.

What you will find in the table:

```
{
  '0': { table: 'exampleOne', nextId: 2 },
  '1': { exampleData: 'some example stuff' },
}
```

**newDatas**

Works like above, just use arrays as arguments like in the REST verbs section.

**dropTable**

`rejs.dropTable('exampleOne')`

The table/file for exampleOne will now be deleted!

**dropTables**

```
rejs.createTable('firstTable')
rejs.createTable('firstTable')

rejs.dropTables('firstTable', 'secondTable')
```

Now all tables given as arguments will be dropped!

**updateTable**

```
rejs.createTable('testOne')
rejs.newData('testOne',     {test: "old data"})

rejs.updateTable('testOne', {test: "new data"})
```

What you find in the table:

```
{
  '0': { table: 'testOne', nextId: 2 },
  '1': { test: 'new data' },
}
```

As you can see, the old data has been wiped/replaced
The exampleOne data will be wiped/replaced with the new data.
The metadata will go in first, and then the new object will go in right after.

**updateTables**

Works like above, just use arrays as arguments like in the REST verbs section.

**findId**

```
rejs.createTable('testOne')
rejs.newData('testOne', {test: "old data"})

rejs.findId('testOne', '1')
```

You will now have have access to/be returned: `{test: "old data"}`

**deleteById**

```
rejs.createTable('testOne')
rejs.newData('testOne', {test: "old data"})

rejs.deleteById('testOne', '1')
```

You will now just have the metadata left in your table.
If you have 20 ID's, you can remove '16' and keep the rest!

**getTable**

```
rejs.createTable('testOne')
rejs.newData('testOne', {test: "old data"})

rejs.getTable('testOne')
```

This will return the entire table!

```
{
  '0': { table: 'testOne', nextId: 2 },
  '1': { test: "old data" },
}
```

**getTables**

```
rejs.createTable('testOne')
rejs.newData('testOne', {test: "old data"})
rejs.deleteById('testOne', '1')

rejs.createTable('exampleOne')
rejs.newData('exampleOne', {exampleData: "some example stuff"})

rejs.getTables('exampleOne', 'testOne')
```

This will return both tables in a flat array:

```
[
  {
    '0': { table: 'exampleOne', nextId: 2 },
    '1': { exampleData: 'some example stuff' },
  },
  {
    '0': { table: 'testOne', nextId: 2 },
    '1': { test: "old data" },
  }
]
```

**where**

```
rejs.createTable('exampleOne')
rejs.newData('exampleOne', {exampleData: "some example stuff"})
rejs.newData('exampleOne', {exampleData: "top level text"} )
rejs.newData('exampleOne', {exampleData: "top level text"})

rejs.where('exampleOne', 'top level text')
```

This will return an array of all objects with the string searched for at the top level of the objects:

```
[
  {exampleData: "top level text"},
  {exampleData: "top level text"}
]
```

repository: selfup/rejs

gha_language: JavaScript

gha_license_id: NOASSERTION

repo_name: selfup/rejs


text:
# Asset Tracking & Monitoring (ASTRA)
Asset Tracking & Monitoring Solution Accelerator

## About
1) This is the toplevel project which will provide the information regarding setup & deployment of Asset Monitoring Solution.
2) User is expected to follow the guidelines outlined & refer to the individual projects for further details.

## List of Repositories
Following are the repositories relevant for the accelerator:

1) [ARM-Template](https://github.com/MobiliyaTechnologies/ARM-Templates): Azure Resource Manager template for the solution.
2) [AMSMessagingServer](https://github.com/MobiliyaTechnologies/AMSMessagingServer): Node Server for passing Sensor data and rule break alerts.
3) [AMSMobileApplication](https://github.com/MobiliyaTechnologies/AMSMobileApplication): Xamarin based iOS & Android application.
4) [AMSPowerBI](https://github.com/MobiliyaTechnologies/AMSPowerBI): Reports & visualization templates.
5) [AMSRESTServer](https://github.com/MobiliyaTechnologies/AMSRESTServer): Backend server for the solution.
6) [AMSWebApp](https://github.com/MobiliyaTechnologies/AMSWebApp): Frontend web application for the solution.
7) [GatewayMiddleware](https://github.com/MobiliyaTechnologies/GatewayMiddleware): NodeJS application for passing sensor data to IoT hub.

## List of Documents
Following are the list of documents available for reference:

1) User guide: To use the solution deployed.
2) Admin guide: To configure and use the solution deployed.
3) Api Documentaion: Please refer '[AssetMonitoringApi.zip](https://github.com/MobiliyaTechnologies/AMSRESTServer/blob/master/AssetMonitoringApi.zip)' from AMSRESTServer repository.

## List of reference hardware (on premise)

Dell 5000 Gateway: Which acts as sensor aggregator, run edge analytics (Azure Stream Analytics on Edge)

TI Sensortags - 2650

Bosch Sensors - XDK

repository: MobiliyaTechnologies/AssetMonitoring

repo_name: MobiliyaTechnologies/AssetMonitoring


text:
# Pythium catenulatum V.D. Matthews, 1931 SPECIES

#### Status
ACCEPTED

#### According to
The Catalogue of Life, 3rd January 2011

#### Published in
Stud. genus Pythium 47 (1931)

#### Original name
Pythium catenulatum V.D. Matthews, 1931

### Remarks
null

repository: mdoering/backbone

repo_name: mdoering/backbone


text:
# Evennia installation

You can find the latest updated installation instructions and
requirements
[here](https://www.evennia.com/docs/latest/Setup/Installation.html)

repository: evennia/evennia

repo_name: evennia/evennia


text:
# Going full version control with git

You have received an e-mail from a good colleague.

!!! note "email"
    Hey there,

    Thanks for sharing the notebook with your exploratory analysis, the results are really promising! I have some code of my own to compute some statistics. I attached the last version of my program in this e-mail. I think the last version compiled well (I hope) but you may need some dependencies I have in my laptop. I think we can collaborate and do a more in-depth analysis together. Please, send me your current results and I will continue from there. [need some reworking]

    Cheers,

    Galileo

Starting a collaboration by sharing code and analysis by e-mail can be a mess. Most probably, a number of unconnected files, with different versions will appear, and tracking versions and stages will become more a more complicated. We need a tool that help us organize all our files, and make it simple and immediate to share exactly the same files with all your collaborators

Objectives and scope

....

# Introduction to Git

Git is a widely used system (both in academia and industry) for version controlling files and
collaborating on code. It is used to track changes in (text) files, thereby establishing a history of all edits made to each file, together with short messages about each change and information about who made it. Git is mainly run from the command line, but there are several tools that have implemented a graphical user interface to run git commands.

Using version control for tracking your files, and edits to those, is an essential step in making your computational research reproducible. A typical git workflow consists of:

* making distinct and related edits to one or several files
* committing those changes (i.e. telling git to add those edits to the history, together with a message about what those changes involve)
* and pushing the commit to a remote repository (i.e. syncing your local project directory with one in the cloud)

There are many benefits of using git in your research project:

* You are automatically forced into a more organized way of working, which is usually a first step towards reproducibility.
* If you have made some changes to a file and realize that those were probably not a good idea after all, it is simple to view exactly what the changes were and revert them.
* If there is more than one person involved in the project, git makes it easy to collaborate by tracking all edits made by each person. It will also handle any potential conflicting edits.
* Using a cloud-based repository hosting service (the one you push your commits to), like e.g. [Github](https://github.com/) or [Bitbucket](https://bitbucket.org/), adds additional features, such as being able to discuss the project, comment on edits, or report issues.
* At some point your project will be published. Github or Bitbucket (or similar) are excellent places to publicly distribute your code. Other researchers can then use git to access the code needed for reproducing your results, in exactly the state it was when used for the publication.
* If needed, you can host private repositories on Github and Bitbucket as well. This may be convenient during an ongoing research project, before it is publicly published.

The best way to get an idea about git is simply to start using it. The tutorial below will guide you through the essential steps, with a focus on what is needed for making a project reproducible. There are many additional features of both git and the web-based repository hosting services (like Github and Bitbucket) that are not included here. If you are interested in learning more, the web is filled with information (see some examples below)!

## Tell me more

* For a more complete introduction to git, check e.g. [Wikipedia](https://en.wikipedia.org/wiki/Git)
* [A simple git guide](http://rogerdudler.github.io/git-guide/)
* ["Got 15 minutes and want to learn Git?"](https://try.github.io/levels/1/challenges/1)
* [Git reference manual](https://book.git-scm.com/docs)

# Set up
This tutorial depends on files from the course Bitbucket repo. Take a look at the [intro](tutorial_intro.md) for instructions on how to set it up if you haven't done so already.

## Install git

Chances are that you already have git installed on your computer. You can check by running e.g. `git --version`. If you don't have git, install it following the instructions [here](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git).

## Configure git

If it is the first time you use git on your computer, you may want to configure it so that it is aware of your username. This username should match the username you have registered on Bitbucket. This will make it easier when you want to sync local changes with your remote Bitbucket repository.

```
git config --global user.name "Mona Lisa"
```

!!! tip
    If you have several accounts (e.g. both a Github and Bitbucket account), and thereby several different usernames, you can configure git on a per-repository level. Change directory into the relevant local git repository and run:

    ```
    git config user.name "Mona Lisa"
    ```

    This will set the default username for that repository only.

## Create an account at Bitbucket

If you have not done so already, go to [bitbucket.org](https://bitbucket.org/account/signup/) and create an account.

!!! note
    You can also create an account on another online hosting service for version control, e.g. [GitHub](https://www.github.com) or [GitLab](https://about.gitlab.com/). The exercises below are written with examples from Bitbucket, but the same thing can be done on alternative services, although the exact menu structure and link placements differ a bit.

# Practical exercise

## Create a new git repository

* Login to [Bitbucket](https://bitbucket.org/) and press the plus button to the left and select *Create repository*:
    * Make sure you are listed as the owner
    * Add a repository name, e.g. *git_tutorial*
    * You can keep the repo private or make it public, as you wish
    * Skip including a README
    * Make sure Git is selected for version control

![](images/new_repo_bitbucket.png)

You will now be redirected to the repository page. It is an empty repository, so there is not much to see yet. We want to add some contents (files) to the repository. To do that we will first *clone* the repository locally:

* Open a terminal and `cd` to a directory where you want to clone your newly created git repository (perhaps make a new directory for this course if you haven't done so already).

!!! attention
    **Important:** the directory should *not* be within the `reproducible_research_course` directory, since
    this is itself a git-tracked directory.

* Once you are in your directory of choice, run the following command (just make sure to change `user` to your Bitbucket username and `git_tutorial` to your repository name, in case you chose something different):

```bash
git clone<EMAIL_ADDRESS>```

What will happen now is that the git repository will be cloned (i.e. downloaded) to your computer. You might get a warning that the repository is empty (which in fact is the case).

* A new directory, `git_tutorial` (or a different name if you choose so), has now been created, `cd` into that directory.
* This is a git version-tracked directory. How can you know? Run `git status`!

It will probably return something like:

```no-highlight
On branch master. Initial commit. nothing to commit (create/copy files and use "git add" to track).
```

!!! tip
    If you try to run `git status` in a non-git directory, it will say that it is *not a git repository*. The way this works is that git adds a hidden directory `.git/` in the root of a git tracked directory (run `ls -a` to see it). This hidden directory contains all information and settings git needs in order to run and version track your files. This also means that your git-tracked directory is self-contained, i.e. you can simply delete it and everything that has to do with git in connection to that directory will be gone.

 Lets do that!
* Copy the following files and directories from the `reproducible_research_course/git` directory, into your `git_tutorial` directory:
    * `Dockerfile`
    * `Snakefile`
    * `config.yml`
    * `environment.yml`
    * `code/`
* Once you have done that, run `git status` again. It will tell you that there are files in the directory that are not version tracked by git.

!!! note
    For the purpose of this tutorial, the exact contents of the files you just copied are not important. But you will probably recognize many of them, as they are all files used in the [MRSA case study](tutorial_intro.md). The `environment.yml` file contains the Conda environment with all the software used in the analysis (see the [Conda tutorial](conda.md)). The `Snakefile` and `config.yml` are both used to define the Snakemake workflow, that you should recognize from the [Snakemake tutorial](snakemake.md). The `Dockerfile` contains the recipe for making a Docker container for the analysis, this will be convered in detail in the [Docker tutorial](docker.md). The `code/` directory contains an R Markdown report that is used in the final step of the analysis (more on this in the [R Markdown tutorial](rmarkdown.md)).

!!! note "Quick recap"
    We have used two `git` commands this far:

    * `git clone` - to clone a remote repository locally (e.g. from Bitbucket). This is only done the first time you want to download the repository locally.
    * `git status` - this is a command you should use *a lot*. It will tell you, amongst other things, the status of your git clone in relation to the online remote repository.

## Committing

* We will now commit the untracked files. A commit is essentially a set of changes to a set of files. Preferably, the changes making out a commit should be related to something, e.g. a specific bug fix or a new feature. Our first commit will be to add the copied files to the repository. Run (as suggested by `git status`):

```bash
git add Dockerfile Snakefile
```

* Run `git status` again! See that we have added Dockerfile and Snakefile to our upcoming commit (listed under "*Changes to be committed*"). This is called the staging area, and the files there are staged to be committed.
* We might as well commit all files in one go! Use `git add` on the remaining files as well:

```bash
git add config.yml environment.yml code/
```

* Run `git status` and see that all files are in the staging area, and that no files are listed as untracked.
* We are now ready to commit!  This should be a short description of what the commit contains.

!!! tip
    There are some general guidelines on how to write good commit messages. The following points are
    often mentioned:

    - Separate subject from body with a blank line
    - Limit the subject line to 50 characters
    - Capitalize the subject line
    - Do not end the subject line with a period
    - Use the [imperative mood](https://en.wikipedia.org/wiki/Imperative_mood) in the subject line
    - Wrap the body at 72 characters
    - Use the body to explain what and why vs. how

    In the command above we just added a short subject line ("Add initial files"). It is capitalized, less
    than 50 characters, does not end with a period, and uses imperative mood (Add!). It is possible to add a
    descriptive body text as well, as hinted by the points above. This is easiest done in a text editor. If
    you run `git commit` without the `-m` flag, git will open the default terminal text editor (can be configured)
    where you can write a longer commit message and body.

* Run `git status` (yep, again!). It should tell you "*nothing to commit, working directory clean*".
* Now, let's edit a file. Open up `environment.yml` in your favorite editor, and change the version of bowtie2 to a different value, e.g. `bowtie2=2.1`.
* Run `git status`. It will tell you that there are modifications in one file (`environment.yml`) compared to the previous commit. This is nice! We don't have to keep track of what files we have edited, git will do that for us.
* Run `git diff environment.yml`. This will show you the changes made to the file. A `-` means a deleted line, a `+` means an added line. There are also shown a few lines before and after the changes, to put them in context.
* Let's edit another file! Open `config.yml`and change the line `genome_id: NCTC8325` to `genome_id: ST398`. Run `git status`. Run `git diff`. If we don't specify a file, it will show all changes made in any file, compared to the previous commit. Do you see your changes?
* Ok, we made our changes. Let's commit them! Run:

```bash
git add config.yml environment.yml
```

This will add both our files to the staging area at the same time. Run `git status` and see that the changes in both `config.yml` and `environment.yml` are ready to be committed.

But wait a minute! Shouldn't each commit optimally be a specified set of changes? Yes! So we want to make two commits, one for each change.

* Let's remove `environment.yml` from the staging area. `git status` tells us how to do this: "*(use "git reset HEAD <file>..." to unstage)*". So run:

```bash
git reset HEAD environment.yml
```

* Run `git status` again. See that now only `config.yml` is staged for being committed, whereas the changes in `environment.yml` are tracked by git, but not ready to be commited.
* Commit the changes in `config.yml`:

```bash
git commit -m "Change to ST398 for alignment"
```

* Add and commit the changes in `environment.yml`:

```bash
git status
git add environment.yml
git status
git commit -m "Change bowtie2 version"
git status
```

You don't have to run `git status` between each command, but it can be useful in the beginning while learning what each command does.

* To see a history of our changes so far, run:

```bash
git log
```

As you can see, each commit is a point in history. The more often you commit, and the more specific you keep your commits, the better (more fine-grained) history and version tracking you will have of your files.

* We can also try to delete a file:

```bash
rm Dockerfile
```

* Run `git status`. As you can see, git tells us that the file is deleted, but that the deletion is not committed. In the same way as we commit edits to files, we need to commit a deletion of a file:

```bash
git add Dockerfile
git status
git commit -m "remove Dockerfile"
git status
git log
```

Here we used `rm Dockerfile` to delete the file and `git add Dockerfile` to stage the deletion. You can also use `git rm Dockerfile` to do both these operations in one step.

!!! note "Quick recap"
    We now added four important git commands to our repertoire:

    * `git add` - adds a file so that changes in that file can be committed.
    * `git rm` - the opposite of `git add`, i.e. sets a file to be deleted in the next commit.
    * `git commit` - commits the changes we have staged (by using `git add` or `git rm`).
    * `git log` - shows us the commit history.

## Pushing

So far we have just worked locally. A strength with git is that we can add a remote location to push our commits to. In fact, we already have setup such a remote, since we created the repository at Bitbucket and cloned it locally. The idea is that you work and edit your files locally, and commit changes as you go along. At some points, preferably as often as possible, you push your changes to the remote. Your local copy and the remote copy are then in sync. In principle, you can now safely delete your local copy since everything is backed up in the cloud, including the full commit history. This also enables collaboration. Several users can work on their local clones of a given repository and push changes to a common remote location. Let's try this out in practice!

* Run `git remote -v`. This will show you what remote location is connected to your local git clone. The short name of the default remote is usually "*origin*".
* Run `git branch`. This will show you the name of the current branch. By default this will be "*master*".

!!! attention
    We have not mentioned branches yet (it is touched on at the end) but they are a major feature of git. They allow you to have different "versions" of a repository. As an example, during software development it is common to have a release branch containing code that is working correctly, and a development branch containing code with new features and fixes but also potential bugs that have not been fixed yet. Once the development branch is fixed and working, it can be merged into the release branch. End-users will typically use the code in the release branch only.

* Now we will push the latest commits to the master branch to our remote origin:

```bash
git push -u origin master
```

* Run `git status`. This should tell you that "*Your branch is up-to-date with 'origin/master'.*".
* Go to your Bitbucket repository in your browser again and click on Source to the left. You should now see that the files you have locally appear here as well!
* Click on `config.yml`. You will see the contents of the file. Notice that it is the latest version, where we changed "genome_id".

![](images/bitbucket_config_yml.png)

* Click on Diff, in the upper right corner. You will see the changes made to this file compared to the previous commit.

![](images/bitbucket_config_yml_diff.png)

* Click History. You will see an overview of the commits involving changes made to this file.

![](images/bitbucket_config_yml_history.png)

* Click Commits, to the left in the main menu. You will see an overview of all commits made. Click on a specific commit to see the changes introduced by that commit.
* Click on the commit that was the initial commit, where we added all the files.

![](images/bitbucket_initial_commit.png)

You can now click on View source in the top right corner. You will now see the files as they were when we first added them. Specifically you can see that the `Dockerfile` is back, even though we deleted it! Click on Source to the left again to return to the latest version.

!!! note "Quick recap"
    We now learned yet another important git command:

    * `git push` -  to push local commits to the remote repository

## Conflicts

We will now learn how to manage conflicts. This is important to know, since it will probably happen sooner or later. It can get a bit tricky, but the important thing is not to panic! :)

* On the Bitbucket web page, click on `environment.yml` and click Edit. We can now edit this file directly on the web. This is generally not recommended, but we will do it here to demonstrate a point.
* Let's pretend that using multiqc version 1.3 did not work. Change the multiqc version to 1.4:

```yaml
multiqc=1.4
```

* Click Commit. Add the commit message: "Update multiqc version to 1.4". Click Commit.
* Click Commits to the left to see the commit history, and your latest change at the top.

Now we have a change in the remote repository that is not yet in our local clone. This could happen for instance if a collaborator of yours committed a change and pushed it to Bitbucket.

* Go back to your local terminal. Run `git status`. Notice that git says: "*Your branch is up-to-date with 'origin/master'.*". This is of course not true, but our local git clone is not yet aware of the remote changes. We will get those changes soon.
* But first, we will edit `environment.yml` locally as well! (It may be the case that your collaborator thought it was good to use multiqc version 1.4, whereas you thought it would be better to use multiqc version 1.2, but neither of you communicated that to the other.) Use a text editor and change the multiqc line to:

```yaml
multiqc=1.2
```

* Commit your change (use `git status` along the way if you want to check what is happening in the different steps):

```bash
git status
git add environment.yml
git status
git commit -m "Downgraded multiqc to v1.2"
git status
```

* Now let's try to push this commit!

```bash
git push
```

!!! tip
    Note that after the initial push you probably don't have to specify `-u origin master`, git will figure that out by itself.

* Read the error message. It should be fairly informative of what is going on. In essence it will not allow you to push since there are conflicting changes made to the remote repository.

* We will now download the changes made to the remote:

```bash
git fetch
```

* Now run `git status`. Unlike before, our local git clone now is aware of the latest changes pushed to the remote. It will tell you something along the lines: "*Your branch and 'origin/master' have diverged,
and have 1 and 1 different commit each, respectively.*".
* Now, since we ran `git fetch` our local git has up-to-date information about the status of the remote repository. We can therefore run the following to see what the difference is between the current state of our local clone and the master branch on the remote origin:

```bash
git diff origin/master
```

* Now let's try to integrate the remote changes with our local changes and get up to sync with the remote:

```bash
git pull
```

!!! tip
    Note that you can skip the `git fetch`command if you want to and run `git pull` directly. The difference is that `fetch` will just update git with the latest information of the remote status, whereas `pull` will try to integrate and sync those changes to your local clone directly.

* As you have probably noticed, the `git pull` command resulted in a conflict. Git tells us about this and suggests that we should fix the conflicts and commit that.
As always, run `git status` to get an overview! You will see that you have, so called, unmerged paths and that the conflicting file is `environment.yml`, since both modified the same line in this file. To fix a conflict, open the affected file in a text editor. You will see that it now looks something like this:

```
channels:
- conda-forge
- bioconda
dependencies:
- fastqc=0.11.6
- sra-tools=2.8
- snakemake-minimal=5.3.0
<<<<<<< HEAD
- multiqc=1.2
=======
- multiqc=1.4
>>>>>>> d9b35ef61d2fde56fcbd64aacb10a96098c67cbf
- bowtie2=2.3
- samtools=1.6
- htseq=0.9
- graphviz=2.38.0
- xorg-libxrender
- xorg-libxpm
- r-ggplot2=3.1.1
- r-reshape2=1.4.3
- r-pheatmap=1.0.12
- bioconductor-rtracklayer=1.42.1
- bioconductor-geoquery=2.50.5
- r-rmarkdown=1.12
```

The part between `<<<<<<< HEAD` and `=======` is your local version, and the part between `=======` and `>>>>>>> d9b35ef61d2fde56fcbd64aacb10a96098c67cbf` is the one added to the remote and which caused the conflict when you tried to pull those changes to your local repository. The long sequence of characters is the commit id (the first 7 are e.g. displayed on Bitbucket under Commits) which will be different for your repository.

* It is now up to you to decide which version to keep, or to change it to a third alternative. Let's say that you are confident that it is better to run multiqc v1.2 rather than v1.4. Edit the file so that it looks like you want it to, i.e. remove the lines added by git and delete the line with `multiqc=1.4`. The final file should look like this:

```yaml
channels:
- conda-forge
- bioconda
dependencies:
- fastqc=0.11.6
- sra-tools=2.8
- snakemake-minimal=5.3.0
- multiqc=1.2
- bowtie2=2.3
- samtools=1.6
- htseq=0.9
- graphviz=2.38.0
- xorg-libxrender
- xorg-libxpm
- r-ggplot2=3.1.1
- r-reshape2=1.4.3
- r-pheatmap=1.0.12
- bioconductor-rtracklayer=1.42.1
- bioconductor-geoquery=2.50.5
- r-rmarkdown=1.12
```

* Run `git status`, notice that it says *use "git add <file>..." to mark resolution*? Let's do that!

```bash
git add environment.yml
```

* Run `git status` again! It will now tell us: "*All conflicts fixed but you are still merging. (use "git commit" to conclude merge)*.". So, you probably guessed it, run:

```bash
git commit -m "Merge and set multiqc to v1.2"
```

* Finally, push these changes to Bitbucket:

```bash
git push
```

* Go to Bitbucket in the browser and click Commits. You should be able to see a graph showing that the paths diverged (where one commit set the version to 1.4 and the other to 1.2) and that they are later merged, and the conflict fixed!

!!! note "Quick recap"
    We now learned how to sync our local clone with the remote one on Bitbucket, and how to fix potential conflicting commits. We added these commands to our repertoire:

    * `git fetch` - downloads information from the remote repository.
    * `git pull` - both fetches and integrates changes from the remote repository.

## Ignoring files

Git is aware of all files within the repository. However, it is not uncommon to have files that we don't want git to track. For instance, our analysis might produce several intermediate files and results. We typically don't track such files. Rather, we want to track the actual code and other related files (e.g. configuration files) that produce the intermediate and result files, given the raw input data.

* Let's make some mock-up intermediate and result files. These are some of the files that would have been generated by the Snakemake workflow if it was run.

```bash
mkdir intermediate
mkdir results
touch intermediate/multiqc_general_stats.txt
touch results/supplementary.pdf
touch log.tmp
```

* Run `git status`. You will see that git tells you that you have untracked files. However, we don't want git to track these files anyway. To tell git what files to ignore we use a file called `.gitignore`. Let's create it:

```bash
touch .gitignore
```

* Open the `.gitignore` file in an editor and add the following lines to it:

```
# Ignore these directories:
results/
intermediate/

# Ignore temporary files:
*.tmp
```

* Run `git status` again. Now there is no mention of the `results` and `intermediate` directories or the `log.tmp` file. Notice that we can use wildcards (\*) to ignore files with a given pattern, e.g. a specific extension.

* Go ahead and add, commit, and push the `.gitignore` file.

!!! note "Quick recap"
    We now learned how to use a `.gitignore` file to control what directories and files git should ignore.

## Tagging

Git allows us to tag commits. This is of particular importance when it comes to reproducible research. We can tag commits that represent important points in the history of our project. This can be, for example, the version of the repository that was used for the manuscript submission, the version used during resubmission, and, most importantly, the version used for the final publication. The first two examples are mainly useful internally, but the latter is essential for other researchers to be able to rerun your published analysis. Let's try this out!

* Let's assume that the status of the repository as it is now is ready for a submission to a journal. It may for example contain the scripts that were used to generate the manuscript figures. Let's add a tag:

```bash
git tag "submission1"
```

* To push this tag to Bitbucket we use:

```bash
git push --tags
```

* Go to Bitbucket and check Commits. Can you see that the tag has been added?
* Let's assume we now got comments from the reviewers, and by fixing those we had to update our code. Open `config.yml` and change the line `max_reads: 25000` to `max_reads: 50000`. Commit and push that change:

```bash
git add config.yml
git commit -m "Increase number of reads"
git push
```

* Now let's say that the reviewers were happy and the manuscript was accepted for publication. Let's immediately add a tag:

```bash
git tag "publication"
git push --tags
```

* After the study was published you realized that you get nicer QC information if you upgrade multiqc. Open `environment.yml` and change `multiqc=1.2` to `multiqc=1.5a`.  Here users can download a compressed file containing the repository at the versions specified by the tags.

![](images/bitbucket_downloads.png)

Alternatively, git users who want to reproduce your analysis with the code used for the publication can clone the Bitbucket repository and then run `git checkout publication`.

* You can try this in your local clone, run:

```bash
git checkout publication
```

* Open `environment.yml` and note that the multiqc version now is back to 1.2! To go back to the latest version, run:

```bash
git checkout master
```

* Again, open `environment.yml` and see that it now has version 1.5a!

* Finally, you could run `git log --oneline --decorate` to get a condensed commit history, where you should
also be able to see the tagged commits.

!!! note "Quick recap"
    We now learned how to tag important commits:

    * `git tag` - add a tag to a commit
    * `git checkout` - update files to match the versions in the given branch or tag name

## Branching and merging

A more advanced, but commonly used, feature of Git is called branching. Branching allows you to diverge from the main line of work and edit or update your code and files, e.g. to test out a new analysis or some experimental feature, without affecting your main work. If the work you did in the branch turns out to be useful you can merge that back into your main branch. On the other hand, if the work didn't turn out as planned, you can simply delete the branch and continue where you left off in your main line of work. Another use case for branching is when you are working in a project with multiple people. Branching can be a way of compartmentalizing your teams work on different parts of the project and enables merging back into the main branch in a controlled fashion.

* Let's start trying out branching! Recall that we can see the current branch by running:

```bash
git branch
```

This tells us that there is only the master branch at the moment.

* Let's make a new branch:

```bash
git branch test_alignment
```

* Run `git branch` again to see the available branches. Do you note which one is selected as the active branch? Let's move to our newly created branch:

```bash
git checkout test_alignment
```

!!! tip
    You can create and checkout a new branch in one line with `git checkout -b branch_name`

Let's add some changes to our new branch! We'll use this to try out a different set of parameters on the sequence alignment step of the case study project.

* Edit the `Snakefile` so that the shell command of the `align_to_genome` rule looks like this (add the `--very-sensitive-local` option):

```bash
shell("bowtie2 --very-sensitive-local -x " + indexBase + " -U {input.fastq} > {output} 2> {log}")
```

* Add and commit the change!

* To get a visual view of your branches and commits you can use the command:

```bash
git log --graph --all --oneline
```

We can push the commits in this branch to our remote repository if we want, but one could also choose to just have it locally and then merge it into the master branch when needed.

* Anyway, let's push it!

```bash
git push -u origin test_alignment
```

!!! note
    The `-u` in the command above sets the remote (upstream) tracking to origin for our `test_alignment` branch. If you would have just typed `git push test_alignment` git would not know where to push it. However, the next time you push commits to this branch you can simply use `git push` without the `-u` since we only need to specify the remote once. Again, you can see your remote locations using `git remote -v`. You will see it's name (e.g. origin) and URL.

* Go the the repository at Bitbucket in your browser and see if the new branch has appeared. Under "Source" you can select which branch to view. Can you see the difference in the `Snakefile` depending on which branch you choose? Under "Commits" you should be able to see the commit history of all branches together with a graph.

* Make an additional edit to the `Snakefile`. To the same line as above, add the `--trim5 5` flag:

```bash
shell("bowtie2 --very-sensitive-local --trim5 5 -x " + indexBase + " -U {input.fastq} > {output} 2> {log}")
```

* Add, commit and push this change. Remember, you should be able to just use `git push` now.

It is often useful to see what the differences exists between branches. You can use the `diff` command for this:

```bash
git diff master --color-words
```

This shows the difference between the active branch (test_alignment) and master. Here we add the argument `--color-words` which should display the difference on a word- rather than line-basis. Do you see that git reports `--very-sensitive-local --trim5 5` to be the difference between the test_alignment and master branches?

Now, assume that we have tested our code and the alignment analysis is run successfully with our new parameters. We want to merge our work into the master branch. It is good to start with checking the differences between branches (as we just did) so that we know what we will merge.

* Next, checkout the branch you want to merge into, i.e. master:

```bash
git checkout master
```

* To merge, run:

```bash
git merge test_alignment
```

A default merge commit message appears. Close the terminal editor (e.g. ctrl + X if Nano or :wq, Enter if Vim). Run `git log --graph --all --oneline` again to see how the merge commit brings back the changes made in test_alignment to master.

!!! note
    When merging it is not uncommon to encounter merge conflicts. This can happen e.g. if work has continued on the master branch that is in conflict with the test_alignment branch (in this example). Handle these conflicts in the same manner as was described above.

!!! tip
    If working on different features or parts of an analysis on different branches, and at the same time maintaining a working master branch for the stable code, it is convenient to periodically merge the changes made to master into relevant branches (i.e. the opposite to what we did above). That way, you keep your experimental branches up-to-date with master and make them more easy to merge into master when time comes.

* If we do not want to do more work in test_alignment we can delete that branch:

```bash
git branch -d test_alignment
```

* Run `git log --graph --all --oneline` again. Note that the commits and the graph history are still there? A branch is simply a pointer to a specific commit, and that pointer has been removed.

The above command only deleted the local branch. If you want to remove the branch from the remote repository as well, run:

```bash
git push origin --delete test_alignment
```

!!! note "Quick recap"
    We have now learned how to divide our work into branches and manage those:

    * `git branch branch_name` - create a new branch
    * `git checkout` - update files to match the versions in the given branch or tag name
    * `git merge` - to merge one branch into another

repository: ldarriba/droplets

repo_name: ldarriba/droplets


text:
# fieldb-auth [![Build Status](https://secure.travis-ci.org/OpenSourceFieldlinguistics/AuthenticationWebService.png?branch=master)](http://travis-ci.org/OpenSourceFieldlinguistics/AuthenticationWebService)

Authentication web services for FieldDB

## Getting Started
Install the module with: `npm install fieldb-auth`

```javascript
var fieldb_auth = require('fieldb-auth');
```

## Documentation & Dev Sandbox
* https://authdev.fielddb.org

## Examples
* https://authdev.fielddb.org

## Contributing
In lieu of a formal styleguide, take care to maintain the existing coding style. Add unit tests for any new or changed functionality. Lint and test your code using [Grunt](http://gruntjs.com/).

## Release History
* v1.16  mongoose auth & everyauth
* v1.32  switched to couchdb
* v1.62  gravatars
* v1.72  server side support for user creation for spreadsheet (without the offline prototype)
* v1.102 support for Learn X users
* v2.12.0 support for psycholinguistics dashboard users and branded emails depending on the client side
* v2.44.22 updated architecture from nodejs 0.6 to 0.12 to build consitent api for v2

## License
Licensed under the Apache, 2.0 licenses.

repository: jrwdunham/AuthenticationWebService

repo_name: jrwdunham/AuthenticationWebService


text:
# fn-clean
firmennest base template

# Version History

__1.5.1 Feb 26, 2021__

- uikit update to 3.6.17
- better cf7 compatibility
- siteorigin custom widget compatibility

__1.5.0 Apr 24, 2020__

- workflow update + cleanup in index, archive & single.php + better standard styling
- added sidebar.php
- added fn Theme Menu
- better yoast compatibility
- removed emoji & comments
- added framework in assets
- styled 404 page
- removed unimportant classes
- removed unused custom fields
- better cf7 compatibility
- added block editor styles
- added own jquery in frontend / remove wp jquery in frontend

__1.4.0 Feb 10, 2020__

- Happy New Year!
- fontawesome update to v5.12.1
- fixed color of em and code elements in variables.less
- workflow update + cleanup in index, archive & single.php
- fixed intro image showing up for index, archive & single.php in template/header/bottom.php
- compiled version update for main.css
- added attachments.php for seo - creates redirect

__1.3.8 Aug 19, 2019__

- added language attribues in header.php
- update to uikit 3.1.7
- removed call for fontawesome.css in lib/theme/assets.php
- added call for fontawesome less-files in assets/theme/less/main.less
- added fontawesome files to less instead of css for easier updates & variables usage
- added form styles for checkbox & ajax-loader in assets/theme/less/theme/forms.less
- added file for content functions & added function for clean phone numbers in lib/theme/content.php
- added call for content.php in lib/theme/config.php
- fixed non-displaying styles for backend-editor lib/theme/editor.php
- added more styles for backend-editor in assets/theme/less/theme/editor.less

__1.3.7 Jul 3, 2019__

- added space to custom class attribute (fn_icon) in shortcodes.php

__1.3.6 Jun 24, 2019__

- removed cookie notice in header.less
- added cookie notice in footer.less
- fixed css in assets/theme/less/theme/header.less:
- fontawesome update to 5.9.0 #10

__1.3.5 Apr 26, 2019__

- uk-button-default styles added in base.less
- often used variables added in variables.less
- shortcodes for owner and mobile added, fn-icon shortcode renamed to icon in shortcodes.php
- added option for owner and mobile in administration.php
- post thumbnail fallback added in index.php, archive.php & single.php
- typo fixed + uk-width-1-1 removed in template/footer-center.php
- google+ call removed, uk-width-1-1 removed in template/footer-bottom.php

__1.3.4 Feb 23, 2019__

- removed user-scalable=no for google audit
- added dropdown styles and changed offcanvas styling in assets/theme/less/header.less
- updated logo call in template/header/center.php
- changed fa-phone icon in template/footer/center.php
- added uikit color fix in assets/theme/less/header.less
- updated css & codekit files to match recent changes

__1.3.3 Feb 5, 2019__

- fixed order for js files in lib/theme/assets.php

__1.3.2 Jan 11, 2019__

- Happy New Year!
- fontawesome update to v5.6.3 #10

__1.3.1 Dez 21, 2018__

- added analytics-shortcode to shortcodes.php

__1.3.0 Dez 12, 2018__

- changed cookie- & analytics-script in header.php

__1.2.9 Dez 6, 2018__

- added versioning to main.css & theme.js in lib/theme/assets.php
- button formats updated in lib/theme/editor.php

__1.2.8 Nov 30, 2018__

- multilanguage support was added to the theme #13
- fontawesome update to v5.5.0 #10
- added some shortcodes to match the theme settings in lib/theme/shortcode.php
- added antispambot to the mail-shortcode in lib/theme/shortcode.php
- added a fn-icon shortcode in lib/theme/shortcode.php
- logo changed to shortcode and more advanced favicon code was added in header.php
- changed the value of @global-muted-color to make subnav-items more readable in assets/theme/less/theme/variables.less
- added z-index to the cookie alert in assets/theme/less/theme/content.less #19
- css files were updated to match the recent changes in assets/theme/css
- theme.js was renamed to base.js and a new theme.js was added in assets/theme/js

__1.2.7 Nov 6, 2018__

- added IE render fix in header.php

__1.2.6 Aug 31, 2018__

- added animated burger-menu in template/header/center.php + header.less #14
- added selection color and container variables in assets/theme/less/theme/variables.less #15 + #16
- changed name of singular.less to content.less in assets/theme/less/theme/ #17
- update to fontawesome 5.3.1 #10
- update to uikit 3.0.0 rc 12 #18

__1.2.5 Jul 26, 2018__

- update to fontawesome 5.2

__1.2.4 Apr 27, 2018__

- uikit 3 updates in various files #11 (this also fixes #1 because uikit2 did need fa4)
- uikit 3 icons added in assets/images #11
- removed some files because they're not longer necessary #11 #1
- minor changes in lib/system/medien.php and lib/system/menus.php
- added blog.less in assets/less/theme
- changed acf fields in lib/system/administration.php
- added cookie notice to header.php and acf-fields #7
- update to fontawesome 5.1

__1.2.3 Apr 27, 2018__

- removed content and added acf-field call in 404.php
- added 404 content edit functionality in lib/system/administration.php

__1.2.2 Mar 27, 2018__

- removed titan-framework in order to use acf-option-pages
- added option-pages & -fields calls in lib/system/administration.php
- changed titan-framework-calls to acf option-field-calls in various files
- added image-sizes for the new options-pages in lib/system/medien.php

__1.2.1 Mar 12, 2018__

- added theme-settings output-shortcodes in lib/shortcode.php #2
- changed icons to fa5 in template/footer/center.php #5
- fixed typos in misc. template files #3
- changed css-request in lib/theme/assets.php #4

__1.2.0 Feb 24, 2018__

- added unzip.php to lib to unzip the titan-framework for workflow-speedup
- removed unused php-variables in singular.php
- removed unused custom header function in lib/system/administration.php
- removed span-use for headline-formats in lib/theme/editor.php
- added fallback-menu with create-menu link in lib/system/menus.php
- typo update in lib/system/menus.php
- fixed mobile styles in assets/theme/less/theme/header.less
- fixed offcanvas, added close-button, added fa5, added fallback-menu in template/header/center.php
- changed logo-usage and added fallback-menu in template/footer/center.php
- set overall box-sizing to border-box in assets/theme/less/theme/base.less
- added uikit variables in assets/theme/less/theme/variables.less
- changed focus-background to primary-color in assets/theme/less/theme/forms.less
- added opening footer tag in template/footer/top.php
- added closing footer tag in template/footer/bottom.php
- added support for custom editor styles lib/theme/editor.php
- added assets/theme/less/theme/editor.less
- added assets/theme/css/editor.css and map
- added fa5 fonts in assets/theme/fonts/
- added assets/theme/css/fontawesome-all.min.css
- updated main.css with latest less-changes

__1.0.7 Oct 27, 2017__

- added intro-image call in template/header/bottom.php
- added intro-image styles in assets/theme/less/theme/singular.less
- mobile menu class changes in template/header/center.php
- added hover and mobile menu styles in assets/theme/less/theme/header.less

__1.0.6 Sep 22, 2017__
- added version history in README.md
- fixed option-name id in template/footer/footer-bottom.php
- added fn-footer-top widget call template/footer/footer-top.php
- added fn-header-bottom widget call template/header/header-bottom.php
- added button styling in assets/theme/less/theme/base.less
- fixed ul structure, added li active & hover in template/header/header-center.php

__1.0.5 Sep 18, 2017__
- removed wrong reference in titan/lib/class-admin-page.php

__1.0.4 Aug 25, 2017__
- social variables deleted in template/footer/footer-center.php
- pinterest added in template/footer/footer-bottom.php
- pinterest added & analytics deleted in lib/theme/settings.php
- analytics link to theme settings deleted in header.php

__1.0.2 - Aug 17, 2017__
- offcanvas id fix in header.php

__1.0.1 – Jul 8, 2017__
- analytics issue fixed in header.php

__1.0.0 - Jul 1, 2017__
- initial commit

repository: firmennest/fn-clean

repo_name: firmennest/fn-clean


text:
以间隔生成值。

**别名** : [ `tf.compat.v1.lin_space` ](/api_docs/python/tf/linspace), [ `tf.compat.v1.linspace` ](/api_docs/python/tf/linspace), [ `tf.compat.v2.linspace` ](/api_docs/python/tf/linspace)

```
 tf.linspace(
    start,
    stop,
    num,
    name=None
)

```

A sequence of  `num`  evenly-spaced values are generated beginning at  `start` .If  `num > 1` , the values in the sequence increase by  `stop - start / num - 1` ,so that the last one is exactly  `stop` .

#### 例如：

```
 tf.linspace(10.0,) => [ 10.0  11.0  12.0]

```

#### 参数：
- **`start`** : A  `Tensor` . Must be one of the following types:  `bfloat16` ,  `float32` ,  `float64` .0-D tensor. First entry in the range.
- **`stop`** : A  `Tensor` . Must have the same type as  `start` .0-D tensor. Last entry in the range.
- **`num`** : A  `Tensor` . Must be one of the following types:  `int32` ,  `int64` .0-D tensor. Number of values to generate.
- **`name`** : A name for the operation (optional).

#### 返回：
A  `Tensor` . Has the same type as  `start` .

repository: veaba/tensorflow-docs

repo_name: veaba/tensorflow-docs


text:
# silverstripe-gridfieldlimititems
Simple component which automatically limits the maximum number of items displayed in a GridField (including modifying
actual relations).

**Important:** This works well as a centralized method to maintain an actual hard limit on the number of `has_many` and
`many_many` relations. Therefore, this will modify those relations and doesn't (yet) simply limit the number of items displayed in a grid field.

## Installation

1. Run `composer require patricknelson/silverstripe-gridfieldlimititems`
2. Run `sake dev/build`

## Example Usage

**Quick Start**

Start managing a relation using the `GridFieldConfig_LimitedRelationEditor` like so:

```php
// Setup a new relation editor with an upper hard limit of 10 items. Items past this amount will be automatically
// removed by GridFieldLimitItems (setup in this relation editor).
$gridConfig = GridFieldConfig_LimitedRelationEditor::create(10);
$gridField = new GridField('RelationName', 'Relation Title', $this->MyRelation()->sort('Sort'), $gridConfig);
$fields->addFieldToTab('Root.main', $gridField);
```

You can setup extra configuration options as well (most options have been included):

```php
// Setup a brand new limiter...
$limiter = new GridFieldLimitItems(10); // Limit to max of 10.
$gridConfig->addComponent($limiter);

// ... or get from an existing configuration.
$limiter = $gridConfig->getComponentByType('GridFieldLimitItems');

// Setup the limiter with a few extra options.
$limiter->setNoteBelow(); // Ensure note displays below grid field instead of on top (default).
$limiter->setRemoveFromTop(true); // Removes excess items from the top of the list instead of the bottom (default).

// You can even setup a callbacks to prevent any manipulation from taking place under certain circumstances.
$limiter->onBeforeManipulate(function(GridField $grid, SS_List $list) use($disableLimiting) {
	// Will prevent manipulation if you return false from this closure, otherwise operates as normal.
	if ($disableLimiting) return false;
});

// Or do something after list manipulation takes place, like so...
$limiter->onBeforeManipulate(function(GridField $grid, SS_List $list) {
	SS_Log::log(print_r($list->map()), SS_Log::DEBUG);
});
```

**Warning:** Since this will modify a relation as a component, it's best to ensure that the relation itself is not being
modified by any other components, such as a paginator. If you are using the standard `GridFieldConfig_RelationEditor` you
will need to remove that component. For example:

```php
// Setup a new relation editor.
$gridConfig = GridFieldConfig_RelationEditor::create();

// Since GridFieldLimitItems is not yet compatible with GridFieldPaginator, remove that now.
$gridConfig->removeComponentsByType("GridFieldPaginator");
$gridConfig->removeComponentsByType("GridFieldPageCount");

// Now we can add our GridFieldLimitItems component.
$limiter = new GridFieldLimitItems(10); // Limit to max of 10.
$gridConfig->addComponent($limiter);

// ... continue below with adding your new GridField instance with this $gridConfig...
```

## Known Issues

- This could be vulnerable to issues relating to not runing in the proper order, in case you are sorting fields and the
  newly sorted field is not yet properly intialized (e.g. starts out at 0 but should be set to 11 prior to modification).
  In this scenario, you should be sure that your sorting component is added to the grid configuration PRIOR to this
  component so that the sort can process first and then the pruning performed by this component can be done. This should
  only be an issue if you are not using the built-in `GridFieldConfig_RelationEditor` which already ensures that it will
  process the relation last.

## To Do

 - Setup ability to customize notes.
 - Setup the ability to modify the returned list without actually affecting relations (i.e. read only, no writing at all to the database).
 - Unit tests to cover current functionality.