text:
ofxOscScheduler
=========
An OSC scheduler addon for openFrameworks.

ofxOscScheduler is an addon for openFrameworks that allows you to send OSC messages with delay and send a message multiple times. You can use ofxOscSenderScheduler and ofxOscReceiverScheduler with same grammer as ofxOscSender and ofxOscReceiver.

In addition to being a scheduler, it intends to somehow guarantee delivery of OSC messages by sending them multiple times since UDP which OSC is based on does not guarantee. For sure, the ultimate solution is to use TCP instead of UDP while most of OSC libraries do not support TCP. ofxOscScheduler helps you to avoid unapparent trouble with OSC.

- In this example, you will send "hello" 5 times in 0.5 seconds with 2.0 seconds delay.
```cpp
- void testApp::setup() {
    sender.setup(HOST, PORT);
    sender.setRepeat(5, 0.5);  // sender will send a message 5 times in 0.5 seconds
}

void testApp::sendOSC() {
    ofxOscMessage m;
    m.setAddress("/address");
    m.addStringArg("hello");
    sender.reserveMessageRepeat(m, 2.0);
}
```

Dependency
------------

- ofxOsc

Usage
---------------------------
### 1. Sender

#### Setup

```cpp
#include "ofxOscScheduler.h"

const string HOST = "localhost";
const int PORT = 12345;

class testApp : public ofBaseApp {
public:
    // definitions

    ofxOscSenderScheduler sender;
}
```

```
void testApp::setup() {
    sender.setup(HOST, PORT);
    sender.setRepeat(5, 0.5);  // sender will send a message 5 times in 0.5 seconds
}
```

#### Send

```cpp
void testApp::sendOSC() {
    ofxOscMessage m;
    m.setAddress("/address");
    m.addFloatArg("hello");
    sender.sendMessage(m);  // sends a message once regardless of setRepeat()
}
```

#### With Delay

```cpp
void testApp::sendOSC() {
    ofxOscMessage m;
    m.setAddress("/address");
    m.addStringArg(3.0);
    sender.reserveMessage(m, 2.0);  // sends a message with 2.0 seconds delay
}
```

#### Multiple Times

```cpp
void testApp::sendOSC() {
    ofxOscMessage m;
    m.setAddress("/address");
    m.addStringArg(3.0);
    sender.sendMessageRepeat(m);  // sends a message multiple times
}
```

#### Multiple Times With Delay

```cpp
void testApp::sendOSC() {
    ofxOscMessage m;
    m.setAddress("/address");
    m.addStringArg(3.0);
    sender.reserveMessageRepeat(m, 2.0);  // sends a message multiple times with 2.0 seconds delay
}
```

### 2. Receiver
To deal with multiple messages sent by ofxOscSenderScheduler, this addon offers ofxOscReceiverScheduler, which ignores any redundant messages.

\*\* Obviously it has a big drawback that you can't receive multiple messages that have a same address and values within a short time. When you need fast communication, I recommend you to implement your program with ofxOscReceiver.

```cpp
class testApp : public ofBaseApp {
public:
    // definitions

    ofxOscReceiverScheduler receiver;
}
```

```cpp
void testApp::setup(){
    receiver.setup(PORT);
    receiver.setIgnoreTime(0.5);
}

void testApp::update(){
    while (receiver.hasWaitingMessages()) {
        ofxOscMessage m;
        receiver.getNextMessage(&m);

        if (m.getAddress() == "/address") {
            ofLog() << m.getArgAsString(0);
        }
    }
}
```

repository: Qoblinli/ofxOscScheduler

repo_name: Qoblinli/ofxOscScheduler


text:
# [RFC] Caching of offloaded types

**Authors:**

- @eapolinario

## 1 Executive Summary

We propose a way to override the default behavior of [caching task executions](https://docs.flyte.org/projects/cookbook/en/latest/auto/core/flyte_basics/task_cache.html), enabling cache-by-value semantics for certain categories of objects.

## 2 Motivation

The behavior displayed by the cache, in some cases, does not match the users intuitions. For example, this code makes use of pandas dataframes:

```python
@task
def foo(a: int, b: str) -> pd.DataFrame:
    df = pd.Dataframe(...)
    ...
    return df

@task(cached=True, version="1.0")
def bar(df: pd.Dataframe) -> int:
    ...

@workflow
def wf(a: int, b: str):
    df = foo(a=a, b=b)
    v = bar(df=df)
```

As the system currently stands, calls to `bar` will never be cached. We cannot honor the promise that cache keys will take into the account the value of the dataframes, because of how we represent dataframes in the backend.

This RFC discusses how to extend this model to allow users to override the representation of objects used for caching purposes.

## 3 Proposed Implementation

First we're going to enumerate the problems tackled in this proposal and discuss an implementation for each one. Namely:
  1. how to model cache-by-value semantics for non-Flyte objects?
  2. how to signal to users that a cached tasks contain hashable objects?

### Problem 1: Cache-by-value semantics for non-Flyte objects

For a certain category of objects, for example pandas dataframes, in order to pass data around in a performant way, Flyte writes the actual data to an object in the configured blob store and uses the path to this random object as part of the representation of the object. In other words, from the perspective of the backend, for all intents and purposes we offer cache-by-reference semantics for these objects.

So how to offer a cache-by-value semantics for the case of these offloaded objects? We're going to expose a way for users to override the hash of objects and use that hash as part of the caching computation.

#### Exposing a hash in Literals

We will expose a new field in [Literal](https://github.com/flyteorg/flyteidl/blob/master/protos/flyteidl/core/literals.proto#L68-L79) objects called `hash`, which will be used to represent that literal in cache key calculations.

Each client will then define the mechanics of setting that field when it's appropriate. Specifically for flytekit, we are going to use the extensions to the typing module proposed in https://www.python.org/dev/peps/pep-0593/, more specifically [`typing.Annotated`](https://docs.python.org/3/library/typing.html#typing.Annotated).

The following example illustrates how these annotated return objects are going to look like:

```python
@task
def foo(a: int, b: str) -> Annotated[pd.DataFrame, HashMethod(hash_pandas_dataframe_function) :
    df = pd.Dataframe(...)
    ...
    return df

@task(cached=True, version="1.0")
def bar(df: pd.Dataframe) -> int:
    ...

@workflow
def wf(a: int, b: str):
    df = foo(a=a, b=b)
    # Note that:
    #   1. the return type of `foo` wraps around a pandas datataframe and adds some metadata to it.
    #   2. the task `bar` is marked as cached and since the dataframe returned by `foo` overrides its hash
    #      we will check the cache using the dataframe's hash as opposed to the literal representation.
    v = bar(df=df)
```

It's worth noting that this is a strictly opt-in feature, controlled at the level of Type Transformers. In other words, annotating types for which Type Transformers are not marked as opted in will be a no-op.

In the backend, during the construction of the cache key, prior to calling data catalog, in case the `hash` field is set, we will use it to represent the literal, otherwise we will keep [the current behavior](https://github.com/flyteorg/flyteidl/blob/master/protos/flyteidl/core/literals.proto#L68-L79). A similar reasoning applies to the local executions case.

#### Adding the hash to FlyteIDL

The ``Literal`` will contain a new field of type string:

```protobuf
// A simple value. This supports any level of nesting (e.g. array of array of array of Blobs) as well as simple primitives.
message Literal {
    oneof value {
        // A simple value.
        Scalar scalar = 1;

        // A collection of literals to allow nesting.
        LiteralCollection collection = 2;

        // A map of strings to literals.
        LiteralMap map = 3;
    }

    // Hash to be used during cache key calculation.
    string hash = 4;
}
```

#### Flytekit

The crux of the mechanics in flytekit revolves around how to expose enough flexibility to allow for arbitrary hash functions to be used, while at the same time providing enough information to flytekit. We propose the use of a `HashMethod` metadata object used in annotated return types. The idea being that during the process of converting from a python value to a literal we apply that hash method and set it in the literal.

We'll lean on [`typing.Annotated`](https://docs.python.org/3/library/typing.html#typing.Annotated) to annotate types with `HashMethod` objects.

Since we cannot assume any hashing characteristics of the hash functions (since we are not talking about perfect hashing in the general case), the `HashMethod` will expose a simple interface, composed of a callable of type `Callable[[T], str]`. That said, we will provide plenty of examples to showcase the flexibility of this approach.

#### Cache key calculation

As mentioned above, during the regular cache key calculation, flyte takes the input literal map as part of the key to generate a tag, which is then associated with the artifact (i.e. the task output). Going forward we will associate multiple tags, with and without the hashes, so that lookups still work transparently for both references and hash-annotated values.

#### Other clients

Although nothing prevents the adoption of this feature in other clients, flytekit-java and other clients are outside of the scope of this RFC.

### Problem 2: Bubbling up caching information

A natural question to ask is in what ways we can help users in the process of authoring and visualizing workflows that use these hash-annotated objects?

First of all, we're going to augment the [`LiteralType` metadata](https://github.com/flyteorg/flyteidl/blob/master/protos/flyteidl/core/types.proto#L91) with a `hashable` field. Setting this field will indicate that for that type we expect the hash to be overridden in case that type is used as an input in a cacheable task.

#### At registration time

During the registration phase we will be able to detect cases where cached tasks[^1] inputs do not set the `hashable` field, even though they should in most cases. For example, by doing this we're able to catch the following case:

[^1]: For the purposes of this discussion, every time we mention cached tasks in this section we are assuming that we're talking about tasks where the cache bit is set to True and that at least one of the input types is hashable.

```python
@task
def foo(a: int, b: str) -> pd.DataFrame:
    df = pd.Dataframe(...)
    ...
    return df

@task(cached=True, version="1.0")
def bar(df: pd.Dataframe) -> int:
    ...

@workflow
def wf(a: int, b: str):
    df = foo(a=a, b=b)
    # At registration time we will be able to signal to the user that calls to the task `bar` will never be cached, since that even though the hashable bit is set,
    # the upstream task is not returning a hash-annotated object.
    v = bar(df=df)
    ...
```

Whenever we detect such cases, we'll raise a warning at registration time, telling the user that it's very likely that they forgot to annotate the return type of `foo`. It's worth noting that we are able to tach this case, but in the general case, users will have to decide if such warnings are valid.

#### During cache hits

We're going to augment the [metadata](https://github.com/flyteorg/flyteidl/blob/989fe6e4f51eed3a5a68b8f563244bd38b765f4c/protos/flyteidl/admin/node_execution.proto#L175) returned by flytepropeller to indicate that the hash was used. We'll investigate ways to display this information in flyteconsole in the case of cached tasks.

## 4 Metrics & Dashboards

N/A?

## 5 Drawbacks

Although this feature does *not* impact the other aspects of how the cache works, for example,  changes to the version or the signature of the task invalidate the cache entries, it still might cause confusion since from the perspective of a task execution we will not be able to tell if an object will have its hash overridden.

## 6 Alternatives

A few options were discussed in https://github.com/flyteorg/flyte/issues/1581:

**Expose a `hash` method in Type Transformers and annotate the task in case the type transformer does not contain a hash function:** The major drawbacks of this alternative are two-fold:
    (1) There's no way to opt-out, i.e. all objects produced by that Type Transformer will be cached.
    (2) The UX is a bit clunky in the case of user-defined hash functions for two reasons:
        - the return type does not contain any indication that the object is being cached, i.e. we'd have to look in the parameters set in the @task decorator

**Offload the hash calculation to an external system like s3:** The idea would be to rely on etags produced by the act of storing an object in s3. This turns out to be a chicken-and-egg problem as we need to produce etags in order to compare if that tag was already produced. Also, even if we were able to overcome that hurdle, handing this computation to a blackbox system like s3 risks making cache entries unrecoverable, since there is no guarantee that the algorithm s3 uses to compute etags will not change.

**Define the new hash field in the Scalar instead of the Literal**: One could argue that the hash could be "tucked away" in the [Scalar](https://github.com/flyteorg/flyteidl/blob/master/protos/flyteidl/core/literals.proto#L55-L65) instead. At this time I couldn't find a great argument for going that route, although most of the reasoning around the use of the hash during cache key calculation still applies (adjusting the access to the hash field).

## 7 Potential Impact and Dependencies

It might be useful to cap the size of hashes produced by client code so as to limit the size of the cache keys. Performing this capping should be done in an uniform manner, which implies that it should happen in the backend.

## 8 Unresolved questions

How does this affect @dynamic tasks, subworkflows, and launchplans?

What's the observability provided by data catalog?

## 9 Conclusion

Users have been requesting a cache-by-value semantics for non-Flyte objects for a long time and the proposal described in this document achieves that goal while not imposing a huge cost to components of the Flyte system.

## 10 RFC Process Guide, remove this section when done

*By writing an RFC, you're giving insight to your team on the direction you're taking. There may not be a right or better decision in many cases, but we will likely learn from it. By authoring, you're making a decision on where you want us to go and are looking for feedback on this direction from your team members, but ultimately the decision is yours.*

This document is a:

- thinking exercise, prototype with words.
- historical record, its value may decrease over time.
- way to broadcast information.
- mechanism to build trust.
- tool to empower.
- communication channel.

This document is not:

- a request for permission.
- the most up to date representation of any process or system

**Checklist:**

- [x]  Copy template
- [x]  Draft RFC (think of it as a wireframe)
- [ ]  Share as WIP with folks you trust to gut-check
- [ ]  Send pull request when comfortable
- [ ]  Label accordingly
- [ ]  Assign reviewers
- [ ]  Merge PR

**Recommendations**

- Tag RFC title with [WIP] if you're still ironing out details.
- Tag RFC title with [Newbie] if you're trying out something experimental or you're not entirely convinced of what you're proposing.
- Tag RFC title with [RR] if you'd like to schedule a review request to discuss the RFC.
- If there are areas that you're not convinced on, tag people who you consider may know about this and ask for their input.
- If you have doubts, ask on [#feature-discussions](https://slack.com/app_redirect?channel=CPQ3ZFQ84&team=TN89P6GGK) for help moving something forward.

repository: flyteorg/flyte

branch_name: refs/heads/master

extension: md

gha_language: Go

license_type: permissive

repo_name: flyteorg/flyte


text:
# GherkinExample

### NuGet installation order:
-SpecFlow
-SpecFlow.Tools.MsBuild.Generation
-SpecRun.SpecFlow
-NUnit

Additionaly you have to install "SpecFlow for Visual Studio" extention in Visual Studio

license: MIT

repository: haevg-rz/LearnToCode

gha_license_id: MIT

repo_name: haevg-rz/LearnToCode


text:
---
layout: post
title: "NullaNet: Training Deep Neural Networks for Reduced-Memory-Access Inference"
date: 2018-08-27 05:22:38
categories: arXiv_CV
tags: arXiv_CV Speech_Recognition Inference Recognition
author: Mahdi Nazemi, Ghasem Pasandi, Massoud Pedram
mathjax: true
---

* content
{:toc}

##### Abstract
Deep neural networks have been successfully deployed in a wide variety of applications including computer vision and speech recognition. However, computational and storage complexity of these models has forced the majority of computations to be performed on high-end computing platforms or on the cloud. To cope with computational and storage complexity of these models, this paper presents a training method that enables a radically different approach for realization of deep neural networks through Boolean logic minimization. The aforementioned realization completely removes the energy-hungry step of accessing memory for obtaining model parameters, consumes about two orders of magnitude fewer computing resources compared to realizations that use floatingpoint operations, and has a substantially lower latency.

##### Abstract (translated by Google)

##### URL
[https://arxiv.org/abs/1807.08716](https://arxiv.org/abs/1807.08716)

##### PDF
[https://arxiv.org/pdf/1807.08716](https://arxiv.org/pdf/1807.08716)


text:
---
title: "Kaxil Naik"
oneliner: "Senior Data Engineer @ Astronomer | Airflow PMC member & core committer"
twitter: "https://twitter.com/"
photo: "kaxil.jpg"
weight: 3
type: "keynote"
publish: true

---

Kaxil is currently working as a Senior Data Engineer @ Astronomer. He did his Masters in Data Science & Analytics from Royal Holloway, University of London.Started as a Data Scientist and then gained experience in Data Engineering and DevOps space. He began working on Airflow in 2017 while working at Data Reply as a BigData consultant and became PMC member in 2018 and now works full-time at astronomer.io making Airflow better for everyone. He is a huge cricket fan and his favorite cricketers are Rahul Dravid and Virat Kohli.

repository: kaxil/airflowsummit-website

repo_name: kaxil/airflowsummit-website


text:
# Example

You will find the UI for this example at [lab259/graphqlws-chat-client](https://github.com/graphql-go/graphqlws-chat-client).

Before running the example you should:

```
docker-compose up -d
```

Now, fallback to the main source directory, the one that has the `Makefile` in it.
You will install all the dependencies by:

```
make dep-ensure
```

Finally, you should be able to run this example:

```
make example-simple-chat-server-redis
```

repository: jamillosantos/go-graphqlws

repo_name: jamillosantos/go-graphqlws


text:
python-tmdb3
============

[![Build Status](https://travis-ci.org/Wessie/python-tmdb3.png?branch=master)](https://travis-ci.org/Wessie/python-tmdb3)
[![Coverage Status](https://coveralls.io/repos/Wessie/python-tmdb3/badge.png?branch=master)](https://coveralls.io/r/Wessie/python-tmdb3?branch=master)

Light Python API around TheMovieDB API version 3, which the documentation off is [here](http://docs.themoviedb.apiary.io/)

The following Python versions are supported: `Python 2.6`, `Python 2.7`, `Python 3.3+`, `PyPy`

Installation
============

Currently, `python-tmdb3` is not on `pip`. To install you can use the following `pip` command for now:

`pip install -e git+https://github.com/Wessie/python-tmdb3.git#egg=tmdb`

Examples
========

Create an API instance:
```python
>>> import tmdb
>>> api = tmdb.API(your_api_key)
```

Receive information by movie ID
```python
>>> api.movie(550)
```

Search for movies:
```python
>>> api.search_movie(query="Rocky")
```

And many more (a total of 86 methods), for all available methods see (for now as documentation isn't setup yet) `dir(tmdb.API)`.

Issues
======

Most of the code is auto-generated, and most likely not perfect. Please file an issue if you run into
a problem using `python-tmdb3`.


text:
# Knife-Plugin Zero

[![Gitter](https://badges.gitter.im/Join Chat.svg)](https://gitter.im/higanworks/knife-zero?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)

[![Gem Version](https://badge.fury.io/rb/knife-zero.svg)](http://badge.fury.io/rb/knife-zero)
[![Stories in Ready](https://badge.waffle.io/higanworks/knife-zero.svg?label=ready&title=Ready)](http://waffle.io/higanworks/knife-zero)
[![Stories in Progress](https://badge.waffle.io/higanworks/knife-zero.svg?label=In%20Progress&title=In%20Progress)](http://waffle.io/higanworks/knife-zero)

Run chef-client at remote node with chef-zero(local-mode) via HTTP over SSH port fowarding.

- It doesn't have to transport cookbooks via scp,rsync or something.
- It can collect node object into local chef-repo.
- It supports all functioanly of chef(C/S).
- You have only to manage one chef-repo.

## Requirements

- Must support AllowTcpForward

## Installation

Add this line to your application's Gemfile:

    gem 'knife-zero'

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install knife-zero

### With Chef-DK

Install via `chef gem` subcommand.

```
$ chef gem install knife-zero
```

## Usage

```
** ZERO COMMANDS **
knife zero bootstrap FQDN (options)
knife zero chef_client QUERY (options)
```

### knife zero bootstrap

Install Chef to remote node and run chef-client under chef-zero via tcp-forward.

Supported options are mostly the same as `knife bootstrap`.
And it supports why-run(`-W, --why-run`).

#### Example

Bootstrap with run-list.

```
$ bundle exec knife zero bootstrap host.example.com -r hogehoge::default --no-host-key-verify
Connecting to host.example.com
host.example.com Installing Chef Client...
-- snip --
host.example.com Thank you for installing Chef!

host.example.com Starting first Chef Client run...
host.example.com Starting Chef Client, version 11.14.6
host.example.com Creating a new client identity for host.example.com using the validator key.

## Resolv and sync cookbook via http over ssh tcp-forward by run-list.
host.example.com resolving cookbooks for run list: ["hogehoge::default"]
host.example.com Synchronizing Cookbooks:
host.example.com   - hogehoge
host.example.com Compiling Cookbooks...
host.example.com Converging 0 resources
host.example.com
host.example.com Running handlers:
host.example.com Running handlers complete
host.example.com Chef Client finished, 0/0 resources updated in 4.895561879 seconds

## Creates node object into local.
 $ ls nodes/host.example.com.json
nodes/host.example.com.json
host.example.com

## Search by knife with --local--mode option.
$ bundle exec knife search node --local-mode
1 items found

Node Name:   host.example.com
Environment: _default
FQDN:
IP:          xxx.xxx.xxx.xxx
Run List:    recipe[hogehoge::default]
Roles:
Recipes:     hogehoge::default
Platform:    ubuntu 12.04
Tags:
```

Search and update node by `knife exec`(I will implement them into plugin.).

```
$ knife exec --local-mode -E 'nodes.all {|n| system "ssh -R8889:<IP_ADDRESS>:8889 #{n.ipaddress} chef-client -S http://<IP_ADDRESS>:8889" }'
```

Seach and execute command via ssh by knife ssh.

```
$ knife ssh 'hostname:*' --local-mode uptime --attribute ipaddress
xxx.xxx.xxx.xxx  08:41:36 up  1:03,  1 user,  load average: 0.00, 0.01, 0.01
xxx.xxx.xxx.xxx  08:41:37 up 143 days,  2:32,  4 users,  load average: 0.00, 0.01, 0.05
```

### knife zero chef_client (for update)

`knife zero chef_client QUERY (options)`

Search nodes from local chef-repo directory, and run command at remote node.

Supported options are mostly the same as `knife ssh`.
And it supports below.

- why-run(`-W, --why-run`)
- Override run-list(`-o RunlistItem,RunlistItem, --override-runlist`). It skips save node.json on workstation.

#### Example

```
## Chef-Repo has two nodes
$ knife node list --local-mode
host.example.com
host2.example.com

## add recipe to run_list of host.example.com
$ knife node run_list add host.example.com hogehoge::default --local-mode
host.example.com:
  run_list: recipe[hogehoge::default]

$ knife zero chef_client 'name:*' --attribute ipaddress

## host.example.com was converged by run_list.
host.example.com Starting Chef Client, version 11.14.6
host.example.com resolving cookbooks for run list: ["hogehoge::default"]
host.example.com Synchronizing Cookbooks:
host.example.com   - hogehoge
host.example.com Compiling Cookbooks...
host.example.com Converging 0 resources
host.example.com
host.example.com Running handlers:
host.example.com Running handlers complete
host.example.com Chef Client finished, 0/0 resources updated in 3.112708185 seconds

## host2.example.com has no run_list.
host2.example.com Starting Chef Client, version 11.14.2
host2.example.com resolving cookbooks for run list: []
host2.example.com Synchronizing Cookbooks:
host2.example.com Compiling Cookbooks...
host2.example.com [2014-08-24T11:52:15+00:00] WARN: Node ngrok01.xenzai.net has an empty run list.
host2.example.com Converging 0 resources
host2.example.com
host2.example.com Running handlers:
host2.example.com Running handlers complete
host2.example.com Chef Client finished, 0/0 resources updated in 3.729471856 seconds
```

## Sample Workflow

1. create chef-repo directory.
1. bundle init and add below.
    - `gem 'chef'  `
    - `gem 'knife-zero'`
    - and cookbook management tool such as `Beakshelf` or `Librarian-Chef`.
1. bundle
e.g.) `bundle install --path vendor/bundle --binstubs`
1.  install cookbooks to `./cookbooks`. (if you need run recipe.)
1. bootstrap on remote node.
`./bin/knife zero bootstrap host.example.com [-r "${your-run-list}"]`
1. chef-client will run using resources on local chef-repo.

### Need test on Vagrant ?

You can test cookbooks easily by Test-Kitchen before manage remote nodes instead of using knife-zero for vagrant VM.

See [Getting Started knife-zero with test-kitchen](https://github.com/higanworks/knife-zero-with-kitchen).

## Contributing

1. Fork it ( https://github.com/[my-github-username]/knife-zero/fork )
2. Create your feature branch (`git checkout -b my-new-feature`)
3. Commit your changes (`git commit -am 'Add some feature'`)
4. Push to the branch (`git push origin my-new-feature`)
5. Create a new Pull Request

## License

Licensed under the Apache License, Version 2.0.


text:
Alfred Extensions by Roger Braunstein @partlyhuman
==================================================

See the [Project Page](http://partlyhuman.github.com/alfred-extensions/)

My name's Roger. I use [Alfred](http://www.alfredapp.com/) (too). I put together some simple extensions to help me work. I thought I'd share them here. They require the [Powerpack](http://www.alfredapp.com/powerpack/). Enjoy!

## Quick Quote & Speak Quote
Gets a stock quote... Quick! ... Quickly! Uses Yahoo Finance feeds and a few lines of Ruby. In "Quick Quote," the ticker pops up in Notification Center. (When available, this will be updated to output in large text instead of Notification Center.) In "Speak Quote," the stock price and its movements are read out using your default voice. Cool.

Aside: I also like to set up a custom search for http://www.google.com/finance?q={query}, but this is far less obtrusive.

Usage: `qq aapl`  `sq aapl`

## ChronoMate Controls
ChronoMate is an app for tracking your time in FreshBooks. It's a great combo for freelancers. I highly recommend both if you haven't given them a shot.
With this extension you can do very basic timer control. It uses whatever project is already active. I also recommend Pomodoro Controls in conjunction with this.

Note: since ChronoMate is not scriptable, it's required that you have the Dock icon for ChronoMate enabled. This turns on some menu bars that I can get to with System Events.

Usage: `cm start` `cm stop` `cm log`

## Todo
All the Reminders scripts out there required me to type too much — or didn't work.   (Also it doesn't open the Reminders app. That's nice too.)

Usage: `todo take out trash`

## New Safari Window
This quickie AppleScript opens a new window of Safari, no matter what Space you're in, without switching Spaces. Like clicking "New Window" on the Dock icon but less sucky. Bind it to a hotkey. That is all.

----------------

This stuff requires Alfred, a free OS X app, and the Powerpack, a not so free addon. Safari icon, Reminders icon, and the programs they reference are
property of and copyright Apple Inc. ChronoMate software and icon are property of and copyright Studio Quadbyte.

repository: partlyhuman/alfred-extensions

repo_name: partlyhuman/alfred-extensions


text:
# Dimensions 📐

Nothing special just two helper functions that use [Dimensions](https://reactnative.dev/docs/dimensions) API

- `getWindowDimensions`
- `getScreenDimensions`

These functions return an object with the next properties:

```ts
width: number;
height: number;
scale: number;
fontScale: number;
```

**Example:**

```ts
import { makeUseStyles } from "react-native-stylex";
import { getWindowDimensions } from "react-native-stylex/dimensions";

export const useStyles = makeUseStyles(() => ({
  video: {
    width: getWindowDimensions().width,
    height: getWindowDimensions().width,
  },
}));
```

repository: retyui/react-native-stylex

gha_language: TypeScript

repo_name: retyui/react-native-stylex


text:
# Reaktor Algolia Plugin for Reaction Commerce

Welcome to the Reaktor Algolia Plugin for Reaction Commerce. This is a plugin which can be used on the reaction commerce platform to publish your catalog to Algolia.

### What is Reaction Commerce?
Reaction Commerce is a modern, open source platform for today's premier ecommerce experiences. It is a lightweight, real-time reactive commerce solution that redefines, simplifies, and aligns both the experiences of the user and the vendor.

https://www.reactioncommerce.com/

### What is Algolia?
A powerful hosted search API that provides product teams with the resources & tools they need to create fast, relevant search.

https://www.algolia.com/

### How does it work?
It's very simple, when an administrator in Reaction Commerce publishes a product to the catalog, this plugin listens to that event and updates a document in Algolia. That document is then indexed and can be queried by the storefront for fast relevant search.

The plugin provides an admin panel available to the administrator to configure the API keys and index information.

To help the storefront application, the Algolia settings are exposed by a GraphQL query so the application can access the search only api key from Algolia.

## Installation

Assumption is that you already have reaction commerce cloned on your machine.

1. Clone this repo into `/imports/plugins/custom`
1. And you're done! Just start or restart your application and that's it.

## Configuration

Assumption is that you already have an Algolia account.

1. Login to your admin area of reaction
1. Click on `Algolia Search`
1. Then provide the following details
    1. Algolia App Id
    1. Algolia Admin API Key
    1. Algolia Search Only API Key
    1. Algolia Products Index Name
1. Then click save
1. Finally, add or edit a product in the products catalog and then after a few seconds see the document indexed in Algolia

repository: reaktor/reactioncommerce-algolia

gha_language: JavaScript

repo_name: reaktor/reactioncommerce-algolia


text:
# READVL

<PageHeader />

## Description

The **READVL** statement acquires a shared record lock and then reads a field from the record.

The **READVL** statement conforms to all the specifications of the [READL](./../readl) and [READV](./../readv) statements

Go back to [jBASE BASIC](./../README.md)

Go back to [Programmers' Reference Guide](./../../reference-guides/jbc/README.md)

<PageFooter />

repository: josepheshaw/docs

repo_name: josepheshaw/docs


text:
## intent: greet
- Hi
- hey
- heya
- Hello
- What's up
- Heya
- Greetings
- Good  morning
- Good afternoon
- Good evening
- Hey sir
- Hi person
- Hey robot
- Hello bot

## intent: thanks
- thanks
- thank you
- Thanks a lot
- Thanks a bunch
- Thank you very much
- Thank you so much

## intent: goodbye
- Talk to you later!
- Bye for now
- Awesome, bye bye
- Goodbye.
- Talk to you later
- Goodbye
- Talk to you later
- Bye for now
- Goodbye

## intent: place_search
- I am looking for a [restaurant](query).
- Where is the closest [cinema](query)?
- Looking for a [supermarket](query) within 50 meters from me.
- Can you tell me where is the [restaurant](query) in 100 meters from where I am?
- Is there a [market](query) within 500 meters?
- Where is the closest [shop](query)?
- Where can I find the [mall](query)?
- I am looking for a [hair salon](query) within 20 meters from here.
- Please tell me is there a [museum](query) around?
- I am wondering if I can find a [train station](query) within 250 meters from here?
- I am looking for a [club](query) nearby.
- Is there a [bank](query) anywhere close?
- I am looking for a [bank](query) withing 25 meters from here.
- Looking for a [cinema](query).
- There is any opening in [centurysoft](query).

## intent: opening_hours
- Is it still open?
- Is it open at the moment?
- Is it working?
- Is it open today?

- Can you tell me if it's open at the moment?
- Tell me if it's open.
- Is the place open today?
- Is the place still open today?

## intent: address
- Where is it?
- What's the address?
- Can you tell me the address?
- Where is the place?
- What is the location of it?
- Where about is it?
- Can you please tell me the actual address?
- Does it take long to get there?
- Does it take a long time to get to the place?
- I am wondering how long does it take to get to the location?
- What is the address of this place?
- Where is this place?
- What is an actual address?

## intent: rating
- What is the rating of this place?
- Does it have a good rating?
- Tell me the rating
- Do you know the rating of this place?
- What rating does it have?
- I want to know the rating

## itent: inform
- 10 meters
- 100 meters
- 1500
- around 100
- let's say 50 meters
- within 15 meters
- within 25 meters from here

repository: AnilLG/Assistant

gha_language: Python

repo_name: AnilLG/Assistant


text:
# Logstash Sumo Logic Output Plugin

This is a plugin for [Logstash](https://github.com/elastic/logstash).
It is fully free and fully open source. The license is Apache 2.0, meaning you are pretty much free to use it however you want in whatever way.

## Getting Started

### 1. Create a Sumo Logic HTTP source
Create a [Sumo Logic](https://www.sumologic.com/) free account if you currently don't have one.

Create a [HTTP source](http://help.sumologic.com/Send_Data/Sources/HTTP_Source) in your account and get the URL for this source. It should be something like:
```
https://events.sumologic.net/receiver/v1/http/XXXXXXXXXX
```

### 2. Install LogStash on your machine
Following this [instruction](https://www.elastic.co/guide/en/logstash/current/getting-started-with-logstash.html) to download and install LogStash. This plugin requires Logstash 2.3 or higher to work.

### 3. Build your plugin gem
In your local Git clone, running:
```sh
gem build logstash-output-sumologic.gemspec
```
You will get a .gem file as `logstash-output-sumologic-1.0.0.gem`

### 4. Install plugin into LogStash
In the Logstash home, running:
```sh
bin/logstash-plugin install <path of .gem>
```

### 5. Start Logstash and send log
In the Logstash home, running:
```sh
bin/logstash -e 'input{stdin{}}output{sumologic{url=>"<url from step 1>"}}'
```
This will send any input from console to Sumo Logic cloud service.

### 6. Get result from Sumo Logic web app
Logon to Sumo Logic [web app](https://prod-www.sumologic.net/ui/) and run [Search](http://help.sumologic.com/Search) or [Live Tail](http://help.sumologic.com/Search/Live_Tail)

### Furthermore
- Try it with different input/filter/codec plugins
- Start LogStash as a service/daemon in your production environment
- Report any issue or idea through [Git Hub](https://github.com/SumoLogic/logstash-output-sumologic)

## Parameters
This plugin is based on [logstash-mixin-http_client](https://github.com/logstash-plugins/logstash-mixin-http_client) thus it supports all parameters like proxy, authentication, retry, etc.

And it supports following additional prarmeters:
```
  # The URL to send logs to. This should be given when creating a HTTP Source
  # on Sumo Logic web app. See http://help.sumologic.com/Send_Data/Sources/HTTP_Source
  config :url, :validate => :string, :required => true

  # Include extra HTTP headers on request if needed
  config :extra_headers, :validate => :hash, :default => []

  # The formatter of message, by default is message with timestamp and host as prefix
  config :format, :validate => :string, :default => "%{@timestamp} %{host} %{message}"

  # Hold messages for at least (x) seconds as a pile; 0 means sending every events immediately
  config :interval, :validate => :number, :default => 0

  # Compress the payload
  config :compress, :validate => :boolean, :default => false

```

repository: danbarratt/logstash-output-sumologic

repo_name: danbarratt/logstash-output-sumologic


text:
---
layout: default
---

# 1994-09-24 - Re: kerberosV telnet

## Header Data

From: "Perry E. Metzger"<EMAIL_ADDRESS>To: Jef Poskanzer<EMAIL_ADDRESS>Message Hash: 344a58ad2644a122b40cd5fc1d11906429739853f99d16b786c69ed2cbfa50cf

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1994-09-24 18:49:31 UTC

Raw Date: Sat, 24 Sep 94 11:49:31 PDT

## Raw message

```
{% raw  %}From: "Perry E. Metzger"<EMAIL_ADDRESS>Date: Sat, 24 Sep 94 11:49:31 PDT
To: Jef Poskanzer<EMAIL_ADDRESS>Subject: Re: kerberosV telnet
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

Jef Poskanzer says:
> "That turns out not to be the case."  The version of CNS that we have
> doesn't have any encryption beyond DES.  4.4BSD telnet is basically
> identical to kerberosV telnet, and the only encryption it has is DES.

The 4.4 telnet is NOT identical. Its much better code, has lots of
neat new capabilities that you probably want, is more modular, and the
versions I saw had hooks for D-H and the like, which is where most of
the work is -- you can get the D-H code from RSAREF and steal the IDEA
code from PGP; from there the changes are small. And yes, I assumed
that you didn't have an encrypted telnet at all.

Perry

{% endraw %}
```

## Thread

+ Return to [September 1994](/archive/1994/09)

+ Return to "[Jef Poskanzer <jef@ee.lbl.gov>](/authors/jef_poskanzer_jef_at_ee_lbl_gov_)"
+ Return to "["Perry E. Metzger" <perry@imsi.com>](/authors/perry_e_metzger_perry_at_imsi_com_)"

+ 1994-09-24 (Fri, 23 Sep 94 17:49:29 PDT) - [Re: kerberosV telnet](/archive/1994/09/2f37cf5a56c22135f68065c4270998ac410f9b55d9532886bf6dadeb93c27fe8) - _Jef Poskanzer<EMAIL_ADDRESS>  + 1994-09-24 (Sat, 24 Sep 94 11:49:31 PDT) - Re: kerberosV telnet - _"Perry E. Metzger"<EMAIL_ADDRESS>


text:
### Observation :

* Check for host property in /etc/cinder/cinder.conf

![alt text](https://github.com/CloudByteStorages/openstack/blob/master/FAQs/images/image4.jpg)

* Check the host column in volumes table in cinder database

![alt text](https://github.com/CloudByteStorages/openstack/blob/master/FAQs/images/image5.jpg)

### Solution :

Above screenshot typically imply, host property was set to FQDN of the cinder node. This has got issues in the current HA implementation in cinder.

Uncomment the "host=cinder" in "/etc/cinder/cinder.conf".

Update the volumes records host column to cinder irrespective of the host in which the volume was created.

repository: yogeshprasad/openstack

repo_name: yogeshprasad/openstack


text:
# Add Page Content Efficiently

**Using A Loop To Add Content**

In the last lesson, we used a `for loop` to create two hundred paragraphs, add event listeners to them, and add them to the page. Let's take another look at the `for loop`, but this time without all of the event listener stuff:

```js
for (let i = 1; i <= 200; i++) {
    const newElement = document.createElement('p');
    newElement.textContent = 'This is paragraph number ' + i;

    document.body.appendChild(newElement);
}
```

Let's quickly recap the code to see where we can make improvements.

This code:

- creates a paragraph element
- adds some text to the paragraph
- adds the paragraph to the page

...and it does this two hundred times.

Since we want two hundred things done, the best way to do this is with a `for loop`, so that code is inescapable. However, the code *inside* the `for loop` is not all that efficient, and there are quite a few things we could do to improve this code. We could:

- create some parent container element *outside* of the loop
- we could append all new paragraph elements to this parent container
- we append this parent container to the `<body>` element instead of appending each time through the loop

Let's see all of these changes:

```js
const myCustomDiv = document.createElement('div');

for (let i = 1; i <= 200; i++) {
  const newElement = document.createElement('p');
  newElement.innerText = 'This is paragraph number ' + i;

  myCustomDiv.appendChild(newElement);
}

document.body.appendChild(myCustomDiv);
```

This looks a lot better, right? Right!...but how do we *know* it is? How can we *prove* it's better?

We can test the time it takes to actually run this code!

**Testing Code Performance**

The standard way to measure how long it takes code to run is by using `performance.now()`. `performance.now()` returns a timestamp that is measured in milliseconds, so it's extremely accurate. How accurate? Here's what the its documentation page says:

> a*ccurate to five thousandths of a millisecond (5 microseconds)*

That's incredibly precise!

If you've ever used a timing procedure in another programming language, then you might've heard of Epoch time (also called Unix time or POSIX time). These tools tell you the time that has passed since 1/1/1970 (the first of January). The browser's `performance.now()` method is slightly different in that it starts measuring from the time the page loaded. Detailed information can be found on its documentation page: [performance.now() on MDN](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now)

These are the steps to use `performance.now()` to measure the speed of your code:

1. use `performance.now()` to get the an initial start time for the code
2. run the code you want to test
3. execute `performance.now()` to get another time measurement
4. subtract the initial time from the final time

Adding two hundred paragraphs to the page is actually going to be relatively quick, so let's slow things down by using a set of nested `for` loops that just count from one to a hundred...one hundred times!

```js
for (let i = 1; i <= 100; i++) {
  for (let j = 1; j <= 100; j++) {
    console.log('i and j are ', i, j);
  }
}
```

Next, we'll add in the `performance.now()` code to measure how long these loops take:

```js
const startingTime = performance.now();

for (let i = 1; i <= 100; i++) {
  for (let j = 1; j <= 100; j++) {
    console.log('i and j are ', i, j);
  }
}

const endingTime = performance.now();
console.log('This code took ' + (endingTime - startingTime) + ' milliseconds.');
```

![performance-now](./performance-now.png)

Let's go back to our original code of adding two hundred paragraphs to the page to see how long that code takes to run. Actually, the code from the left side runs a little bit faster, so it's more efficient.

![code-performance](./code-performance.png)

**Using a Document Fragment**

So far, we've made a number of improvements to the code. However, there is still one thing that seems not so great; we have to create a extraneous `<div>` element *just to hold all the `<p>` tags so we can add them all at once* and then we append this `<div>` to the `<body>` element. So in the end, we have an extra `<div>` that isn't really needed. It was just around because we wanted to add each new `<p>` to it instead of to the `<body>`.

Why are we doing this? The browser is constantly working to *make the screen match the DOM*. When we add a new element, the browser has to run through a `reflow` calculation (to determine the new screen layout) and then `repaint` the screen. This takes time.

If we had added each new paragraph to the body element, then the code would've been a lot slower, because this would cause the browser to go through the `reflow` and `repaint` process *for each paragraph*. We really only want the browser to do this once, so we need to attach each new paragraph to something, but we don't want to have an extra, unneeded element to get added to the DOM.

This is exactly why we have the **DocumentFragment**! According to the documentation, a **DocumentFragment**:

> *represents a minimal document object that has no parent. It is used as a lightweight version of Document that stores a segment of a document structure comprised of nodes just like a standard document.*

So it's like creating another lightweight DOM tree. But the beneficial part of this is what it says next:

> *The key difference is that because the document fragment isn't part of the active document tree structure, changes made to the fragment don't affect the document, cause reflow, or incur any performance impact that can occur when changes are made.*

In other words, changes made to a DocumentFragment happen off-screen; there's no reflow and repaint cost while you build this. So this is exactly what we need!

We can use the `.createDocumentFragment()` method to create an empty `DocumentFragment` object. This code should be very familiar to you, because it looks so very similar to `document.createElement()`.

```js
const myDocFrag = document.createDocumentFragment();
```

Let's rewrite our code to use a DocumentFragment instead of the `<div>`.

```js
const fragment = document.createDocumentFragment();  // ← uses a DocumentFragment instead of a <div>

for (let i = 0; i < 200; i++) {
    const newElement = document.createElement('p');
    newElement.innerText = 'This is paragraph number ' + i;

    fragment.appendChild(newElement);
}

document.body.appendChild(fragment); // reflow and repaint here -- once!
```

**Recap**

In this section, we took a brief dive into the performance implications of the code we write. We looked at a specific chunk of code and came up with ways that we could improve its performance simply by rearranging when the code was running (moving initialization code out of the `for loop`).

We also looked at how to measure how long it takes code to run using `performance.now()`.

Lastly, we looked at using a `DocumentFragment` to prevent performance issues and to prevent adding unnecessary elements to the DOM.

**Further Research**

- [performance.now() on MDN](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now)
- [Performance Interface on MDN](https://developer.mozilla.org/en-US/docs/Web/API/Performance)
- [DocumentFragment Interface on MDN](https://developer.mozilla.org/en-US/docs/Web/API/DocumentFragment)
- [createDocumentFragment docs on MDN](https://developer.mozilla.org/en-US/docs/Web/API/Document/createDocumentFragment)

# Reflow & Repaint

We mentioned `Reflow` and `Repaint` in the last section, now it's time to take a closer look.

**Reflow** is the process of the browser laying out the page. It happens when you first display the DOM (generally after the DOM and CSS have been loaded), and happens again every time something could change the layout. This is a fairly expensive (slow) process.

**Repaint** happens after reflow as the browser draws the new layout to the screen. This is fairly quick, but you still want to limit how often it happens.

Why did adding a little CSS change cause a `reflow`? What if adding a class changed the position of the element or caused it to float? The br`owser won't know for certain (and a complete calculation of the impact of a change could take longer than doing the reflow!)

Let's take a realistic example. Say you're writing the next great blogging platform, and you want to have a "remove spam" button for the administrator. Your HTML looks like this:

```html
<div id="comments">
  <div class="comment"> <!-- some content --> </div>
  <div class="comment"> <!-- some content --> </div>
  <div class="comment"> <!-- some content --> </div>
</div>
```

When we run the spam filter, we discover comments one and two have to be removed.

If we simply call `.removeChild()` for each of the two `comments` that need to be removed, that's one reflow and one repaint for each change (so a total of 2 reflows and 2 repaints). We could rebuild the whole thing in a `DocumentFragment` and replace `#comments` -- that's the time to rebuild (possibly involving reading files or data), plus at least one reflow and one repaint.

Or we could *hide* `#comments`, delete the spam, and show it again -- that's surprisingly fast, to the cost of one reflow and two repaints (and little else). It's fast because hiding doesn't change the layout, it just erases that section of the screen (1 repaint). When you make the changed section visible again, that's a reflow and a repaint.

> *In general, if you have to make a group of changes, hide/change all/show is a great pattern to use if the changes are relatively contained.*

**Virtual DOM**

By the way, this is why React and other "virtual DOM" libraries are so popular. You don't make changes to the DOM, but make changes to another structure (a "virtual DOM") and the library calculates the best way to update the screen to match. The catch is you then have to rework your code to use whatever library you're adopting, and sometimes you can do a better job updating the screen yourself (because you understand your own unique situation).

**Recap**

In this section, we took a brief look at what reflow and repaint are and saw how they can impact the performance of a website.

Reflow is the process of calculating the dimensions and position of page elements. This is a computationally intensive (slow) tasks. Repaint is the process of drawing the pixels to the screen. This is faster than reflow, but is still not a fast process. You want to make sure that your code causes the fewest number of reflows as possible.

**Further Research**

- [Website Performance Optimization](https://www.udacity.com/course/website-performance-optimization--ud884) free course by Udaicty
- [Minimizing browser reflow](https://developers.google.com/speed/docs/insights/browser-reflow) from PageSpeed Tools Guides
- [Avoid Large, Complex Layouts and Layout Thrashing](https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing) from Google's Web Fundamentals Guides
- [Performance Analysis Reference](https://developers.google.com/web/tools/chrome-devtools/evaluate-performance/reference#rendering) from Google's Web Fundamentals Guides
- Article [Reflows & Repaints: CSS Performance Making Your JavaScript Slow?](http://www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performance-making-your-javascript-slow/)

# The Call Stack

**Single Threading**

You might've heard that JavaScript is **single-threaded** but what does that mean? According to Wikipedia, single-threading is:

> *the processing of one command at a time [(source)](https://en.wikipedia.org/wiki/Thread_(computing)#Single_threading)*

Ok, so JavaScript can "process" one command at a time. The opposite of single-threading, is multithreading. There are numerous pros and cons to both which we won't be getting into (feel free to check out the [Wikipedia article on Threading](https://en.wikipedia.org/wiki/Thread_(computing)#Single_threading) for more info about the pros and cons). We're going to take a look at JavaScript's single-threaded model and how/why we should write our code to take advantage of it.

Let's look at some code:

```js
function addParagraph() {
    const para = document.createElement('p');
    para.textContent = 'JavaScript is single threaded!';
    document.body.appendChild(para);
}

function appendNewMessage() {
    const para = document.createElement('p');
    para.textContent = "Isn't that cool?";
    document.body.appendChild(para);
}

addParagraph();
appendNewMessage();
```

Keeping JavaScript's single-threaded nature in mind (meaning it can only perform one task at a time), let's break down this code into the order it will run:

- the `addParagraph()` function is declared on line 1
- the `appendNewMessage()` function is declared on line 6
- `addParagraph()` is called on line 13
  - execution moves into the function and executes all three lines in order
  - now that the function is finished, execution returns to where it was called
- the `appendNewMessage()` function is called on line 14
  - execution moves into the function and executes all three lines in order
  - now that the function is finished, execution returns to where it was called
- the program ends because all lines of code have been executed

Hopefully, the order that this code executed in wasn't surprising. There are a couple of things I particularly want you to pay attention to:

- First, is the *run-to-completion nature of the code*. When `addParagraph()` is invoked on line 13, *all of the code in the function gets executed*: it doesn't just execute some lines and leave other lines to be executed later. The entire block of code is run.
- A second thing I want to point out is that `addParagraph()` is invoked, runs, and finishes before `appendNewMessage()` is invoked (including a possible reflow and repaint); JavaScript doesn't execute multiple lines/functions at the same time (this is single-threading...processing one command at a time!).

I have a question for you - once `addParagraph()` has been invoked and it runs the lines of code inside the `addParagraph()` function, how does it know to go back to `appendNewMessage()`? How does it keep track of that?

What if we changed this code slightly to create nested functions:

```js
function addParagraph() {
    const para = document.createElement('p');
    para.textContent = 'JavaScript is single threaded!';

    appendNewMessage();
    document.body.appendChild(para);
}

function appendNewMessage() {
    const para = document.createElement('p');

    para.textContent = "Isn't that cool?";
    document.body.appendChild(para);
}

addParagraph();
```

Notice that the call to `appendNewMessage()` is located inside the `addParagraph()` function. First, `addParagraph()` is invoked. Then `appendNewMessage()` is invoked on line 5. Once `appendNewMessage()` has finished running, execution returns and finishes running the last line of code in the `addParagraph()` function...but how does it know how to do that? How does the JavaScript engine know where it left off and how to get back to it?

**The Call Stack**

The JavaScript engine keeps a call stack (basically a list) of the functions that are running. When a function is invoked, it is added to the list. When all of the code inside a function has been run, then the function is removed from the call stack. The cool part about a call stack is that a function doesn't have to complete before another function is added to the call stack.

Let's see how this works!

---
QUESTION:

How many items (frames) will be on the stack when the code reaches the "stop here" comment?

```js
function quiz () {
  var y = 'yes';
  questions();
  fun();
}
function questions () {
  var y = 'no';
  return 7;
}
function are () {
  return 3;
}
function fun () {
  are();
  // stop here
}

quiz()
```

Assume there is no `"<main>"`/default frame.

OPTIONS:
- 0
- 1
- 2
- 3
- 4

ANSWER: '2'. When `// stop here` is reached, both `quiz` and `fun` are on the stack.

---

**The Call Stack Recap**

In this section, we looked at how JavaScript is a **single-threaded programming language**, which means it *can only execute one thing at a time*. We looked at how JavaScript keeps track of what functions are running by using the **Call Stack**.

**Further Research**
- [Call stack](https://developer.mozilla.org/en-US/docs/Glossary/Call_stack) on MDN
- [Call stack](https://en.wikipedia.org/wiki/Call_stack) on Wikipedia

# The Event Loop

**Code Synchronicity**

In the previous section on the `Call Stack`, we used the terms:

- run-to-completion
- single-threaded

Another term for this is **synchronous**. By definition, "synchronous" means:

> *existing or occurring at the same time*

All of the code we've been looking at runs in order, at the same time. Functions are added to the call stack, and then removed from the call stack when they've completed. However, there is some code that is not synchronous - meaning that the code is written just like any other code, but it is executed at some later point in time. Does this sound familiar at all? You've just been working with it:

```js
const links = document.querySelectorAll('input');
const thirdField = links[2];

thirdField.addEventListener('keypress', function handleKeyPresses(event) {
    console.log('a key was pressed');
});
```

...event listeners! *Most* of this code is synchronous like you're used to. But the event listener's function `handleKeyPresses` is not invoked immediately, it's invoked at some later point in time.

Have you ever wondered about that? Where does the code go? What about the "call stack" that we learned about? Is it hidden in the call stack somewhere?

Let's look at this code snippet:

```js
console.log('howdy');
document.addEventListener('click', function numbers() {
    console.log('123');
});
console.log('ice cream is tasty');
```

The code will run in this order:

1. `'howdy'` will be logged to the console
2. `'ice cream is tasty'` will be logged to the console

The string `'123'` will only be logged if there's a click. If the page is never clicked, then this code might not ever run! But where is it? Where did the `numbers` function holding the `console.log('123');` code go?

**Running Code Later**

But the same questions exist for this code as it does for the `.addEventListener()` code:

- where does the function go to wait?
- how does the function get run when it needs to?

This happens because of the **JavaScript Event Loop**!

**The JavaScript Event Loop**

The simplest explanation of JavaScript's **concurrency model** uses two rules:
- If some JavaScript is running, let it run until it is finished (`"run-to-completion"`).
- If no JavaScript is running, *run any pending event handlers*.

Since most JavaScript is run in response to an `event`, this is known as `an event loop`: *Pick up the next event, run its handler, and repeat.*

There are three parts you have to think about around the event loop:

- the Call Stack
- Web APIs/the browser
- an Event Queue

![event-loop](./event-loop.png)

Not all of the code that we write is 100% *JavaScript* code. Some of the code is interacting with the Web APIs (also known as "browser APIs"). There are many more examples, but both `.addEventListener()` and `setTimeout()` are Web APIs.

Let's look back at this code:

```js
console.log('howdy'); // 1
document.addEventListener('click', // 2
  function numbers() {
    console.log('123');
});
console.log('ice cream is tasty'); // 3
```

First, the browser runs this block of code to completion -- that is, steps 1, 2, and 3. Step 2 passes an event handler (`numbers`) to the browser for future use: the browser will hold this function until there's a click event.

What happens if someone clicks before this block of code is done? When there is a click event and there is code already running, the `numbers` function can't just be added directly to the `Call Stack` because of JavaScript's *run-to-completion nature*; we can't interrupt any code that might currently be happening. So the function is placed in the `Queue`. When all of the functions in the `Call Stack` have finished (also known as *idle time*), then the `Queue` is checked to see if anything is waiting. If something is in the `Queue`, then it's run, creating an entry on the `call stack`.

> **IMPORTANT:** The key things to remember here are: 1) current synchronous code runs to completion, and 2) events are processed when the browser isn't busy. Asynchronous code (such as loading an image) runs outside of this loop and sends an event when it is done.

So, we have the `Call Stack`, the `Browser` and the `Queue`.

1. We start at the first line of the code.

![event-loop-1](./event-loop-1.png)

2. The `console.log()` is run and added to the `Call Stack`

![event-loop-2](./event-loop-2.png)

3. When it finishes it's removed from the call stack

4. Now onto the event listener. It's added to the call stack because the code is being evaluated,

![event-loop-3](./event-loop-3.png)

5. But then it's handed over to the browser. The browsers internals are invisible to us but when the browser is clicked, it knows to run the `numbers` function.

![event-loop-4](./event-loop-4.png)

6. And that's it. The code moves onto the last line,

![event-loop-5](./event-loop-5.png)

7. It runs `console.log('ice cream is tasty') and finishes.

![event-loop-6](./event-loop-6.png)

8. !!! **but** Whenever the `browser` IS clicked, the `numbers` function is moved to the queue where waits untill the call stack is empty.

![event-loop-7](./event-loop-7.png)

![event-loop-8](./event-loop-8.png)

9. Then `numbers` function is moved to the `call stack` and invoked.

![event-loop-9](./event-loop-9.png)

10. Invoking the `numbers` function will invoke another `console.log('123'),

![event-loop-10](./event-loop-10.png)

11. when it's finished i's removed from the list,

![event-loop-11](./event-loop-11.png)

12. and the `numbers` function is finished and removed

![event-loop-12](./event-loop-12.png)

---
QUESTION:

What is the order that the iceCream function goes through if the `<footer>` is clicked?

```js
const pageFooter = document.querySelector('#page-footer');

pageFooter.addEventListener('click', function iceCream () {
    const footerDetails = document.querySelector('#details');

    footerDetails.textContent = 'Everyone should eat ice cream!';
});
```

ANSWER: order: browser-queue-call stack. When this code is run, the `iceCream` function is given to the `browser`. When the `<footer>` is clicked, the code moves to the `Queue`. Then, when the `Call Stack` is empty, `iceCream` is moved over to the `Call Stack` and invoked.

---

**Recap**

This section uncovered how JavaScript works under the hood; We looked at how `JavaScript`, the `DOM`, and `Web APIs` all fit together.

Specifically, we looked at how JavaScript is a *single-threaded* programming language, which means it can only execute one thing at a time. We looked at how JavaScript keeps track of what functions are running by using the `Call Stack`. We also looked at how *asynchronous* code is handled.

*Asynchronous* code makes use of the JavaScript `Event Loop`. Any `asynchronous code` (like `setTimeout` or the function passed to `.addEventListener()`) **is handled by the browser**. When this `asynchronous code` is ready to be executed, it's moved to the **queue** where it waits until the **Call Stack** is empty. Whenever the **Call Stack** is empty, code moves from the **Queue** over to the **Call Stack** and gets executed.

Knowing how `JavaScript` and the `Event Loop` work can help us write code that is more efficient.

**Further Research**

- [Concurrency model and Event Loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop)
- [Events and Handlers Overview](https://developer.mozilla.org/en-US/docs/Web/Guide/Events/Overview_of_Events_and_Handlers)
- [What the heck is the event loop anyway? by Philip Roberts on YouTube](https://www.youtube.com/watch?v=8aGhZQkoFbQ)

# setTimeout

**Running Code Later**

Similarly to `.addEventListener()` code being run at some later point, there is the `setTimeout()` function that will run code at a point later in time. The `setTimeout()` function takes:

- a function to run at some later time
- the number of milliseconds the code should wait before running the function

Let's check out an example:

```js
setTimeout(function sayHi() {
    console.log('Howdy');
}, 1000);
```

If we ran this code, the string `'Howdy'` would appear in the console in about 1,000 milliseconds or in just about 1 second.

Since `setTimeout()` is an API provided by the browser, the call to `setTimeout()` gives the `sayHi()` function over to the browser which it starts a timer. After the timer is finished, the `sayHi()` function moves to the Queue. If the Call Stack is empty, then the `sayHi()` function is moved to the Call Stack and executed.

**`setTimeout()` with Delay of 0**

An interesting aspect to `setTimeout()` is that we can pass it a delay of `0` milliseconds.

```js
setTimeout(function sayHi() {
    console.log('Howdy');
}, 0);  // ← 0 milliseconds!
```

You might think that since it has a delay of `0` milliseconds, that the `sayHi` function would run immediately. However, it still goes through the JavaScript Event Loop. So the function is handed off to the browser where the browser starts a timer for `0` milliseconds. Since the timer ends immediately, the `sayHi` function will move to the Queue, and then to the Call Stack once the Call Stack has finished executing any currently-running tasks.

So why is this helpful? Well, this technique can help us to convert potentially long-running code to one that's broken up to allow for the browser to handle user interactions!

**Break Up Long-Running Code**

Do you remember back to a previous section when we wrote JavaScript code to add two hundred paragraphs to the page? Now, instead of adding *two hundred* paragraphs to the page, what if we added *twenty thousand*? That's a lot of elements to create, append, and insert into the page!

Now keep in mind how reflow and repaint affect an app's performance. We want to write our JavaScript code to take into consideration reflow and repaint and to cause the fewest number of these.

However, we also want to make sure our app is responsive to user interaction. While JavaScript is running, the page is "busy" and the user won't be able to interact with the page (e.g. clicking a button, filling out a form). Remember that this is because JavaScript runs *synchronously*. So it will run to completion (creating, appending, and inserting all twenty thousand elements), and it does this *before* it is able to respond to any actions the user has taken. The function creates all of these elements and adds the to the page will be in the Call Stack until it's completely finished.

One way to give the user a chance to interact with the page is to break up the adding of the content into chunks. Let's do this with `setTimeout()`:

```js
let count = 1

function generateParagraphs() {
    const fragment = document.createDocumentFragment();

    for (let i = 1; i <= 500; i++) {
        const newElement = document.createElement('p');
        newElement.textContent = 'This is paragraph number ' + count;
        count = count + 1;

        fragment.appendChild(newElement);
    }

    document.body.appendChild(fragment);

    if (count < 20000) {
        setTimeout(generateParagraphs, 0);
    }
}

generateParagraphs();
```

This code starts off by setting a `count` variable to `1`. This will keep track of the number of paragraphs that have been added. The `generateParagraphs()` function will add 500 paragraphs to the page each time it's invoked. The interesting thing is that there's a `setTimeout()` call at the end of the `generateParagraphs()` function. If there less than twenty thousand elements, then it `setTimeout()` will be used to call the `generateParagraphs()` function.

If you try running this code on a page, you can still interact with the page while the code is running. It doesn't lock up or freeze the page. And it doesn't lock up or freeze because of the `setTimeout()` calls.

**`setTimeout()` Recap**

The browser-provided `setTimeout()` function takes another function and a delay, and invokes the function after the delay has passed.

Knowing how the JavaScript Event Loop works, we can use the `setTimeout()` method to help us write code that allows the browser to handle user interactions.

**Further Research**

- [setTimeout docs on MDN](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout)
- [Concurrency model and Event Loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop)
- [What the heck is the event loop anyway? by Philip Roberts on YouTube](https://www.youtube.com/watch?v=8aGhZQkoFbQ)
- [Scheduling: setTimeout and setInterval](https://javascript.info/settimeout-setinterval)

repository: anmud/learntocode

repo_name: anmud/learntocode


text:
# dgvm
dynamic game virtual machine kit

DGVM is a study into python's advanced features such as metaprogramming,
with the goal of being a "virtual machine kit", i.e. a way for the user to define transactional state
as a virtual machine with instructions and data models.

General goals of the project:

* Allow user to define data models (similar to ORM)
* Allow user to define custom instructions
* Allow state to be serialized and deserialized (with full execution history)
* Allow individual commits/diffs to be serialized and deserialized
* Allow for network conectivity and automatic state syncing

Non-goals:

* Optimal performance

##### Documentation is currently a work in progress as this project is a result of a couple of sprints focused on getting a minimal use case working. Please see the test cases to have some insight on the use cases.

TODO:
* Change ipc approach from threading to event loop
* docs docs docs
* more tests
* Fully functional use case sample


text:
## VGGFace2

To download the VGGFace2 dataset, refer to this link.

 The code to train the model on VGGFace2 is inspired from the facenet.


text:
This section includes information about how to contribute to the project, versioning rules and project development workflow.
[block:api-header]
{
  "type": "basic",
  "title": "Versioning"
}
[/block]
Currently, glim is not using any versioning standards before 1.x releases. After the 1.0 release, the project will use [semantic versioning](http://semver.org/). Currently, the versioning is used only  to seperate milestones of development. The minor version numbers increase only in bug fixes. You can check the [Roadmap & Future Releases](doc:roadmap) section for future releases and its versions.
[block:api-header]
{
  "type": "basic",
  "title": "Development Workflow"
}
[/block]
We are using github for the issue tracking. All the issues are consolidated there. The workflow of development will be the following;

- User creates a github issue.
- If this is a bug, the issue will be replicated by admin and approved, else it will be discussed and approved.
- Developer creates a local branch if this is a minor issue, else creates a remote branch.
- Developer provides a pull request.
- Admin merges from feature branch to dev branch and tests the feature requests locally.
- Admin merges from dev branch to master branch

Currently, it is unfortunate that all the actors mentioned above is 1 person. Therefore, it is needed more and more contributors.
[block:callout]
{
  "type": "info",
  "title": "Please provide tests after solving issues",
  "body": "After the 0.9 release of glim, writing unit tests will be an obligation."
}
[/block]

repository: aacanakin/glim-docs

repo_name: aacanakin/glim-docs


text:
# SiriWave

The "Apple Siri" wave replicated in pure Javascript using the Canvas API. To learn more about the project, [read the blog post here](https://dev.to/kopiro/how-i-built-the-siriwavejs-library-a-look-at-the-math-and-the-code-l0o), [check the demo](http://kopiro.github.io/siriwave) or [codepen](https://codepen.io/kopiro/pen/oNYepEb).

[![npm version](https://badge.fury.io/js/siriwave.svg)](https://badge.fury.io/js/siriwave)

### iOS (classic) style

The classic, pre-iOS9 style.

### iOS9 style

The new fluorescent wave introduced in iOS9.

### iOS13 style

_work in progress_

The wave reinvented as a bubble.

## Usage

### Browser (via CDN) usage

Import the UMD package via the unpkg CDN and it's ready to use.

```html
<script src="https://unpkg.com/siriwave/dist/siriwave.umd.min.js"></script>
```

### ES module

Install it through `npm install siriwave` or `yarn add siriwave` first:

```js
import SiriWave from "siriwave";
```

## Initialize

Create a div container and instantiate a new SiriWave object:

```html
<div id="siri-container"></div>
<script>
  var siriWave = new SiriWave({
    container: document.getElementById("siri-container"),
    width: 640,
    height: 200,
  });
</script>
```

## Constructor options

| Key               | Type               | Description                                                            | Default    | Required |
| ----------------- | ------------------ | ---------------------------------------------------------------------- | ---------- | -------- |
| `container`       | DOMElement         | The DOM container where the DOM canvas element will be added.          | null       | yes      |
| `style`           | "ios", "ios9"      | The style of the wave.                                                 | "ios"      | no       |
| `ratio`           | Number             | Ratio of the display to use. Calculated by default.                    | calculated | no       |
| `speed`           | Number             | The speed of the animation.                                            | 0.2        | no       |
| `amplitude`       | Number             | The amplitude of the complete wave-form.                               | 1          | no       |
| `frequency`       | Number             | The frequency of the complete wave-form. Only available in style "ios" | 6          | no       |
| `color`           | String             | Color of the wave. Only available in style "ios"                       | "#fff"     | no       |
| `cover`           | Bool               | The `canvas` covers the entire width or height of the container        | false      | no       |
| `autostart`       | Bool               | Decide wether start the animation on boot.                             | false      | no       |
| `pixelDepth`      | Number             | Number of step (in pixels) used when drawed on canvas.                 | 0.02       | no       |
| `lerpSpeed`       | Number             | Lerp speed to interpolate properties.                                  | 0.01       | no       |
| `curveDefinition` | ICurveDefinition[] | Override definition of the curves, check above for more details.       | null       | no       |

## API

#### `new SiriWave`

#### `curveDefinition`

By passing this argument, you're overriding the default curve definition resulting in a completely different style.

The default definition for the `ios` classic style is:

```js
[
  { attenuation: -2, lineWidth: 1, opacity: 0.1 },
  { attenuation: -6, lineWidth: 1, opacity: 0.2 },
  { attenuation: 4, lineWidth: 1, opacity: 0.4 },
  { attenuation: 2, lineWidth: 1, opacity: 0.6 },
  { attenuation: 1, lineWidth: 1.5, opacity: 1 },
];
```

and it results in 5 different sin-waves with different parameters and amplitude.

You can set 4 attributes for each curve:

- `attenuation`: the power factor determining the attenuation
- `lineWidth`: the line width
- `opacity`: the opacity
- `color`: the color, default to `SiriWave.color`; optional

The `ios9` style definition is instead:

```js
[
  { color: "255,255,255", supportLine: true },
  { color: "15, 82, 169" }, // blue
  { color: "173, 57, 76" }, // red
  { color: "48, 220, 155" }, // green
];
```

and it results in 3 different colored waves + 1 support wave that needs to be there.

Here you set:

- `supportLine`: only one of these curves must have this to `true`, it will be used to draw the support line
- `color`: the color of the wave

#### `start()`

Start the animation

#### `stop()`

Stop the animation.

#### `setSpeed(newValue)`

Set the new value of speed (animated)

#### `setAmplitude(value)`

Set the new value of amplitude (animated)

#### `dispose()`

Stop the animation and destroy the canvas, by removing it from the DOM.
Subsequent `start()` calls on this SiriWave instance will fail with an exception.

## Grapher plots

- [GCX default](etc/gcx/default.gcx)
- [GCX iOS 9](etc/gcx/ios9.gcx)

## Build and development

If you wanna make some modifications in your local environment, use:

```sh
yarn dev
```

this will create a watchable build with RollupJS and automatically create a server to see your changes in the browser.

To finally build all targets:

```sh
yarn build
```

## QA

#### How do I integrate this library with a microphone user input?

You can find an excellent demo [here](https://jsitor.com/PPQtOp9Yp) by @semmel

repository: kopiro/siriwave

repo_name: kopiro/siriwave


text:
# Qoncrete.com

## Install

```
$ npm run install
```

## Test
```
$ npm install -g http-server
$ http-server -p 8000
```

## Build

```
$ npm run build
```

## New Language

Whenever a new language is added to the site, please modify /.packacge.json
```json
"scripts": {
	"install": "gitbook install resources.md/",
	"build": "gitbook build resources.md/ resources/"
}
```
into
```json
"scripts": {
	"install": "gitbook install resources.md/; gitbook install zh-CN/resources.md/;",
	"build": "gitbook build resources.md/ resources/; gitbook build zh-CN/resources.md/ zh-CN/resources/;"
}
```


text:
# puppet-galera

[![Build Status](https://travis-ci.org/fraenki/puppet-galera.png?branch=master)](https://travis-ci.org/fraenki/puppet-galera)

NOTE: The "master" branch on GitHub contains the development version, which may break anything at any time. Consider using one of the stable branches instead.

#### Table of Contents

1. [Overview](#overview)
2. [Requirements](#requirements)
3. [Usage](#usage)
    - [Beginning with galera](#beginning-with-galera)
    - [Custom repository configuration](#custom-repository-configuration)
4. [Reference](#reference)
    - [Public classes](#public-classes)
        - [galera](#class-galera)
        - [galera::firewall](#class-galerafirewall)
        - [galera::repo](#class-galerarepo)
    - [Private classes](#private-classes)
        - [galera::debian](#class-galeradebian)
        - [galera::mariadb](#class-galeramariadb)
        - [galera::status](#class-galerastatus)
        - [galera::validate](#class-galeravalidate)
5. [Limitations](#limitations)
6. [Development](#development)
    - [Contributing](#contributing)

## Overview

This module will massage puppetlabs-mysql into creating a MySQL or MariaDB galera cluster.

It will try to recover from failures by bootstrapping on a node designated as the master if no other nodes appear to be running mysql, but if the cluster goes down and the master is permanently taken out, another node will need to be specified as the 'master' that can bootstrap the cluster.

## Requirements

* Puppet 5 or higher
* puppetlabs-mysql

## Usage

### Beginning with galera

Basic usage requires only the FQDN of the master node, a list of IP addresses of other nodes and two passwords:

```puppet
class { 'galera':
  galera_servers  => ['<IP_ADDRESS>', '<IP_ADDRESS>'],
  galera_master   => 'node1.example.com',
  root_password   => 'pa$$w0rd',
  status_password => 'pa$$w0rd',
}
```

This will install the default galera vendor and version. However, in a production environment you should definitely specify the vendor and version to avoid accidential updates:

```puppet
class { 'galera':
  vendor_type    => 'percona',
  vendor_version => '5.7',
  ...
```

On Debian/Ubuntu systems the user `debian-sys-maint@localhost` is required for updates and will be created automatically, but you should set a proper password:

```puppet
class { 'galera':
  deb_sysmaint_password => 'secretpassword',
  ...
```

Furthermore, a number of simple options are available:

```puppet
class { 'galera':
  galera_servers  => ['<IP_ADDRESS>', '<IP_ADDRESS>'],
  galera_master   => 'node1.example.com',
  root_password   => 'pa$$w0rd',
  status_password => 'pa$$w0rd',

  # Default is 'percona'
  vendor_type     => 'codership',

  # This will be used to populate my.cnf values that
  # control where wsrep binds, advertises, and listens
  local_ip => $facts['networking']['ip'],

  # This will be set when the cluster is bootstrapped
  root_password => 'myrootpassword',

  # Disable this if you don't want firewall rules to be set
  configure_firewall => true,

  # These options are only used for the firewall -
  # to change the my.cnf settings, use the override options
  # described below
  mysql_port => 3306,
  wsrep_state_transfer_port => 4444,
  wsrep_inc_state_transfer_port => 4568,

  # This is used for the firewall + for status checks
  # when deciding whether to bootstrap
  wsrep_group_comm_port => 4567,
}
```

A catch-all parameter can be used to populate my.cnf in the same way as the puppetlabs-mysql module:

```puppet
class { 'galera':
  override_options => {
    'mysqld' => {
      'bind_address' => '<IP_ADDRESS>',
    }
  }
  ...
}
```

### Custom repository configuration

Disable repo management if you are managing your own repos and mirrors:

```puppet
class { 'galera':
  configure_repo => false,
  ...
}
```

Or if you just want to switch to using a local mirror:

    # RHEL-based systems
```puppet
class { 'galera::repo':
  yum_baseurl => "http://repo.example.com/release/${facts['os']['release']['major']}/RPMS/${facts['os']['architecture']}/",
  ...
```
    # Debian-based systems
```puppet
class { 'galera::repo':
  apt_location => "http://repo.example.com/apt/${facts['os']['distro']['codename']}/",
  ...
```

## Reference

### Public Classes

#### Class: `galera`

* `additional_packages`: Specifies a list of additional packages that may be required for SST and other features. Valid options: an array. Default: A vendor-, version- and OS-specific value.
* `bind_address`: Specifies the IP address to bind MySQL/MariaDB to. The module expects the server to listen on localhost for proper operation. Valid options: a string. Default: `::`
* `bootstrap_command`: Specifies a command used to bootstrap the galera cluster. Valid options: a string. Default: A vendor-, version- and OS-specific bootstrap command.
* `client_package_name`: Specifies the name of the MySQL/MariaDB client package to install. Valid options: a string. Default: A vendor-, version- and OS-specific value.
* `configure_firewall`: Specifies wether to open firewall ports used by galera using puppetlabs-firewall. Valid options: `true` and `false`. Default: `true`
* `configure_repo`: Specifies wether to configure additional repositories that are requird for installing galera. Valid options: `true` and `false`. Default: `true`
* `create_root_my_cnf`: A flag to indicate if we should manage the root .my.cnf. Set this to false if you wish to manage your root .my.cnf file elsewhere. Valid options: `true` and `false`. Default: `true`
* `create_root_user`: A flag to indicate if we should manage the root user. Set this to false if you wish to manage your root user elsewhere. If this is set to undef, we will use true if galera_master == $::fqdn. Valid options: a string or undef. Default: `undef`
* `create_status_user`: A flag to indicate if we should manage the status user. Set this to false if you wish to manage your status user elsewhere. Valid options: `true` and `false`. Default: `true`
* `deb_sysmaint_password`: Specifies the password to set on Debian/Ubuntu for the sysmaint user used during updates. Valid options: a string. Default: `sysmaint`
* `default_options`: Internal parameter, *do NOT change!* Use `$override_options` to customize MySQL options.
* `galera_master`: Specifies the node that will bootstrap the cluster if all nodes go down. Valid options: a string. Default: `$fqdn`
* `galera_package_ensure`: Specifies the ensure state for the galera package. Note that some vendors do not allow installation of the wsrep-enabled MySQL/MariaDB and galera (arbitrator) on the same server. Valid options: all values supported by the package type. Default: `absent`
* `galera_package_name`: Specifies the name of the galera wsrep package to install. Valid options: a string. Default: A vendor-, version- and OS-specific value.
* `galera_servers`: Specifies a list of IP addresses of the nodes in the galera cluster. Valid options: an array. Default: `[${facts['networking']['ip']}]`
* `local_ip`: Specifies the IP address of this node to use for comms. Valid options: a string. Default: `$networking.ip`
* `manage_additional_packages`: Specifies wether additional packages should be installed that may be required for SST and other features. Valid options: `true` and `false`. Default: `true`
* `manage_package_nmap`: Specifies wether the package nmap should be installed. It is required for proper operation of this module. Valid options: `true` and `false`. Default: `true`
* `mysql_package_name`: Specifies the name of the server package to install. Valid options: a string. Default: A vendor-, version- and OS-specific value.
* `mysql_port`: Specifies the port to use for MySQL/MariaDB. Valid options: a string. Default: `3306`
* `mysql_restart`: Specifies the option to pass through to `mysql::server::restart`. This can cause issues during bootstrapping if switched on. Valid options: `true` and `false`. Default: `false`
* `mysql_service_name`: Specifies the option to pass through to `mysql::server`. Valid options: a string. Default: A vendor-, version- and OS-specific value.
* `override_options`: Specifies options to pass to `mysql::server` class. See the puppetlabs-mysql documentation for more information. Valid options: a hash. Default: `{}`
* `package_ensure`: Specifies the ensure state for packages. Valid options: all values supported by the package type. Default: `installed`
* `purge_conf_dir`: Specifies the option to pass through to `mysql::server`. Valid options:  `true` and `false`. Default: `true`
* `root_password`: Specifies the MySQL/MariaDB root password. Valid options: a string.
* `rundir`: Specifies the rundir for the MySQL/MariaDB service. Valid options: a string. Default: `/var/run/mysqld`
* `service_enabled`: Specifies wether the MySQL/MariaDB service should be enabled. Valid options: `true` and `false`. Default: `true`
* `status_allow`: Specifies the subnet or host(s) (in MySQL/MariaDB syntax) to allow status checks from. Valid options: a string. Default: `%`
* `status_available_when_donor`: Specifies wether the node will remain in the cluster when it enters donor mode. Valid options: `0` (remove), `1` (remain). Default: `0`
* `status_available_when_readonly`: When set to 0, clustercheck will return a "503 Service Unavailable" if the node is in the read_only state, as defined by the `read_only` MySQL/MariaDB variable. Values other than 0 have no effect. Valid options: an integer. Default: `-1`
* `status_check`: Specifies wether to configure a user and script that will check the status of the galera cluster. Valid options: `true` and `false`. Default: `true`
* `status_host`: Specifies the cluster to add the cluster check user to. Valid options: a string. Default: `localhost`
* `status_log_on_failure`: Specifies which fields xinetd will log on failure. Valid options: a string. Default: `undef`
* `status_log_on_success`: Specifies which fields xinetd will log on success. Valid options: a string. Default: `''`
* `status_log_on_success_operator`: Specifies which operator xinetd uses to output logs on success. Valid options: a string. Default: `=`
* `status_password`: Specifies the password of the status check user. Valid options: a string.
* `status_port`: Specifies the port for cluster check service. Valid options: an integer. Default: `9200`
* `status_user`: Specifies the name of the user to use for status checks. Valid options: a string: Default: `clustercheck`
* `validate_connection`: Specifies wether the module should ensure that the cluster can accept connections at the point where the `mysql::server` resource is marked as complete. This is used because after returning success, the service is still not quite ready. Valid options: `true` and `false`. Default: `true`
* `vendor_type`: Specifies the galera vendor to use. Valid options: codership, mariadb, percona. Default: `percona`
* `vendor_version`: Specifies the galera version to use. To avoid accidential updates, set this to the required version. Valid options: a string. Default: A vendor- and OS-specific value. (Usually the most recent version.)
* `vendor_version_internal`: Internal parameter, *do NOT change!*
* `wsrep_group_comm_port`: Specifies the port to use for galera clustering. Valid options: an integer. Default: `4567`
* `wsrep_inc_state_transfer_port`: Specifies the port to use for galera incremental state transfer. Valid options: an integer. Default: `4568`
* `wsrep_sst_auth`: Specifies the authentication information to use for SST. Valid options: a string. Default: `root:<%= $root_password %>`
* `wsrep_sst_method`: Specifies the method to use for state snapshot transfer between nodes. Valid options: mysqldump, rsync, skip, xtrabackup, xtrabackup-v2 (Percona). Default: `rsync`
* `wsrep_state_transfer_port`: Specifies the port to use for galera state transfer. Valid options: an integer. Default: `4444`

#### Class: `galera::firewall`

Open firewall ports used by galera using puppetlabs-firewall.

* `source`: Specifies the firewall source addresses to unblock. Valid options: a string. Default: `undef`

#### Class: `galera::repo`

This class will try to automatically lookup the repository data by taking `$galera::vendor_type` and `$galera::vendor_version` into account.

* `apt_repo_include_src`: Specifies whether to include source repo. Valid options: `true` and `false`. Default: `false`.
* `apt_key`: Specifies the GPG key ID of the APT repository. Valid options: a string.
* `apt_key_server`: Specifies the server from which the GPG key should be retrieved. Valid options: a string.
* `apt_location`: Specifies the APT repository URL. Valid options: a string.
* `apt_release`: Specifies a distribution of the APT repository. Valid options: a string. Default: `$facts['os']['distro']['codename']`.
* `apt_repos`: Specifies the component of the APT repository that contains galera packages. Valid options: a string. Default: `main`.
* `epel_needed`: Specifies whether to configure the Epel repository on YUM systems. Valid options: `true` and `false`. Default: `true`.
* `vendor_type`: Internal parameter, *do NOT change!*
* `yum_baseurl`: Specifies the YUM repository URL. Valid options: a string.
* `yum_descr`: Specifies the YUM repository description. Valid options: a string.
* `yum_enabled`: Specifies whether to enable the YUM repository. Valid options: `true` and `false`. Default: `true`.
* `yum_gpgcheck`: Specifies whether to verify packages using the specified GPG key. Valid options: `true` and `false`. Default: `true`.
* `yum_gpgkey`: Specifies the GPG key ID of the YUM repository. Valid options: a string.

### Private Classes

#### Class: `galera::debian`

This private class adds several workarounds to solve issues specific to Debian-based systems.

#### Class: `galera::mariadb`

This private class fixes issue when using MariaDB.

#### Class: `galera::status`

This private class configures a user and script that will check the status of the galera cluster.

#### Class: `galera::validate`

This private accept connections at the point where the `mysql::server` resource is marked as complete.
This is used because after returning success, the service is still not quite ready.

* `action`: Specifies the MySQL/MariaDB command to run. Valid options: a string. Default: `select count(1);`
* `catch`: Specifies a string that if present indicates failure. Valid options: a string. Default: `ERROR`
* `delay`: Specifies the seconds to sleep between attempts. Valid options: an integer: Default: `3`
* `host`: Specifies the MySQL/MariaDB host to check. Valid options: a string. Default: `$galera::status_host`
* `inv_catch`: Specifies a string that if not present indicates failure. Valid options: a string. Default: `undef`
* `password`: Specifies the password for the MySQL/MariaDB user. Valid options: a string. Default: `$galera::status_password`
* `retries`: Specifies the number of times to retry connection. Valid options: an integer. Default: `20`
* `user`: Specifies the MySQL/MariaDB user to use. Valid options: a string. Default: `$galera::status_user`

## Limitations

This module was created to work in tandem with the puppetlabs-mysql module, rather than replacing it. As the stages in the mysql module are quite strictly laid out in the `mysql::server` class, this module places its own resources in the gaps between them.

Of note is an `exec` that will start the mysql service with parameters which will bootstrap/start a new cluster, but only if it cannot open the comms port to any other node in the provided list. This is done with a simple `nc` command and should not be considered terribly reliable.

Furthermore the bootstrap functionality may be considered harmful. A better approach is currently being discussed and will be included in a future release ([GH-116](https://github.com/fraenki/puppet-galera/issues/116)).

## Development

### Contributing

Please use the GitHub issues functionality to report any bugs or requests for new features. Feel free to fork and submit pull requests for potential contributions.

repository: efoft/puppet-galera

repo_name: efoft/puppet-galera


text:
---
layout: post
title: One year as a postdoc in the federal government
image: /img/posts/IMG_6384.JPG
tags: [postdoc, government, thoughts]
---

After a little over a year with the U.S. Geological Survey (USGS), I thought I would write up some thoughts

<img src="../img/posts/IMG_6385.JPG">

At the time of this writing, I have been a "USGS Mendenhall Postdoctoral Fellow" for a little over a year. I began my position remotely at the end of October 2019, moved to Fort Collins, Colorado in January of 2020 where I worked for about two months in an office and then have worked from home since due to the COVID-19 pandemic.

I thought it would be useful for current graduate students, or those otherwise considering a career in government to hear some thoughts. Obviously I do not have a long track-record in government science, *and my experience is heavily altered by the chaos of this year*, but I haven't seen a ton written about the "government life" and thought people would be interested.

Because this is a post about government research, I'll start with a cheeky but maybe obligatory: these are my person views, provided in my non-professional capacity, and do not represent any opinions, recommendations, or official position of the U.S. federal government. :P

Honestly, this post became kinda-long because I had a lot I wanted to blather about. Here's a handy clickable list to skip to a section of interest:

[INSERT LIST]

## Getting the job

I have been asked a few times about how I landed my current position. I know of many great scientists in graduate school who maybe had previous government experience and planned to return to a federal position when they completed their degree. I did not necessarily plan on a position in government after graduate school.

In my fifth year at UC Davis I was a part of the Professors for the Future program. They encouraged us to conduct informational interviews and to explore career options besides "traditional" academic tracks. In that spirit, I had a short chat with Rich Hatfield of Xerces Society and another supposed-to-be-short-but-turned-into-multiple-hours chat with Ian Pearse at USGS.

I intended just to ask Ian about what it was like to work in government, whether he liked the agency, what his day to day was like, etc. We chatted about that, but then Ian mentioned he would be hiring a postdoc to work on Rusty Patched Bumble Bee projects in the near future and that I should consider applying. So, basically, I did. For the USGS Mendenhall program, you have to submit a competitive proposal based around a topic area. Without detailing the program here, basically the USGS advertises a variety of research areas they will hire postdocs for and then you submit a proposal within that research domain. I am happy to provide anyone with my proposal if you're curious.

After submitting my proposal, it went through a HR filter, likely was seen by a few people, evaluated, and then ultimately selected. Ian and I worked on the proposal together - so in some ways it's sort of like having the "project" accepted rather than a particular researcher. Overall, I'm not sure that my particular experience "getting the job" is going to apply to a lot of people...but I think the main point is that informational interviews are the absolute best thing you can do to "generate your own coincidences" (a phrase from a author-carpenter I always admired).

**What is probably a universal experience with getting a government job**...is how freaking long it took to work its way through the system. I basically had known that I was selected in ~June 2019. Then I had to make a mad dash to finish my PhD in time to have degree-in-hand for September. USGS requires it to actually say on your transcript that you have a PhD to be hired at the GS-12 level (my "grade"). After a whole set of shenanigans around that, worry that the offer would expire or something, background checks, fingerprinting, etc...it all came together and I began my job in late October 2019. Ian was super accomodating about me working remotely at first (in retrospect, a sort of funny sentiment given we are all remote now) but I had to physically be present in Colorado on my first day of work to receive my computer, access codes, etc.

## Organizational structure (gov't v. academia)

## Day to day, projects, and "my mission"

## Salary, funding, and grants

## Work-life balance

## Government bureaucracy and paperwork

## USGS vs. other agencies

##

gha_language: HTML