text:
# annie-rose
## Examples
### 3 Host

This example shows a basic 3 host network with each host connected to a quantum circulator switch. Although basic, this configuration permits transmission and reception between any host. The simulation is currently configured to transmit a long string of text from Alice to Bob, but this may be altered if desired.

Before running the example, you must load the Open vSwitch kernel module and launch the switch. Please refer to the proper documentation on information on how to do this. It's important to note that the Open vSwitch instance must be closed and relaunched after each example run, otherwise existing quantum flows may interfere with new ones.

To run the example, simply run the app.py using python:
```
# python app.py
```
After the setup is complete, you may execute scripts on the simulated hosts as would you on a real host. This is the great benefit of using Mininet: it allows a completely interactable simulation. To run the example, execute the following within the Mininet CLI:
```
bob xterm &
alice xterm
```
This will launch two instances of xterm, one for Alice and one for Bob. In Bob's xterm window, run his host script to listen for requests for quantum transmissions:
```
$ python lib/b_qim_client.py
```
and in Alice's xterm window, run her host script to transmit text through quantum transmission to Bob:
```
$ python lib/a_qim_client.py
```
As soon as you enter Alice's command, you should begin to see text output in Bob's terminal. This text has been transmitted through a simulated quantum channel using superdense coding. Since there is no noise model present, the transmission is perfect.

#### Files
##### `app.py`
Excluding Open vSwitch, this script is what launches the interactable simulation. The network topology file is parsed and passed into the network simulator. The software for each host is launched within their own namespace, and by using IPC through the /tmp location, quantum simulation traffic is routed without traversing and impacting the simulated network. The script also installs specific quantum flows to the switch, allowing circuit switched quantum network traffic.

##### `3host.json`
A JSON representation of the network topology.

##### `lib/qim_client.py`
A generic host script for quantum communication using superdense coding.

##### `lib/a_qim_client.py`
A host script for communicating classical data with superdense coding. This file is for transmission, where an example text is sent to Bob.

##### `lib/b_qim_client.py`
A host script for communicating classical data with sueprdense coding. This file is for reception, where an example text is received from Alice.

repository: stjordanis/annie-rose

repo_name: stjordanis/annie-rose


text:
---
layout: post
title: Introduction to Regular Expression
date: "2013-06-29 03:51"
tags: [regex]
permalink: /2013/06/29/regular-expression-intro/
gh-repo: sarkershantonu/sarkershantonu.github.io
excerpt: "Blog on Regular Expression"
gh-badge: [star,follow]
comments: true
---
In this article, we are going to learn basic Regular Expression.

### Why Regular Expression(Regix)
Regular expression is one of the daily necessary items for a developer as well as tester. My focus will be on how to cover both side. I personally use regular expression
- Jmeter, Gatling, Load Runner for extracting information from response data/headers/cookie/url
- Data Scraping, for extracting information from any HTML/CSS/XML element
- Selenium webdriver, for finding element
- Robotium, for finding element
- Genie, For finding element.
- NodePadd++ to modify regex based information.

So, my focus will be the basic terms and examples which are used by me.

First, let's have an idea about what is Regular Expression. A regular expression is the set of characters containing symbolic and literal meaning, together they create an expression that matches like as pattern match from a given character set. Detail description, you may find in [wiki](https://en.wikipedia.org/wiki/Regular_expression). The main objective is , getting objective character set from given set of characters.
So, a regular expression activity will have 3 parts.
a. Given text or set of characters or a doc( text/html/xml or any)
b. Pattern to match( the regular expression)
c. Matched Array(the result set)

### String Definition
Before start writing Expressions, we need to know some **Stringdefination/meaning** (literal) in the regex. Let's use see in the rgular expression the meaning of the symbols.
- Letters: ```a-z```
- Digits : ```0-9```
- Capital Letters: ```A-Z```
- any character: ```.```
- any single digit: ```\d```
- any Non Digit character: ```\D```
- Period: ```\.```
- white space:```\s```
- any Non White space: ```\S```
- any alpha numeric character: ```\w```
- any non alpha numeric character: ```\W```
- starts with indicator: ```^```
- ends with indicator: ```$
- makes/captures in a groups: ```( )```
- makes/captures in a sub groups: ```(a(bc))```
- makes/captures variable content: (.*)

### Conditional Logic expressions
- matches a or b: ```a|b```
- only one of a, b or c: ```[abc]```
- Not of abc, means no a/b/c: ```[^abc]```
- any single character of range a to z: ```[a-z]```
- any single character of range A to Z: ```[A-Z]```
- any single number between 0-9: ```[0-9]``` .It is similar to ```\d```
- m times repetitions: ```{m}```
- Minimum m time to maximum n time repetitions: ```{m,n}```
- any literal present ZERO or more times : ```*```
- any literal present ONE or more times: ```+```
- optional character indication :```?```

So, what are those. Those are meaning in the expression.

### Example:
If our data string is like ***abcdefgh123ijklmnopqrstuvwxyz*** and we need to find **123** from there.

So, our regular expression will be simple ```123```

we can add some intelligence here. What if we do not know the value is 1,2 or 3. If we need 3 adjacent digits. So , our expression will be ```\d\d\d```

As there is 3 times digits, we can write like ```\d{3}```.

If, we consider a digit but there can 1 minimum and 3 maximum. Then expression will be ```\d{1,3}```.

In a similar situation when we need min 1, maximum unlimited the expression will be ```\d+```.

Or no minimum and unlimited maximum digits , the expression ```\d*```

### Useful Links
1. For learning basic with [JAVA](http://www.vogella.com/articles/JavaRegularExpressions/article.html)
2. To [practice](http://regexone.com/)
3. To do experiment or test before apply , use this tool [**The Regex Coach**](http://www.weitz.de/regex-coach/)

And for advanced users , you may [**see this**](https://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html). It's a very enlarge support for JAVA.

Thanks...:)...

license: MIT

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
# Adapter

## Intent :dart:

Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

 The problem is when the service are incompatible with your client code (or class).

> [Service class example](BooksApi.php)

### Adapter :electric_plug:

The Adapter are the solution for our problem, this class are responsible to rewrite some features of client, so that the application can work with the external service properly.

> [Adapter class example](MyLibrary.php)

branch_name: refs/heads/main


text:
# Creating a CoreOS account

Creating a CoreOS account activates a License for up to 10 free nodes on a Tectonic cluster.

First, go to [https://account.coreos.com/login][account-login] to sign up for a CoreOS account.

A confirmation email will be sent to the listed account. Check your inbox for an email from CoreOS Support, and click *Verify Email*.

Log in to complete registration and access the account *Overview* page, which lists available CoreOS products.

Click *Free for use up to 10 nodes* below Tectonic, enter your contact information, and click *Get License for 10 nodes* to complete the registration process. Once complete, the *Overview* page will list active subscriptions, and provide access to your CoreOS License and Pull Secret.

## CoreOS License and Pull Secret

The *CoreOS License* and *Pull Secret* are required to install Tectonic and access container images for CoreOS products.

To obtain these files, [log in][account-login] to your CoreOS account, and click the buttons to *Download CoreOS License* and *Download Pull Secret*. Then, provide them when requested during the installation process.

[account-login]: https://account.coreos.com/login

repository: zbwright/tectonic-docs

repo_name: zbwright/tectonic-docs


text:
---
title: Opening Native Projects
description: Opening Native Projects via Native IDEs
url: /docs/basics/opening-native-projects
contributors:
  - dotnetkow
  - mlynch
---

# Opening Native Projects

Capacitor uses the native IDE for each platform in order to provide required configuration, and to build, test, and deploy apps.

For iOS development, that means you must have Xcode 10 or above installed. For Android, Android Studio 3 or above.

Both IDEs can be opened manually or using the npx cap open command:

## Opening Xcode

```bash
npx cap open ios
```

Alternatively, you can open Xcode manually:

```bash
open ios/App/App.xcworkspace
```

## Opening Android Studio

```bash
npx cap open android
```

Alternatively, you can open Android Studio and import the `android/` directory as an Android Studio project.

repository: chrisweight/capacitor

gha_license_id: NOASSERTION

repo_name: chrisweight/capacitor


text:
See LaTeX run.  Run latexrun.

latexrun fits LaTeX into a modern build environment.  It hides LaTeX's
circular dependencies, transforms errors into a standard and
user-friendly format, and generally enables other tools to do what
they do best.

Features
========

* Runs latex the right number of times.  LaTeX's iterative approach is
  a poor match for build tools that expect to run a task once and be
  done with it.  latexrun hides this complexity by running LaTeX (and
  BibTeX) as many times as necessary and no more.  Only the results
  from the final run are shown, making it act like a standard,
  single-run build task.

* Visible error messages and warnings.  LaTeX and related tools bury
  errors and useful warnings in vast wastelands of output noise.
  latexrun parses this spew and prints only the messages that matter,
  in a format understood by modern tools.  latexrun even figures out
  file names and line numbers for many BibTeX errors that usually
  don't indicate their source.

* Incremental progress reporting.  latexrun keeps you informed of
  LaTeX's progress, without overwhelming you with output.

* Cleaning.  LaTeX's output files are legion.  latexrun keeps track of
  them and can clean them up for you.

* Atomic commit.  latexrun updates output files atomically, which
  means your PDF reader will no longer crash or complain about broken
  xref tables when it catches latex in the middle of writing out a
  PDF.

* Easy {.git,.hg,svn:}ignore.  Just ignore `.latexrundb` and
  `latex.out/`.  Done!

Non-features
============

Kitchen sink not included.  latexrun is not a build system.  It will
not convert your graphics behind your back.  It will not continuously
monitor your files for changes.  latexrun is designed to be *part* of
your build system and let other tools do what they do well.

Integrating with make
=====================

latexrun does its own dependency tracking (at a finer granularity than
`make`).  Since it also does nothing if no dependencies have changed,
it's easy to integrate with `make` using phony targets.  Here's a
complete example:

```Makefile
.PHONY: FORCE
paper.pdf: FORCE {files that need to be generated, if any}
	latexrun paper.tex

.PHONY: clean
clean:
	latexrun --clean-all
```

Note that `paper.pdf` depends on a phony target, but is not itself
phony, since this would cause `make` to consider anything that
*depended* on `paper.pdf` to always be out of date.  Instead, `make`
only considers targets that depend on `paper.pdf` out of date if
latexrun actually updates `paper.pdf`.

How latexrun works
==================

latexrun views the world as a cyclic graph of deterministic functions
of system state:

         .tex → ┌───────┐ ─────────────────────────→ .pdf
    ╭─── .aux → │       │ → .aux ──╮
    │╭── .toc → │ latex │ → .toc ─╮│
    ││╭─ .bbl → │       │ → .log  ││
    │││     … → └───────┘ → …     ││
    │╰────────────────────────────╯│
    ╰──────────────────────────────┤
      │                            ↓
      │                 .bst → ┌────────┐ → .blg
      │                 .bib → │ bibtex │ → .bbl ─╮
      │                        └────────┘         │
      ╰───────────────────────────────────────────╯

latexrun's goal is to find the *fixed-point* of this computation.  Put
simply, it runs latex and bibtex repeatedly until it can guarantee
that additional runs will not change the output.

A direct approach could be to check the output of latex and bibtex
after each run and stop when the output is the same from one run to
the next.  This works, but runs latex too many times; it will have
already produced its final output one iteration before this approach
can figure out that it's done.

Instead, latexrun models latex and bibtex as deterministic functions
of the file system state, their command-line arguments, and certain
environment variables.  Hence, if the *inputs* to latex and bibtex do
not change over one iteration, then latexrun can guarantee that the
output also will not change, and stop.

Known bugs
==========

latexrun doesn't always track files that *don't* exist, so it may not
re-run LaTeX after a file gets created.  Currently the best solution
is to latexrun --clean-all, though this it obviously sub-optimal.

Command-line usage errors when calling latex appear before "This is
pdfTeX" and are not logged and therefore often not reported.

Tasks
=====

* Use `errors='surrogateescape'` (or maybe latin1 encoding) instead of
  bytes in the filter code.

* Solve the problem of missing input files.  LaTeX doesn't record
  inputs that it couldn't read, so we don't know about them even
  though they affect the computation (often seriously!).  We can
  partially address this by getting the listing of the output
  directory before running latex.  Once we know the jobname and such,
  filter this listing down to files that start with the jobname,
  remove a few others that are known not to be inputs like the output
  file and the log file, and then record this *listing* as an input.
  This isn't perfect, but it's a good approximation.  We could also
  scan the log for "No file X.", which is printed by LaTeX's `\@input`
  for things like aux and toc files and could potentially catch more
  optional inputs.  Neither of these solutions solves the problem for
  general user input files.

* If LaTeX logs "No pages of output." on a line, then no output file
  is generated and the exit status is 0.  Perhaps that should be a
  warning or an error?  Currently we don't report anything, which is
  confusing.  This message takes the place of the "Output written on
  X" that indicates the main output file name.

* Provide a way to disable output filters for things that do their own
  output parsing (e.g., AUCTeX).

* Integrate even better with `make`.  Phony rules are okay, but will
  force `make` dependencies to be generated even if latexrun
  ultimately does nothing.  Since latexrun's dependencies are
  finer-grained than `make`'s, it might be necessary to shell out to
  latexrun to do this.

* Include page numbers at least in overfull/underfull box warnings.

* Separate clean data by source file so you can clean a single input
  file's outputs.

* Some important things like undefined references are only considered
  warnings since they don't stop compilation.  Maybe distinguish
  document-mangling warnings (almost but not quite errors) and format
  warnings (can be ignored if justified).

repository: keithw/latexrun

repo_name: keithw/latexrun


text:
## v1.1.8
* Add `include` support for file config

## v1.1.6
* Check for unknown state when stopping (ephemerals final state is :unknown)
* Force Rye to proxy method_missing correctly on free form commands

## v1.1.4
* Only stop container on cleanup if container is running
* Add flag for selection of using ssh or attach to run commands

## v1.1.2
* Provide direct access to `Rye::Box`
* Add alternate ephemeral init using bash wrapper for cleanup

## v1.1.0
* Update all documentation to yardoc
* Group classes into logical namespaces
* Define expected returns for methods
* Remove calls to lxc-shutdown (not always available)
* Always attempt in container halt prior to lxc-stop
* Use lxc-ls for container listing to prevent permission issues
* Use the Rye library under the hood for container connects
* Use ChildProcess for shelling out

## v1.0.22
* Update underlying implementation for execute
* Provide better info interpretation
* Scrub bundler environment variables if found

## v1.0.20
* Fix `LxcFileConfig` population when using `Chef::Resource` instance

## v1.0.18
* Use shellwords to properly break down commands
* Force hash type as required
* Return expected type on command failure
* Remove custom `run_command` and use helper based method instead

## v1.0.16
* Fix syntax bug in `Lxc::FileConfig` (thanks @mikerowehl)

## v1.0.14
* Remove rebase artifact because duh

## v1.0.12
* Allow access to ephemeral setup without creation (thanks @portertech)
* Add `#destroy` method to `Lxc` instances (thanks @portertech)

## v1.0.10
* Add clone support
* Allow command passage to ephemeral nodes
* Update temp directories to be world accessible/readable
* Clean up and dry out some reusable bits

## v1.0.8
* Delete overlay directories using `sudo`

## v1.0.6
* Fix `sudo` issue on ephemeral creation (tmpdir)
* Allow multi-retry on info since false error can be encountered if container is in shutdown phase

## v1.0.4
* Removes vendored lxc cookbook
* Adds proper implementations for lxc and ephemerals

## v1.0.2
* Update Chef::Log usage to only apply when Chef is loaded

## v1.0.0
* Initial release

repository: iroller/elecksee

repo_name: iroller/elecksee


text:
# Implementation of the Lind/Mehlum utest

To test for a U shaped or inverse U shaped relationship, it is necessary to provide an interval where the shape is located. A U shaped relationship is downward sloping at the lower bound and upward sloping at the upper bound, and vice versa for an inverted U shape. This package provides a joint test of the two slopes.

See Lind and Mehlum: [With or Without U? The Appropriate Test for a U‐Shaped Relationship](https://doi.org/10.1111/j.1468-0084.2009.00569.x) for details

## Installation

## Implementation for R

To install the R package from this repository (assuming `devtools` is installed)
```
devtools::install_github('https://github.com/jotlind/utest')
```

## Implementation for Stata
To install the Stata package from SSC
```
ssc install utest
```

## Running the package in R

Set up data
```
x <- runif(100,min=-1,max=1)
xsq <- x^2
y <- x^2+rnorm(100)
mod <- lm(y~x+xsq)
```

Run the U test
```
utest(mod,c("x","xsq"))
```

Get details on the slope of the relationship at the boundaries
```
uslopes(mod,~x+xsq)
```

## Authors

- [Jo Thori<EMAIL_ADDRESS>- [Halvor<EMAIL_ADDRESS>

## License
[![License](http://img.shields.io/:license-mit-blue.svg?style=flat-square)](http://badges.mit-license.org)

- **[MIT license](http://opensource.org/licenses/mit-license.php)**
- Copyright 2020 © Jo Thori Lind and Halvor Mehlum.

repository: jotlind/utest

repo_name: jotlind/utest


text:
# Overview

This document describes Thunder's logging system. This system
features output that lists the log domain and severity in a clear manner, allows the log level both
globally and for specific subsystems to be changed while the server is running, and is simple to
use.

The output looks like

        2018/06/12 10:47:31 INFO: [/Bouncer/Server]: bncrServer.go:113: expecting chainid 19
        2018/06/12 10:47:31 INFO: [/Bouncer/Client]: bncrClient.go:82: starting
        2018/06/12 10:47:31 INFO: [/Bouncer/Client/Conn]: bncrClient.go:107: Connected from <IP_ADDRESS>:48876 to <IP_ADDRESS>:8887
        2018/06/12 10:47:31 INFO: [/Bouncer/Server]: bncrServer.go:162: start listening
        2018/06/12 10:47:31 INFO: [/Bouncer/Server]: bncrServer.go:165: bouncer listening on port [::]:8886
        2018/06/12 10:47:31 INFO: [/Bouncer]: bouncer.go:154: ackChannelHandler starting
        2018/06/12 10:47:31 INFO: [/Bouncer]: bouncer.go:139: txChannelHandler starting
        2018/06/12 10:47:38 INFO: [/Bouncer/Server/Conn] 1: bncrServer.go:205: Connection from [::1]:49920
        2018/06/12 10:47:38 INFO: [/Bouncer]: bouncer.go:145: got tx id 1/0 from txChannel
        2018/06/12 10:47:38 INFO: [/Bouncer/Client]: bncrClient.go:326: send txact 1/0
        2018/06/12 10:47:38 INFO: [/Bouncer]: bouncer.go:145: got tx id 2/1

# Usage

To use a logger, create an instance of a Lgr object for each subsystem
(client, server, connection, etc.).  These are organized hierarchically, so that it is possible
to globally display all log messages of level warning or above, but for /Bouncer/Server display
info and above.  In code this looks like

        svr.lgr = bouncer.Lgr.ChildLgr("Server")

to log something:

        svr.lgr.Info("bouncer listening on port %s", svr.listenIpPort)

which produces

        2018/06/12 10:47:31 INFO: [/Bouncer/Server]: bncrServer.go:165: bouncer listening on port [::]:8886

## Tagged Loggers

Sometimes sub-systems can make their logs extra useful by adding fixed tags to each
log line. For example, connection loggers can add information about remote host, or committee can
add its own committee id which can be useful in tests which run multiple committee in same process.
To build tagged loggers, use:

        committee.lgr = lgr.NewLgrT("Committee", commId)
        OR
        conn.lgr = svr.lgr.NewChildLgrT("Conn", remoteAddr)  // svr.lgr from above example

Log line for tagged loggers will look like:

        2018/06/12 10:47:38 INFO: [/Bouncer/Server/Conn(<IP_ADDRESS>:12345)]: bncrServer.go:252: tx check failure: invalid transaction v, r, s values

This is a format that's easy to scan visually, and offers a lot of control.  At a previous company
we used something like this, and it was very useful to be able to temporarily log more data from
specific areas, and then turn it back to default, after collecting some data.

It uses a single log.Logger instance to write the data to the output writer.

# Output levels

Output levels are controlled by calling lgr.SetLevel, as in

        lgr.SetLevel("/Bouncer/Client", lgr.LvlWarning)

# Load/Save logging level specs

The current set of log level specs can be saved by calling

        err := WriteLogCfg(os.Stdout) //or any io.Writer

and can be read via

        err := ReadLogCfg(os.Stdin) //or any io.Reader


text:
## Details

Normally, when you modify elements, each modification can trigger a style calculation and a redraw --- depending on timing for a redraw.  For example, the following will cause two style calculations and at least one draw:

```js
cy.$('#j')
  .data('weight', '70')   // style update
  .addClass('funny')      // style update AGAIN
  .removeClass('serious') // style update YET AGAIN

  // at least 1 redraw here
  // possibly 3 total depending on speed of above operations
  // (for one ele almost certainly 1 redraw, but consider many eles)
;
```

This is not a problem for a handful of operations on a handful of elements, but for many operations on many elements you end up with redundant style calculations and probably redundant redraws.  In the worst case, you have `eles.length * numOps` style updates and redraws --- and both style updates and redraws can be expensive.  In the worst case when using `cy.batch()`, you limit the style updates to `eles.length` and you limit the redraws to just one.

Thus, this function is useful for making many changes to elements at once.  When the specified callback function is complete, only elements that require it have their style updated and the renderer makes at most a single redraw.

This makes for very efficient modifications to elements, but it has some caveats.  While inside the batch callback,

* you can not reliably read element style or dimensions (it may have changed, or computed values may be out of date),
* you probably do not want to use `eles.style()` et cetera because they force a style bypass rather than a recalculation.

## Examples

Synchronous style:
```js
cy.batch(function(){
  cy.$('#j')
    .data('weight', '70')
    .addClass('funny')
    .removeClass('serious')
  ;
});
```

Asynchronous style:
```js
cy.startBatch();

cy.$('#j')
  .data('weight', '70')
  .addClass('funny')
  .removeClass('serious')
;

cy.endBatch();
```

branch_name: refs/heads/unstable

gha_language: JavaScript

gha_license_id: MIT


text:
<!-- Do not edit this file. It is automatically generated by API Documenter. -->

[Home](./index.md) > [@anglr/common-structured-log](./common-structured-log.md) > [RestLog](./common-structured-log.restlog.md) > [logLevel](./common-structured-log.restlog.loglevel.md)

## RestLog.logLevel property

Level of log

<b>Signature:</b>

```typescript
logLevel: string;
```


text:
Background
==========
This document is a developer's guide to developing `vx-sync`. `vx-sync` is the implementation to synchronize the VistA Exchange (VX) cache, expanding on the existing HMP Sychronization process. `vx-sync` is to support multiple sources of data, be able to scale to enterprise demands by supporting processing data massively in parallel and in order independent manner, and be able to reliable reflect how up-to-date the data in the cache is.

The overall design for `vx-sync` may be found on the wiki [https://wiki.vistacore.us/pages/viewpage.action?pageId=4720941].

This document
=============
This document is written using markdown [http://daringfireball.net/projects/markdown/syntax]. This ideal is that, by following markdown syntax, this is maintainable and readable as a plaintext document but can also be "compiled" to a PDF or HTML document for distrubution or pretty formatting.

This document is maintained in the vx-sync git repository as `product/production/vx-sync/README.md`.

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

Node
----
`node.js` [http://nodejs.org] is the container under which the vx-sync job processors run. It is _comparable_ in purpose to the `JVM` for the Java ecosystem.

`npm` is the package management service for node.js. It is _comparable_ in purpose to Maven repositories for the Java ecosystem.

`vx-sync` must have `node.js` and `npm` installed.

We try to stay reasonably current with the latest stable version of node. At the time this document was written, the latest version of node was 0.10.33.

```
jayray> node --version
v0.10.33
jayray> npm --version
1.3.11
```

Beanstalkd
----------
Must have `beanstalkd` installed. Check to see if installed.

```
jayray> beanstalkd -v
beanstalkd 1.9
```

Until we have the infrastructure scripts to manage installing `node.js`, `npm`, and `beanstalkd`, use brew [http://brew.sh].

Using `brew install node` (this will install both node and npm), `brew install beanstalkd`.

Run `npm install` to ensure all required npm modules are installed

IDE and environment
-------------------
TODO: provide link to IDE setup. Ensure that everyone is using same plug-in's

Get the code
------------
Perform `git clone https://code.vistacore.us/scm/app/VX-Sync.git`.

This needs to change to get source code from an infrastructure boostrap script.

Install npm defined dependencies
--------------------------------
Once you have the source code and npm, use npm to pull down any dependencies by running:

```
npm install
```

Running the Application
=======================
Note: much of this is placeholder until we get legit infrastructure scripts. This is intended to be used for a short period of time.

To start the entire framework, there are 10 processes that must be run. Start them in the order listed from within `~/Projects/vistacore/VX-Sync/product/production/vx-sync`:

* `beanstalkd -p 5000 -V`
* `node mocks/vista/vista-mock.js --vistaId 9E7A --port 10001 | node_modules/.bin/bunyan -o short`
* `node mocks/vista/vista-mock.js --vistaId C877 --port 10002 | node_modules/.bin/bunyan -o short`
* `node endpoints/mvi/mvi-endpoint.js --connector ../../mocks/mvi/mvi-mock.js --port 3000 | node_modules/.bin/bunyan -o short`
* `node mocks/jds/jds-mock.js --port 9080 | node_modules/.bin/bunyan -o short`
* `node pollerHost.js --site 9E7A --site C877 | node_modules/.bin/bunyan -o short`
* `node subscriberHost.js | node_modules/.bin/bunyan -o short`
* `node endpoints/writeback/writeback-endpoint.js --port 9090 | node_modules/.bin/bunyan -o short`

This is optional. It will add a __lot__ of traffic
* `node triggerPollerHost.js --site 9E7A --site C877 | node_modules/.bin/bunyan -o short`

This is not really used at the moment, it just stubs out the writeback endpoint
* `node endpoints/sync-request/sync-request-endpoint.js --port 8080 | node_modules/.bin/bunyan -o short`

There are several shell scripts that will start (and stop) these processes, which you can use if you find them more convenient. If you run the triggerPollerHost.js, messages will begin moving through the system, as the vista-mock.js will generate simulated appointment patients.

Start a Patient Sync
--------------------
Once everything is started, you can start a simulated synchronization by doing a `GET` to the following url [http://localhost:8080/sync/doLoad?pid=9E7A;3](http://localhost:8080/sync/doLoad?pid=9E7A;3). Note that you can pass a `pid` or an `icn` as the query parameter. Alternately, you can do a `POST` to the following url [http://localhost:8080/sync/load?pid=9E7A;3](http://localhost:8080/sync/load?pid=9E7A;3).

Run tests
=========

You can run the unit tests using `npm test`.

Development
===========
The rest of this document is to explain how to develop.

There are several concepts to ensure that you understand in order to execute development. Please ensure that you have working knowledge of the [design](http://bit.ly/vx-sync) prior to proceeding - the details are less important than the concept and the terms.

*Editorial comment*: it is possible for this document and the wiki based design to drift. My recommendation is to use the wiki based document for high level design and use this document for code level design of *how* to build handlers, write tests, and code level design goals.

* job: represents one unit of work. This is requested and scheduled by publishing a job request into a job repository and then executed by a job handler. An example of a job is "transform JMeadow to VPR".
* job handler: a job handler is the implementation that fulfills a job. An example is the "transform JMeadow to VPR handler" (which is responsible for taking a payload in JMeadows format and transforming to VPR format). A job handler implements a logic contract for accepting the job payload and returning, via callback, the result

The development of `vx-sync` consists of building cross-cutting concerns (maintaining infrastructure code, sync status, ability to reserve jobs, etc) and development of handlers. The development of handlers is expected to involve many developers, and thus this document will focus setting a process for how to develop a handler.

How to develop a handler
========================

General Guidelines
------------------
* Don't block. Make sure that the handler utilizes non-blocking I/O. Consider the use of `sync` [http://bit.ly/1st6NxU] to help manage serial / parallel asynchronous processing.

* Only one instance of a given handler is created. Thus, handlers shall have no "threading" concerns. The only state that should be stored in a handler are references to other stateless module

Anti-pattern:
```
self.currentPatient = job.payload.patient;
```

Acceptable pattern:
```
self.log = Logger.get('enterprise-sync-request-handler');
```

* All functions shall exist as part of the handler instance, not just in module space

* Be very careful with the use of `this`. It is recommended to set reference to `self` to avoid unexpected issues

Acceptable pattern:
```
var self = this;
self.log.info('sample handler received job request [%s]', JSON.stringify(payload));
```

Create module
-------------
Currently, all modules are created in the same git repository. Perhaps over time that we will change this to allow for handlers to exist in their own git repository, have their own build pipelines, publish to a npm repository, and be pulled in together at compilation time. But no yet..

Start by creating a module by creating a new directory `/product/production/vx-sync/handlers/<jobname>/`

Create a new file file in that directory `<jobname>-handler.js`.

For example, the handler for job `enterprise-sync-request` exists as: `/product/production/vx-sync/handlers/enterprise-sync-request/enterprise-sync-request-handler.js`.

Factory method
--------------
By contract the handler must implement a factory method as the exported module fucntion.

Within the handler, export a function that will return an instance of the handler. This function accepts two parameters.
`environment`: this contains reference to any subsystems needed by the handler as well as configuration
`publisherRouter`: this is an instance of a router that can be used to publish new jobs to other job repositories

A standard example is:
```
module.exports = function(environment, publisherRouter) {
    function SampleHandler(environment, publisherRouter) {
        var self = this;
        self.environment = environment;
        self.publisherRouter = publisherRouter;
    }

...

    return new SampleHandler(environment, publisherRouter);
};
```

Create a handler method
-----------------------
By contract, the handler object must implement a function that will be used to process job request. This function accepts two parameters:
`payload`: this is the payload portion of the job that was created by the producer. The format of this payload is specific to this job
`handlerCallback`: this is a callback method in the format of `f(err, result)`. `err` is any exception that occurred during the processing of this job. `result` specifies is this was successfully processed or not. See the response section of this document for more information. For convenience, if there is no error, the handler may invoke as `f(result)` - this is handled by the underlying job framework.

It is recommended to create the handler function as a prototype of the based object definition (although I suppose that it does not matter, since it is expected that only one instance of the object will be created).

Example:
```
    SampleHandler.prototype.handle = function(payload, handlerCallback) {
        var self = this;
        self.log.info('sample handler received job request [%s]', JSON.stringify(payload));
        handlerCallback('success');
    }
```

This handler method is the core entry point into processing. Have at it!

Logger
------
Every handler is likely to need to perform logging.

In the header part of the module, utilize the Logger to get an instance of a log, utilizing `handler` as the prototype.

Example (replace `sample-handler` with your handler name)
```
var log = require('../../jobframework/loggingFactory').get('sample-handler', 'handler');
```

*Jason's note*: I am split between two perspectives of logging. In general, there is no doubt that we need to achieve the following:
- while in development mode and possibly early day's of deployment, we need to have verbose logging to help troubleshoot
- while in mature deployment, to maximize runtime efficiency and size of logs, we need to favor logging that only reports issues that need to be addressed
- it is easy to fall into a mindset while you are developing a set of code (like a handler) that for that period of time the stuff is significant to you, and thus the shift the logging to a high level than it should be. That is, something that is actually debug/trace quickly becomes info. Warns become error. Error becomes fatal. Need to provide guidelines to prevent this.

Two choices:
1) cap all handler logging to `debug`/`trace`. Because all exceptions (both through callback or uncaught exceptions) are raised to the vx-framework, these significant messages are logged by the framework. This gives us ability to leave `debug` (or even `trace`) output on while we are in dev / early deployment. When we are running at a stable mode, we would switch the logging configuration to only output at `info` and above.
2) Allow handlers to log at their own defined levels. Adjust the handler logging configuration indepedently of the standard logging configuration.

After typing this out, I am convinced that option #1 is the correct path.

Guidelines on logging levels for a handler:

`fatal`: should only be used to represent events that effect many jobs. This should not be used by a handler. This generally would be used by the framework if a situation occurs that results in the process shutting down (such as required external systems are not available)

`error`: should be used to represent that a job has a non-transient exception (such as malformed format). This should not be used by a handler. This should be used a maximum of ONCE from the framework during the processing of a job.

`warn`: should be used to represent that a job has a transient exception (such as a timeout while waiting for a response from MVI). This should be used a maximum of ONCE from the framework during the processing of a job.

`info`: use ONCE per message from job framework; information during startup. Not used from handlers.

`debug`, `trace`: any log messages that need to be used to troubleshoot a handler should be at debug and trace level. Consider debug should be enough for casual understanding, while trace is likely extermely verbose. Expect that during development it is acceptable for `trace` to be turned on, and that early deployment can be at `debug`.

Logging is through a component call `bunyan`. One of the interesting things with bunyan is that it actually logs as a json stream to file or stdout. This is great for later parsing the log file. This is hard from a human readable perspective. Luckily there is a utility (`node_modules/.bin/bunyan`) that can put into an easy to read format.

To use this, generally when running a process, pipe the output to this utility. The startup scripts do this as shown in the run-worker.sh script:
```
node host.js "$@" | node_modules/.bin/bunyan
```

Response
--------
During the course of processing a job, the job handler will yield one of the following logical conclusions:
* the job was successfully processed (lets label this as success)
* the job was not able to be completely processed because of a potentially temporary situation with the expectation that a retry at some future point in time may result in success. This could be a result as of an external system not available (lets label this as transient exception)
* the job was not able to be completely processed, and it is not expected that retrying later will yield a different (lets label this as fatal exception)

In the case of success, perform the following at the conclusion of processing:
```
handlerCallback('success');
```

In the case of transient exception, perform the following at the conclusion of processing (where `err` is either the actual exception that was caught that represents the issue OR *preferably* a string/object to represent the situation):
```
handlerCallback(err, 'transient-exception');
```

In the case of fatal exception, perform the following at the conclusion of processing (where `err` is either the actual exception that was caught that represents the issue OR *preferably* a string/object to represent the situation):
```
handlerCallback(err, 'fatal-exception');
```

The framework will catch an uncaught exception and treat as fatal-exception. Do not rely upon this.

The framework also understands other status (`exception`, `release`, `bury`), do not use these. Likely will be dropped.

Running Tests
=============
For the development of `vx-sync`, we will rely upon different levels of testing to achieve different balances of timeliness (how quick can the developer get feedback), fidelity (how much is this test reflective of the way that it will actually be used in production / how much can you trust the test), and permanency (tests that assert the requirements at a stable API contract have high permanency compared with tests that represent developer intent at low level class level and are obsoleted by refactoring the implementation).

To this, I expect the following type of tests:
- *VX acceptance tests*: this asserts that the overal behavior of the system while utilizing the integration of the application, resource server, and `vx-sync` subsystem. It is expect that there are only a minimal number of tests at this level as they have a high expense (high timeliness). These are defined in gherkin and implement in cucumber with ruby.
- *`vx-sync` accceptance tests*: this assert that synchronization behavior executes as intended, exercising the sync API and asserting state in `VX-Cache` with test instances of VistA and mocked instances of systems like MVI (these should be actual running instances that use the same technology / interfaces). It is expected that there many of these to cover top level concerns of `vx-sync`. It is not expected that these *must* be run by a handler developer prior to check-in. (Subject to change if handler development is routinely breaking the acceptance builds). These are defined in gherkin and implement in cucumber with ruby.
- *handler integration tests*: this asserts that a handler, when executed in the context of running through the vx framework worker host and connecting to job repository (beanstalkd) runs as expected (including properly creating other jobs and making network calls to mock instances of external systems). It is expected that each handler has a few integration tests. These need to be executed locally during pre-commit activities. It is expected that these are defined in gherkin and implement in cucumber with ruby (but could be through Jasmine, but probably not a good idea). Unless contract for a handler change (such as different format for the input or aggregation/decomposition of handlers in the design), this should be very stable definition of the tests themselves (high permancy).
- *handler unit test tests*: this asserts developer intent for a handler. These need to be FAST. The full suite of all unit tests should run in the matter of a few seconds. These utilize fake job framework, and thus do not require network calls, no interaction with beanstalkd, etc. It is expected that each handler have many unit tests to cover different scenarios. These tests should be run not only during pre-commit, but constantly throughout the development of the handler. It is expected that these test are written in `jasmine-node`.

To run all unit test
--------------------
You can run this using `node_modules/jasmine-node/bin/jasmine-node tests/unittests/ --matchall --color --verbose`. For short, I added an npm shortcut which you can run as: `npm test`
TODO: This should be wrapped with a gradle command.

To write handler unit tests
---------------------------
For an intro into jasmine, see here: http://jasmine.github.io/2.0/introduction.html
TODO: explain how to use HandlerTestRunner
TODO: explain how we need to expand the expection checker for HandlerTestRunner

Other testing concerns
----------------------
TODO: setup common code and patterns for handler acceptance tests (in gherkin and ruby), including spinning up beanstalk, starting specific worker, how to publish test messsage, wait for worker to run, then check downstream effects such as JDS or other job repositories.

TOOD: allow developer to run acceptance / unit tests for their handler rather than all tests

TODO: setup common code and patterns for `vx-sync` acceptance tests

TODO: consider the impact that `vx-sync` will have on system wide acceptance tests - not all data is immediately available. This is by its very nature not deterministic. How should this evolve?

Beanstalkd Protocol
===================
It is helpful to understand the beanstalkd protocol:
[https://wiki.vistacore.us/download/attachments/4720934/BeanStalk-protocol-abridged.pdf?api=v2]. As it relates to the workflow of the handlers.

* Through the use of the publisher, either from the web service API or through other handlers, performs a `put`
* The worker (part of the vx job framework) performs a `reserve` and then delegates the job to the correct handler instance
* The handler response with `success`, `transient-exception`, or `fatal-exception`.
* On `success`, the worker performs a `delete` to remove the job from the job repository
* On `transient-exception`, the worker performs a `release with delay` to schedule the job to be worked on in the future
* On `fatal-exception`, the worker performs a `bury`

Note: it is expected to utilize TTR to ensure that jobs to not get assigned to a handler, the handler crashes, and that the job never is released. So far this seems to be handled without using TTR, but we will implement TTR for safety.


text:
# Forensics Challenges

## Santa's letter
> It seems that Santa may have used some Invisible Ink to write this letter... he is surely playing Hide&Seek.

[File](challenge.png)

Google for ```Invisible Ink Hide and Seek Stego```

[Digital Invisible Ink Toolkit](http://diit.sourceforge.net/howtos.html)

![](https://i.imgur.com/ymlIlLf.png)

Flag: ```X-MAS{NOBODY:_SANTA:Hyvää joulua!}```

repository: QzSG/CTF-Write-Ups

path: /X-MAS CTF/2019/Forensics/Forensics.md

repo_name: QzSG/CTF-Write-Ups


text:
---
title: Design Principles for Windows Store apps
author: Microsoft
overview: |

link: https://docs.microsoft.com/en-us/windows/uwp/design/basics/design-and-ui-intro
principles:
- principle: Pride in craftsmanship
  summary: |
    Engineer the experience to be complete, thorough, and polished at every stage. Devote time and energy to small things that are seen often by many of your users.

    Sweat the details.
    Make using apps safe and reliable.
    Use balance, symmetry, and hierarchy.
    Align your app layout to the grid, the new layout for apps.
    Make your app accessible to the widest possible audience, including people who have impairments or  disabilities.
- principle: Be fast and fluid
  summary: |
    Let people interact directly with content. Respond to actions quickly with matching energy. Bring life to the experience by creating a sense of continuity and telling a story through meaningful use of motion.

    Be responsive to user interaction and ready for the next interaction.
    Design for touch and direct interaction.
    Delight your users with motion.
    Smoothly connect to what comes before and after.
- principle: Authentically digital
  summary: |
    Exemplify the capabilities of hardware and software. Take full advantage of the digital medium. Remove physical boundaries to create experiences that are more efficient and effortless than reality. Being authentically digital means embracing the fact that apps are pixels on a screen. It means designing with colors and images that go beyond the limits of the real world.

    Be dynamic and alive with communication.
    Use typography beautifully.
    Use bold, vibrant colors.
    Connect to the cloud so that your users can stay connected to each other.
- principle: Do more with less
  summary: |
    You can do more with less by reducing your design to its essence. Create a clean and purposeful experience by leaving only the most relevant elements on screen so people can be immersed in the content.
    Be great at something instead of mediocre at lots of things.

    Put content before chrome.
    Be visually focused and direct, letting people get immersed in what they love, and they will explore the rest.
    Inspire confidence in users.
    Reduce redundancy in your UI.
- principle: Win as one
  summary: |
    Work with other apps, devices, and the system to complete scenarios for people. For example, let people get content from one app and share it with another. Take advantage of what people already know, like standard touch gestures and charms, to provide a sense of familiarity, control, and confidence.

    Use the UI model.
    Work with other apps to complete scenarios by participating in app contracts.
    Use our tools and templates to promote consistency.
tags: [specific, organisations]
---

gha_language: SCSS


text:
# Orca Ray Pong example

We demonstrate how to easily run [pong](https://gist.github.com/karpathy/a4166c7fe253700972fcbc77e4ea32c5) example
provided by [Ray](https://github.com/ray-project/ray) using BigDL API. See [here](https://bigdl.readthedocs.io/en/latest/doc/Ray/Overview/ray.html) for more details for RayOnSpark support in BigDL.

## Prepare environments
We recommend you to use [Anaconda](https://www.anaconda.com/distribution/#linux) to prepare the environments, especially if you want to run on a yarn cluster(yarn-client mode only).
```
conda create -n bigdl python=3.7 #bigdl is conda enviroment name, you can set another name you like.
conda activate bigdl
pip install gym gym[atari]
pip install bigdl-orca[ray]
```

## Run example
You can run this example on local mode and yarn client mode.

- Run with Spark Local mode:
```bash
python rl_pong.py
```

- Run with Yarn Client mode:
```bash
python rl_pong.py --cluster_mode yarn
```

In above commands
* `--cluster_mode` The mode of spark cluster, supporting local and yarn. Default is "local".
- `--object_store_memory`The store memory you need to use on local. Default is 4g.
- `--driver_cores` The number of driver's or local's cpu cores you want to use. Default is 8.
- `--iterations` The number of iterations to train the model. Default is -1, training will not terminate.
- `--batch_size` The number of roll-outs to do per batch. Default is 10.

**Options for yarn only**
- `--slave_num` The number of slave nodes you want to to use. Default is 2.
- `--executor_cores` The number of slave(executor)'s cpu cores you want to use. Default is 8.
- `--executor_memory` The size of slave(executor)'s memory you want to use. Default is 10g.
- `--driver_memory` The size of driver's memory you want to use. Default is 2g
- `--extra_executor_memory_for_ray` The size of slave(executor)'s extra memory to store data. Default is 20g.

## Results
You can find the logs for training:
```
Batch 3 computed 10 rollouts in 3.907017707824707 seconds, running mean is -20.851752130222128
```

repository: intel-analytics/BigDL

gha_language: Jupyter Notebook

repo_name: intel-analytics/BigDL


text:
## Synopsis

This is the top-level element-documentation of the code that accompanies the numerical section of the article  [Costly Consideration and Dynamic Choice Set Formation](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3423876)  (henceforth the article).

The code implements a simple version of the radial attention model and solves it. For more details on the model's technicalities see the [article](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3423876). The solver is based on a concurrent re-formulation of the value function iteration algorithm. Further, it uses an adaptive search grid implementation to provide more accurate optimal control approximations.

If you use this software, please consider citing it. The permanent link of the software's release version is [![DOI](https://zenodo.org/badge/doi/10.5281/zenodo.3353648.png)](https://zenodo.org/badge/latestdoi/199311654). Suggested citations can be found at this link.

## Installation

The source code of the project can be found at this [repository](https://github.com/pi-kappa-devel/rad). The easiest way to build the C applications of the project is to use [CMAKE](https://cmake.org/). The following macros can be passed to CMAKE :
 - If you want to build with debug symbols and warnings use `CMAKE_BUILD_TYPE=Debug`.
 - If you want to build fully optimized for execution speed use `CMAKE_BUILD_TYPE=Release`.
 - If you want to have bound checking for the grids, set `GRID_T_SAFE_MODE=1`.
 - If you want the parameter maps to check if the passing keys exist, set `PMAP_T_SAFE_MODE=1`.
 - Lastly, if you want the compilation to include debugging development functionality use `RAD_DEBUG=1`.

CMAKE produces four targets; three executables and one documentation target. The last one gives this documentation. The executable targets are
 - `rad_msol`  : Solves the radial attention model based on the saved parameterization file.
 - `rad_mcont` : Resumes the solution of the model that is halted in a previous execution. This is useful when you are using the code in environments with execution-time limits such as in clusters.
 - `rad_pardep`: Produces the data for the parameter dependence analysis.

The C code was compiled and tested using
 - gcc version 10.2.1 20201125 (Red Hat 10.2.1-9) (GCC)
 - Microsoft (R) C/C++ Optimizing Compiler Version 19.16.27025.1 for x64

The Python code was tested using
 - Python 3.8.6

## Functionality

The C code is used to approximate the solutions of the radial attention model. It also stores the solution and parameter analysis' binary data in the file system. The Python code is used to create model logic level objects from the stored binary data. The python code is using the resulting data to produce the tables and the figures of the [article](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3423876). An org document, exported in Html format [here](https://rad.pikappa.eu/rad.html), summarizes the main results of the execution.

## Concurrency

The concurrency is written on an operating system level using low-level abstractions (i.e. mutexes and locks). In UNIX based systems it is written using the POSIX Threads API [pthreads](http://www.cs.wm.edu/wmpthreads.html). In windows systems it uses the native windows  [threading](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/) and [synchronization](https://docs.microsoft.com/en-us/windows/win32/api/synchapi/) APIs.

## Documentation

The documentation of the project can be found online [here](https://rad.pikappa.eu/index.html) and it is also available for [downloading](https://rad.pikappa.eu/refman.pdf) in a PDF format. It is built using [DOXYGEN](http://www.doxygen.nl/) and follows the `repeat your-self documentation approach´.

Only the top-element functionality of the C code is documented. Drilling into lower-level functions requires that you have an understanding of the radial attention model. Knowledge of the standard value function iteration algorithm is another prerequisite. For the parallelization, basic knowledge of system multithreading implementations and the pipeline parallelization pattern is required. There are also some accompanying implementation comments in the source code that is not reported in this documentation.

The Python code is simple and its elements are briefly documented.

## Contributors

Pantelis Karapanagiotis

Feel free to join, share, contribute, distribute.

## License

The code is distributed under the MIT License. See the [LICENSE](https://rad.pikappa.eu/LICENSE.txt) file.

repository: pi-kappa-devel/rad

repo_name: pi-kappa-devel/rad


text:
# Current Release Managers

## 1.16

* [Daniel Hawton](https://github.com/dhawton)
* [Ziyang Xiao](https://github.com/ZiyangXiao)
* [Mariam John](https://github.com/johnma14)

## 1.15

* [Sam Naser](https://github.com/Monkeyanator)
* [Daniel Hawton](https://github.com/dhawton)
* [Ziyang Xiao](https://github.com/ZiyangXiao)

## 1.14

* [Greg Hanson](https://github.com/GregHanson)
* [Lei Tang](https://github.com/lei-tang)

## 1.13

* [Steven Landow](https://github.com/stevenctl)
* [Lei Tang](https://github.com/lei-tang)

# Emeritus Members

We would like to acknowledge previous release managers for their contribution to
the success of the Istio community:

## 1.12

* [Kenan O'Neal](https://github.com/jacob-delgado)
* [Daniel Grim](https://github.com/dgn)

## 1.11

* [Jonh Wendell](https://github.com/jwendell)
* [Ryan King](https://github.com/ryantking)
* [Steve Zhang](https://github.com/zhlsunshine)

## 1.10

* [Sam Naser](https://github.com/Monkeyanator)
* [Zhihan Zhang](https://github.com/ZhiHanZ)

## 1.9

* [Jacob Delgado](https://github.com/jacob-delgado)
* [Shamsher Ansari](https://github.com/shamsher31)
* [Steven Landow](https://github.com/stevenctl)
## 1.8

* [Pengyuan Bian](https://github.com/bianpengyuan)
* [Greg Hanson](https://github.com/GregHanson)

## 1.7

* [Cynthia Coan](https://github.com/Mythra)
* [Jimmy Chen](https://github.com/JimmyCYJ)
* [Jonh Wendell](https://github.com/jwendell)

## 1.6

* [Jacob Delgado](https://github.com/jacob-delgado)
* [Iris Ding](https://github.com/irisdingbj)
* [Brian Avery](https://github.com/brian-avery)

## 1.5

* [Daniel Grimm](https://github.com/dgn)
* [Francois Pesce](https://github.com/fpesce)
* [Eric Van Norman](https://github.com/ericvn)
* [Mariam John](https://github.com/johnma14)

## 1.4

* [Jonh Wendell](https://github.com/jwendell)
* [John Howard](https://github.com/howardjohn)
* [Eric Van Norman](https://github.com/ericvn)

## 1.3

* [Steve Dake](https://github.com/sdake)
* [Brian Avery](https://github.com/brian-avery)
* [Romain Lenglet](https://github.com/rlenglet)

## 1.2

* [Francois Pesce](https://github.com/fpesce)
* [Lin Sun](https://github.com/linsun)

## 1.1

* [Josh Blatt](https://github.com/duderino)

repository: istio/community

gha_language: Go

repo_name: istio/community


text:
---
title: How to use SAP Fundamentals SCSS with Angular
keywords: how to use scss
sidebar: left-navigation-sidebar
toc: false
permalink: resources/how-to-use-scss.html
folder: resources
summary: The following step-by-step guide will covers how to install SAP Fundamentals in your angular project, import SCSS in your workflow and explain some built-in functions.
---

## Table of contents
{:.docs-header-h2}
1. [Prerequisites and Requirements](#prerequisites-and-requirements)
1. [Configuring Angular Project to use SCSS](#configuring-angular-project-to-use-scss)
1. [Installing SAP Fundamentals via NPM](#installing-fiori-fundamentals-via-npm)
1. [Configuring and Importing SCSS source](#configuring-and-importing-scss-source)
1. [Selective Imports](#selective-imports)
1. [Core Functions and Mixins](#core-functions-and-mixins)

## Prerequisites and Requirements
{:.docs-header-h2}

- Familiarity using terminal or command prompt
- This guides assumes that the initial setup was done using [Angular 4](https://angular.io/){:target="_blank"} or higher and initial setup was doing using [Angular CLI](https://cli.angular.io/){:target="_blank"}
- [NPM](https://www.npmjs.com/){:target="_blank"} is installed globally

## Configuring Angular Project to use SCSS
{:.docs-header-h2}

Angular CLI does not configure the project to process SCSS files by default. Instead it is set to a CSS file located at the root of `src` folder. We recommend that you use keep all your SCSS files in one place under `src/scss/`.

To set the angular project to use SCSS:

1. Type `ng set defaults.styleExt scss` in command prompt or terminal at project root.

2. Open `.angular-cli.json` located at the project root and change the styles configuration to `"styles": [ "scss/app.scss"]`

3. Verify that the `styleExt` is set to `scss`

4. Create a folder named `scss` under the `src` folder and a also create the main SCSS file named `app.scss`

5. Remove the src/styles.css file. It will not be used.

The Basic SCSS configuration is now complete.

## Installing SAP Fundamentals via NPM
{:.docs-header-h2}

SAP Fundamentals is currently available as an [NPM package](https://www.npmjs.com/package/fiori-fundamentals){:target="_blank"} and a compiled and minified [CDN file](https://unpkg.com/fiori-fundamentals@latest/dist/fiori-fundamentals.min.css){:target="_blank"}. The following steps will cover how to install it via NPM.

1. Type `npm install fiori-fundamentals --save-dev`. This will install the package as a dev dependency.
2. Verify the installation was successful by typing `npm list fiori-fundamentals`

SAP Fundamentals installation is now complete

## Configuring and Importing SCSS source
{:.docs-header-h2}

1. Open `scss/app.scss` file
2. Add the following line of code to define the icons path:

 `$fd-icons-path: "~fiori-fundamentals/scss/icons/";`
3. Add the following line of code to define the fonts path:

 `$fd-fonts-path: "~fiori-fundamentals/scss/fonts/";`
4. Add the following line of code to import SCSS source file:

 `@import "~fiori-fundamentals/scss/all.scss";`

Importing SAP Fundamentals SCSS is now complete

> **Note:** In order to render the icons and fonts correctly, you need to define the `$fd-icons-path` and `$fd-fonts-path` variables.

At this point, the contents of your `scss/app.scss` should look like this:

{% highlight css %}

$fd-icons-path: "~fiori-fundamentals/scss/icons/";
$fd-fonts-path: "~fiori-fundamentals/scss/fonts/";
@import "~fiori-fundamentals/scss/all.scss";

{% endhighlight %}

You can continue to build out your SCSS workflow based on your project needs.

## Selective Imports
{:.docs-header-h2}

SAP Fundamentals is divided into several functional pieces. You may choose to import key features selectively to reduce the SCSS overhead in your project.

Here is an overview of the SCSS structure -

{% highlight css %}
scss/
 |- components/
 |- core/
 |- helpers/
 |- icons/
 |- layout/
 |- theme/
 all.scss
 components.scss
 core.scss
 helpers.scss
 icons.scss
 layout.scss
{% endhighlight %}

- `all.scss`: Includes all components.
- `components.scss`: SCSS source for each components. The components are decoupled  with little or no dependency on other components.
- `core.scss`: The main purpose of core is elements and forms. It's like the reset and foundation.
- `helpers.scss`: Includes various helper functions.
- `icons.scss`: SAP Fundamentals's custom icon library.
- `/theme/fundamental.scss`: Includes fonts.
- `layout.scss`: App level layout components such as top Overview of Core features bar, side nav, containers, panels, etc.

You can choose to selectively import parts of the library that best fits the need of your project. Please note that components, icons, layout and helpers have a dependency on `settings.scss`. Therefore, `settings.scss` should always be included in case if you are not importing `all.scss`. For fonts, make sure you are importing `theme/fundamental.scss`

For selective import your `app.scss` content should look like this:

{% highlight css %}
$fd-icons-path: "~fiori-fundamentals/scss/icons/";
@import "~fiori-fundamentals/scss/theme/fundamental";
@import "~fiori-fundamentals/scss/core";
@import "~fiori-fundamentals/scss/{feature}";

{% endhighlight %}

### Angular components
{:.docs-header-h3}

If you are writing angular components using SAP Fundamentals toolkit, you will need to import the following in your component's scss file:

{% highlight css %}
@import "~fiori-fundamentals/scss/core/settings";
@import "~fiori-fundamentals/scss/core/mixins";
@import "~fiori-fundamentals/scss/core/functions";
{% endhighlight %}

## Core Functions and Mixins
{:.docs-header-h2}

SAP Fundamentals comes with some very useful built-in functions and mixins to help maintain consistency and quality of your SCSS source files. We recommend that you utilize these functions instead of hard coding colors, spacing, fonts, etc. in your code to keep CSS low specificity. Utilizing functions also helps in retaining the integrity of the theming options and makes it easy to switch between different themes such as a high-contrast theme for accessibility or a brand specific theme.

> **Note:** In order to use the functions and mixins, please ensure that you are importing the functions SCSS files

> `@import "~fiori-fundamentals/scss/core/functions";`

> `@import "~fiori-fundamentals/scss/core/mixins";`

## Color Function
{:.docs-header-h3}

If you have a need to apply a color to any of your scss/css class, you can use the built-in color function -
 `fd-color(group, shade)`

{% highlight css %}
.foo {
  background-color: fd-color(neutral, 3); /* renders #ccdaeb */
  color: fd-color(text, 1); /* renders #21262c */
}
{% endhighlight %}

You can refer to the [colors page]({{site.baseurl}}/foundation/colors.html){:target="_blank"} for the complete list of the available color options.

## Spacing Function
{:.docs-header-h3}

```
fd-space("value")
```
The space function can be utilized for heights, padding, margins and other positioning.

The design system defines a variety of spacing increments that are commonly used throughout and [all of those are available](https://github.com/SAP/fundamental/blob/main/scss/_settings.scss#L18) using the mixin by passing the key. However, there are four units that will be used most often when building and extending components. These are accessible with special keys to apply consistent padding and margins.

{% highlight css %}
.foo {
  padding: fd-space("tiny"); /* renders 8px */
  margin-bottom: fd-space("small"); /* renders 24px */
}
{% endhighlight %}

The following spacing options are available -

{:.docs-table}
| Value           | Rendered Value |
|  --------------- | -------------- |
| `fd-space("tiny")` |  8px           |
|  `fd-space("small")`  |  16px          |
| `fd-space("medium")`   |  32px          |
| `fd-space("large")` |  48px          |

## Type Mixin
{:.docs-header-h3}

You can utilize the type mixin to render size, line height and weight -
 `fd-type($size, $weight)`

{% highlight css %}
.foo__header {
    @include fd-type("3", "bold"); /* renders the css below */
    /* font-size: 1.75rem; */
    /* line-height: 1.4; */
    /* font-weight: 700; */
}
{% endhighlight %}

{:.docs-table}
| Option      | Value                                          |
| ----------- |----------------------------------------------- |
| `size`      | `-1`, `0`, `1`, `2`, `3`, `4`, `5`, `6` |
| `weight`    | `light`, `normal`, `bold`                           |

repository: SAP/fundamental

gha_language: Nunjucks

repo_name: SAP/fundamental


text:
# rawrtc-terminal-demo

A browser terminal that uses WebRTC to punch through NATs.

![RAWRTC Terminal Demo Screenshot][screenshot]

The frontend uses the amazing [xterm.js][xterm-js].

## Introduction

This demo includes two tightly coupled applications and an optional signalling
server:

1. The [web terminal][web-terminal] which can be opened in any modern browser
   that supports WebRTC and WebRTC data channels. It represents a browser-based
   terminal GUI that needs to be used in combination with the
   RAWRTC terminal application.
2. The [RAWRTC terminal][rawrtc-terminal] application can be used to make a
   terminal (or any other program that reads from `stdin` and outputs data to
   `stdout`) accessible by using RAWRTC's data channel implementation. IO will
   be relayed from/to the web terminal frontend.
3. A very basic WebSocket signalling server written for Python 3.4+ which can
   be used instead of copy & pasting the signalling data from one peer to the
   other. Follow the [signalling server's readme][signalling-readme] for
   instructions on how to set up the server.

In the following sections, we will describe how to build the RAWRTC terminal
backend followed by [usage instructions](#usage) for the combination of the two
applications.

## Prerequisites

The following dependencies are required:

* [cmake][cmake] >= 3.2
* [RAWRTC][rawrtc]

### Meson (Alternative Build System)

~~If you want to use Meson instead of CMake, you have to install both the Meson
build system and Ninja.~~ Use CMake for now. Meson will be updated later.

* [meson][meson]
* [ninja][ninja]

## Build

The following instruction will use a custom *prefix* to avoid installing
the necessary dependencies and this library system-wide.

### Package Configuration Path

Make sure you have [set up the package configuration path][rawrtc-pkg-path] to
be able to find the RAWRTC library and its dependencies.

### Compile

#### Meson

    Will be added later. Use Cmake for now.

#### CMake

    cd <rawrtc-terminal-demo>/c
    mkdir build && cd build
    cmake -DCMAKE_INSTALL_PREFIX=${PWD}/prefix ..
    make install

## Run

Ensure you have [set up the library path][rawrtc-lib-path] (`LD_LIBRARY_PATH`
environment variable) to be able to find the RAWRTC shared library and its
dependency libraries. In addition, update the `PATH` environment variable
to find the newly built binary:

    export PATH=${PWD}/prefix/bin:${PATH}

Note: We assume that you are in the `build` directory.

Now you should be able to print usage information of the RAWRTC terminal
application by invoking

    rawrtc-terminal

which will output

    Usage: rawrtc-terminal <0|1 (ice-role)> [<sctp-port>] [<shell>] [<ws-url>]
                          [<ice-candidate-type> ...]

Below is a description for the various arguments:

#### ice-role

Determines the ICE role to be used by the ICE transport, where `0` means
*controlled* and `1` means *controlling*. For now, the web terminal will
always take the *controlling* role, thus you must use `0` for the RAWRTC
terminal application.

#### sctp-port

The port number the internal SCTP stack is supposed to use. Defaults to `5000`.

Note: It doesn't matter which port you choose unless you want to be able to
debug SCTP messages. In this case, it's easier to distinguish the peers by
their port numbers.

#### shell

The binary the data channel's incoming messages will be piped into (`stdin`) and
whose output (`stdout`) will be sent over the data channel to the other peer.
Defaults to `bash`.

#### ws-uri

If supplied and set to a valid WebSocket URI, the signalling server and the
WebSocket path supplied in the URI will be used to exchange signalling data.
The URI is split into three parts: `ws://<hostname-or-ip>/<channel>/<ice-role>`

* *hostname-or-ip*: The hostname or IP of the WebSocket server.
* *channel*: A channel name known to both peers. The server buffers and
  relays data on a channel from ICE role `0` to `1` and vice versa.
* *ice-role*: The chosen ICE role of the peer.

If not supplied or not a valid WebSocket URI, the copy & paste mode will be
used.

#### ice-candidate-type

If supplied, one or more specific ICE candidate types will be enabled and all
other ICE candidate types will be disabled. Can be one of the following
strings:

* *host*
* *srflx*
* *prflx*
* *relay*

Note that this has no effect on the gathering policy. The candidates will be
gathered but they will simply be ignored by the tool.

If not supplied, all ICE candidate types are enabled.

### Usage

Before we can go ahead, we need to choose between two modes:

* **Copy & Paste mode**: Signalling data will be exchanged using copy & paste.
  This is the default mode.
* **WebSocket mode**: In this mode, the various parameters will be exchanged
  using a simple WebSocket-based signalling server that relays data. The mode
  can be activated by supplying a valid WebSocket URI which has been explained
  in the [`ws-uri` argument description](#ws-uri).

1. Open the [web terminal][web-terminal] in a WebRTC data channel capable
   browser.
2. Start the RAWRTC terminal application.
3. Exchange the signalling data:
   * In **Copy & Paste mode**, copy the JSON blob after `Local Parameters:`
     from the RAWRTC terminal application into the web terminal. Copy the web
     terminal's JSON blob into the RAWRTC terminal application. Press *Enter*
     in the RAWRTC terminal application.
   * In **WebSocket mode**, supply the RAWRTC terminal's WebSocket URI as an
     argument when starting the application and paste the web terminal's
     WebSocket URI into the web terminal.
4. Done! Enjoy your WebRTC remote terminal.

[screenshot]: screenshot.png "RAWRTC Terminal Demo Screenshot"
[xterm-js]: https://github.com/sourcelair/xterm.js

[cmake]: https://cmake.org
[rawrtc]: https://github.com/rawrtc/rawrtc
[meson]: https://github.com/mesonbuild/meson
[ninja]: https://ninja-build.org

[web-terminal]: web/index.html
[rawrtc-terminal]: ./c/src/rawrtc-terminal.c
[signalling-readme]: ./signaling/Readme.md
[rawrtc-pkg-path]: https://github.com/rawrtc/rawrtc#package-configuration-path
[rawrtc-lib-path]: https://github.com/rawrtc/rawrtc#run

repository: rawrtc/rawrtc-terminal-demo

gha_language: C

repo_name: rawrtc/rawrtc-terminal-demo


text:
.. python_template documentation master file, created by
   You can adapt this file completely to your liking, but it should at least
   contain the root `toctree` directive.

Welcome to the Bellkor Algorithm documentation!
========================================================

Contents:

.. toctree::
   :maxdepth: 2

   intro
   changelog

.. toctree::
   :caption: Module Classes & Function Docstrings and Code
   :maxdepth: 2

   functions

.. toctree::
   :caption: Development & Contributing
   :maxdepth: 2

   development

Indices and tables
==================

* :ref:`genindex`
* :ref:`modindex`
* :ref:`search`

repository: TheXu/BellkorAlgorithm

repo_name: TheXu/BellkorAlgorithm


text:
# reactive-kafka-test
Small study project on [Apache Kafka](http://kafka.apache.org/) which is publish-subscribe messaging rethought as a distributed commit log. A good read is the book [Unified Log Processing by Alexander Dean](https://www.manning.com/books/unified-log-processing) and the ideas by [Martin Kleppmann's book: Designing Data-Intensive Applications](http://my.safaribooksonline.com/book/software-engineering-and-development/9781491903063), and has [some good talks on Youtube](https://www.youtube.com/channel/UClB4KPy5LkJj1t3SgYVtMOQ) so enjoy!

# Building and launching
This project builds `v<IP_ADDRESS>` of Kafka and uses Zookeeper `v3.4.5`. Just execute the `launch.sh` script and all will be build and launched.

# Hello World
The ["helloworld"](http://kafka.apache.org/documentation.html#quickstart_send) of zookeeper is the `console-producer` and `console-consumer` example, in which a producer places a message on the topic `test` and the consumer, consumes the message. In contrast to message brokers, the message will stay persisted after it has been processed by a consumer (the log concept) and will always be available to new consumers that start processing the topic `test` from `the beginning`.

# Youtube
- [Martin Kleppmann - Building real-time data products at LinkedIn with Apache Samza](https://www.youtube.com/watch?v=yO3SBU6vVKA)
- [Jay Kreps - Stream Processing with Apache Kafka](https://www.youtube.com/watch?v=Z9UrIm2Nc7s)
- [Jay Kreps - Apache Kafka and the Next 700 Stream Processing Systems](https://www.youtube.com/watch?v=9RMOc0SwRro)
- [Jay Kreps - I Love Logs: Apache Kafka and Real-Time Data Integration](https://www.youtube.com/watch?v=aJuo_bLSW6s)
- [Jay Kreps - Putting Apache Kafka to Use for Event Streams](https://www.youtube.com/watch?v=el-SqcZLZlI)
- [Joe Stein - Introduction to Apache Kafka](https://www.youtube.com/watch?v=qc33qMUvR7c)
- [Cody Koeninger - Exactly Once Streaming from Kafka](https://www.youtube.com/watch?v=fXnNEq1v3VA)

# Camel
- [Camel Kafka Component](http://camel.apache.org/kafka.html)

# more to come...
...

# resources
https://github.com/yahoo/kafka-manager

repository: dnvriend/reactive-kafka-test

repo_name: dnvriend/reactive-kafka-test


text:
# Fastly_Cdn Release Notes

## 1.2.20

- Add Historical bandwidth/request/error stats to the Magento Dashboard

## 1.2.19

- Redesign the edge dictionaries interface to use individual actions/calls when adding/removing entries instead
of bulk calls as bulk

## 1.2.18

- Add Edge Dictionaries management interface directly into the Magento Plugin admin

## 1.2.17

- Purge by content type and store was not working due to fallout from the multiple surrogate key purge bug.

## 1.2.16

- Fix for multiple surrogate key purges being incorrectly serialized

## 1.2.15

- Convert multiple single surrogate key purges to the new single multiple key purges request
- Migrate geo location variables to the new namespace
- Minor bug fixes and clean ups

## 1.2.14

- Fix multiple purges being sent for a single product/category change

## 1.2.13

- Webhooks code inadvertently broke ability to do setup and upgrades. This fixes it.

## 1.2.12

- Add ability to add WebHooks for purges and configuration changes

## 1.2.11

- Remove Download VCL button and custom VCL as it's deprecated
- Fix an issue with error/maintenance page where contents were not being escaped causing some elements to be invisible while editing
- Add usage statistics tracking

## 1.2.10

- Mark custom VCL separately

## 1.2.9

- Add new shield locations
- Error page fixes

## 1.2.7

- Add a UI to add a custom error/maintenance page

## 1.2.6

- Add a check to make sure user has saved config before attempting upload

## 1.2.5

- Add Backend Settings configuration - allows reconfiguration of existing backends
- Minor bug fixes

## 1.2.4

- Add Force TLS button in advanced settings - it enables/disables it in the Fastly service

## 1.2.3

- Fix VCL if user has uploaded custom VCL and changed req.url

## 1.2.2

- Minor VCL optimizations

## 1.2.1

- Fix for VCL Snippet upload when no snippets exist

## 1.2.0

- Convert to using VCL snippets https://docs.fastly.com/guides/vcl-snippets/. This will provide for better maintainability since it breaks
down functionality into separate files instead of one large file. Also it avoids the need for having VCL upload functionality enabled
- Button to Test Credentials

## 1.0.9

- Updated etc/fastly.vcl to remove set-cookies on static content. Also to
cache static 404's for 5 minutes.

## 1.0.8

- Some styling changes to better match Magento's style

## 1.0.7

- bumped version.

## 1.0.6

- Corrected autoload typo.

## 1.0.5

- Corrected spelling mistake in README.
- Adjusted dependencies for 2.1 installation issue.

## 1.0.4

- Fixed compilation errors due to dependency declaration

## 1.0.3

- Fixed display of cache management.

## 1.0.2

- Added CLI command to generate VCL

## 1.0.1

- Updates to README.
- Adjustments from Marketplace review.
- Resolved Geo-IP ESI tag being added when Geo-IP function is disabled.
- Adjusted cache headers for caching of Geo-IP response

## 1.0.0

- Changed module name for marketplace review

## 0.9.0

Initial release for testing.


text:
---
title : DAYS 17 & 18 - Detour via React
subtitle : A note on Semantic UI (React Version)
slug : day-18
date : 2020-01-18
author : Lucie B
---

So I am taking a detour via React (create-react-app), but since Gatsby is built on React I’m counting it as part of the [#100DaysofGatsby](https://twitter.com/hashtag/100DaysofGatsby) challenge.

This React project, is a discussion for another day but in this project, I’m also working with [Semantic UI](https://react.semantic-ui.com/), which happens to be quite different to what I’m used to but surprisingly nice to work with, at least in the context of React and the project I am building.

## Semantic UI (React)

[Semantic UI](https://react.semantic-ui.com/) is known as a minimalist UI component framework for theming websites and web applications. There are two versions: the standard one which uses jQuery and the React version (which I link to in this post), which is jQuery free.
The reason for the 2 versions being that jQuery is a DOM manipulation library but React uses a virtual DOM, so using the ‘standard’ version within react isn’t feasible.

For someone who’s really fussy on styling and spend more time than required on details, I think this could be a good option. From what I’ve seen so far, and what I've had to look up, the documentation is good and provides ‘out-of-the-box’ solutions to most questions. It has very cool features such as 'segments' and 'containers' that just work and look good.

I am aware that Semantic UI is a ‘one-man-show’, which hasn’t been active for a while and that there is an upcoming Fomantic UI (a community fork of Semantic-UI) gaining popularity. In addition to that there are other options. Having said that, I can only base my judgement on my limited use of Semantic UI, and so far it works very well.

## Semantic UI & Gatsby

Gatsby docs are great.. really! they are. There is, however, no mention of Semantic UI. So in the next few days, I’ll make an attempt at using semantic UI on a Gatsby site and see if that works; there is no reason why it shouldn’t. If all goes well, I’ll put together a short tutorial page on how to do so.

#### Till tomorrow, Happy coding!


text:
Upgrade Guide
=============
1.x.x -> 2.0.0
-----------------
### Jwt plugin exports a class
Before you did `client.addPlugin(jwtPlugin)` now you should do `client.addPlugin(new jwtPlugin())`

### Default timeout is 10 seconds
If you're doing long running requests they might fail unless you set a higher timeout than the default

### Plugins are async
plugin functions (like onStart) are called with await now, so they can be async functions

Pre-1.0.0 -> 1.0.0
------------------

### Default array syntax in query strings changed

If you were relying on arrays in query strings to use bracket syntax (e.g. `foo[]=bar&foo[]=baz`),
you need to pass `bracketStyleArrays: true` to the Client constructor.

repository: synapsestudios/fetch-client

repo_name: synapsestudios/fetch-client


text:
# Documentation

## Scenarios

The included AMIs built with this default repository consist of:

- Broken Nginx
- Broken Apache
- Broken Python Web App
- Broken Ruby Web App
- Broken Bash Script

### Broken Apache

This scenario is intended to provide a candidate with the opportunity to demonstrate their familiarity with Systemd, Apache and a basic web application.  They must determine why the web application is not operational, drilling down into why a service works.  Once a candidate has been able to resolve the first few issues, they must then determine why the web application isn't appearing externally.

### Broken Python Web App

This scenario is intended to provide a candidate with the opportunity to demonstrate their familiarity with Python tooling.

### Broken Ruby Web App

This scenario is intended to provide a candidate with the opportunity to demonstrate their familiarity with Ruby tooling.

## Solutions

Explanations of the tests are located in the Solutions directory.

repository: troyfontaine/vsc-remote-skills-test

gha_language: HCL

repo_name: troyfontaine/vsc-remote-skills-test


text:
---
layout: page
title: Lean Prover Zulip Chat Archive
permalink: archive/113488general/02748Idontunderstandheq.html
---

## [general](index.html)
### [I don't understand heq](02748Idontunderstandheq.html)

#### [Kevin Buzzard (Apr 14 2018 at 12:01)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125071940):
Here's a self-contained extract from `analysis/topology/topological.space_lean`:

#### [Kevin Buzzard (Apr 14 2018 at 12:02)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125071981):
```lean
import analysis.topology.topological_space
open topological_space
universes u v w
variables {α : Type u} {β : Type v} {ι : Sort w} {a a₁ a₂ : α} {s s₁ s₂ : set α} {p p₁ p₂ : α → Prop}
variables [topological_space α]

lemma is_open_Union_orig {f : ι → set α} (h : ∀i, is_open (f i)) : is_open (⋃i, f i) :=
is_open_sUnion $ assume t ⟨i, (heq : t = f i)⟩, heq.symm ▸ h i

lemma is_open_Union' {f : ι → set α} (h : ∀i, is_open (f i)) : is_open (⋃i, f i) :=
begin
  refine is_open_sUnion _,
  intro t,
  intro Ht,
  cases Ht with i Hi,
  exact eq.symm Hi ▸ h i,
end

lemma is_open_Union'' {f : ι → set α} (h : ∀i, is_open (f i)) : is_open (⋃i, f i) :=
is_open_sUnion $ assume t ⟨i, (rfl : t = f i)⟩, eq.symm ▸ h i -- doesn't compile
```

#### [Kevin Buzzard (Apr 14 2018 at 12:02)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125071983):
well, the first lemma is the extract -- it's called `is_open_Union` in the actual file.

#### [Kevin Buzzard (Apr 14 2018 at 12:03)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125071988):
I should perhaps say `lemma is_open_sUnion {s : set (set α)} (h : ∀t ∈ s, is_open t) : is_open (⋃₀ s)`

#### [Kevin Buzzard (Apr 14 2018 at 12:03)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125071992):
So I realised I didn't really understand the mathlib proof of `is_open_Union_orig` (which is the proof given in the extract above, with its `heq`)

#### [Kevin Buzzard (Apr 14 2018 at 12:04)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125072033):
so I proved the lemma "in the same way", in tactic mode

#### [Kevin Buzzard (Apr 14 2018 at 12:04)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125072034):
and that's `is_open_Union'`

#### [Kevin Buzzard (Apr 14 2018 at 12:04)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125072035):
and everything works fine with eq

#### [Kevin Buzzard (Apr 14 2018 at 12:05)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125072043):
Oh -- got it:

#### [Kevin Buzzard (Apr 14 2018 at 12:05)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125072045):
```lean
lemma is_open_Union'' {f : ι → set α} (h : ∀i, is_open (f i)) : is_open (⋃i, f i) :=
is_open_sUnion $ assume t ⟨i, (eq : t = f i)⟩, eq.symm ▸ h i
```

#### [Kevin Buzzard (Apr 14 2018 at 12:06)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125072085):
What's with this `heq` in the mathlib version?

#### [Kevin Buzzard (Apr 14 2018 at 12:08)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125072130):
Oh!

#### [Kevin Buzzard (Apr 14 2018 at 12:08)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125072131):
Got it :-)

#### [Kevin Buzzard (Apr 14 2018 at 12:08)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125072132):
`heq` has nothing to do with `heq`, it's just a variable name :-)

#### [Kevin Buzzard (Apr 14 2018 at 12:09)](https://leanprover.zulipchat.com/#narrow/stream/113488-general/topic/I%20don%27t%20understand%20heq/near/125072138):
Oh OK, so I do understand this particular use of heq, we're calling a variable by the same name as a Lean function :-)


text:
# Layout Guide

Chronograf's applications are built by layout configurations that can be found in the `canned` directory of the repository or the directory specified in with the `--canned-path` of the binary distribution. This document will cover how to create new layouts or modify existing ones to better fill your environment.

To create a new layout use the `new_apps.sh` script in the `canned` directory. This script takes an argument, which is the name of the layout you want, often this will map to the InfluxDB measurement, but it does not have to. For this example I will be creating a layout for the zombocom daemon zombocomd. So first step is the run `new_app.sh zombocomd` this will create a file called `zombocomd.json`. The file will look something like:

```json
{
  "id": "d77917f4-9305-4c9c-beba-c29bf17a0fd2",
  "measurement": "zombocomd",
  "app": "zombocomd",
  "cells": [
    {
      "x": 0,
      "y": 0,
      "w": 4,
      "h": 4,
      "i": "b75694f1-5764-4d1d-9d67-564455985894",
      "name": "Running Zombo Average",
      "type": "line-plus-single-stat",
      "queries": [
        {
          "query": "SELECT mean(\"zombo\") FROM zombocomd",
          "db": "telegraf",
          "rp": "",
          "groupbys": [
            "\"pod\""
          ],
        }
      ]
    },
    {
      "x": 0,
      "y": 0,
      "w": 4,
      "h": 4,
      "i": "7a6bc880-054e-455c-becd-c0ebbbe109ce",
      "name": "Anythings Per Second",
      "queries": [
        {
          "query": "SELECT non_negative_derivative(max(\"anything\"), 1s) FROM zombocomd",
          "db": "telegraf",
          "rp": "",
          "label": "anything/s",
          "range": {
            "upper": 100,
            "lower": 10
          },
          "wheres": ["\"status\" = 'critical'"]
        }
      ]
    }
  ]
}
```

The meaning of the fields are as follows:
* id - A unique identifier for this file. Because apps can have more than one file, this needs to be unique or your layout will not show up.
* measurement - The name of the [measurement](https://docs.influxdata.com/influxdb/v1.1/concepts/glossary/#measurement) to search. This is used to indicate to chronograf whether the application should be listed for a host.
* app - The name of the application, this does not need to be unique. All layouts for an app will be displayed when the layout is requested.
* cell - An array of graphs
* type - The layout visualization type. All layouts default to `line` if a type is not specified. Current visualization types include:
  - `single-stat` (use `last()` in your query to optimize performance)
  - `line`
  - `line-plus-single-stat`
* x - Not currently used
* y - Not currently used
* w - The width of the graph, for the initial release set to 4 to make everything line up properly.
* h - The height of the graph, for the initial release set to 4 to make everything line up properly
* i - A unique ID for the graph
* name - The displayed name of the graph
* queries - An array of InfluxQL queries. Note: queries must use an aggregate function since chronograf adds a group by time function to keep the data points manageable.
* queries.[].db - The name of the database for the query
* queries.[].rp - The [retention policy](https://docs.influxdata.com/influxdb/v1.1/concepts/glossary/#retention-policy-rp) for the database
* queries.[].groupbys - An optional array of GROUP BY clauses to use on the query
* queries.[].wheres - An optional array of WHERE clauses to add to the query
* queries.[].label - Optional key specifying the user-facing name of the y-axes
* queries.[].range.upper - Optional key specifying the default upper bound of the y-axis
* queries.[].range.lower - Optional key specifying the default lower bound of the y-axis

The above example will create two graphs. The first graph will show the mean number of zombos created then group the zombos by pod and by time. It is important to note that all queries have a `GROUP BY` time(x) appended to them. In this case `x` is determined by the duration of the query. The second graph will show the number of the "anything" [field](https://docs.influxdata.com/influxdb/v1.1/concepts/glossary/#field) per second average.
For real world examples of when to use the `groupbys` see the docker examples and for `wheres` examples see the kubernetes examples in the `canned` directory.

repository: jimis/influxdb

repo_name: jimis/influxdb


text:
---
title: Python Lan Crawler
date: 2021-01-25T16:52:19.819Z
summary: Lan Crawler is a crawler and indexer to access shared files by SMB shares. It provides dynamic Web UI for searching files, media etc. and allow user to download them from single dashboard.
draft: false
featured: false
tags:
  - Python
  - Django
  - SQLite
external_link: "https://github.com/gh0st27/Lan_Crawler"
links:
- icon: github
  icon_pack: fab
  name: Follow
  url: https://github.com/gh0st27/Lan_Crawler
url_code: ""
url_pdf: ""
url_slides: ""
url_video: ""

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


text:
#React

* 참고문헌
  * https://thebook.io/080203/ch01/02/01/02-01/
  * [https://www.inflearn.com/course/react-%EC%83%9D%ED%99%9C%EC%BD%94%EB%94%A9/dashboard](https://www.inflearn.com/course/react-생활코딩/dashboard)


text:
## Restore original signal after sampling and quantization technique

#### Project Purpose
- To understand the process of sampling and quantization.
- To see how much the original signal and the restoration signal match.

#### Project Procedure
- Generate original signal
- Sampling
- Quantization
- Encoding
- Decoding
- Calculate average quantization noise power
- Signal restoring

#### Result

![result](https://user-images.githubusercontent.com/58179712/123029087-87a6e780-d41b-11eb-99a8-76ceafed8cac.PNG)


text:
# CMake Test Explorer for Visual Studio Code

Run your [CMake](https://cmake.org) tests using the [Test Explorer UI](https://marketplace.visualstudio.com/items?itemName=hbenl.vscode-test-explorer).

## Features

- Shows a Test Explorer in the Test view in VS Code's sidebar with all detected tests and suites and their state
- Shows a failed test's log when the test is selected in the explorer
- Forwards the console output from the test executable to a VS Code output channel

## Getting started

- Install the extension
- Open the Test view
- Run your tests using the ![Run](img/run.png) icon in the Test Explorer

## Configuration

| Property                           | Description                                                                                |
| ---------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `cmakeExplorer.buildDir`           | Location of the CMake build directory. Can be absolute or relative to the workspace. Defaults to empty, i.e. the workspace directory.                                                                                |
| `cmakeExplorer.buildConfig`        | Name of the CMake build configuration. Can be set to any standard or custom configuration name (e.g. `Default`, `Release`, `RelWithDebInfo`, `MinSizeRel` ). Case-insensitive. Defaults to empty, i.e. no specific configuration. |
| `cmakeExplorer.extraCtestLoadArgs` | Extra command-line arguments passed to CTest at load time. For example, `-R foo` will only load the tests containing the string `foo`. Defaults to empty.                                                                         |
| `cmakeExplorer.extraCtestRunArgs`  | Extra command-line arguments passed to CTest at run time. For example, `-V` will enable verbose output from tests. Defaults to empty.                                                                                |

repository: Derivitec/cmake-test-explorer

repo_name: Derivitec/cmake-test-explorer


text:
Metagist.org
============

Metagist is an attempt to leverage quality and transparency of composer
packages by collecting and providing quality-related information. It is meant to
be used in addition to Packagist.org.

Packages can be rated and reviewed github users - similar to th rating system of
popular app stores.

![screenshot](https://github.com/wuzzitor/metagist-server/raw/master/doc/screen.png "In-Dev Screenshot")

repository: Wuzzitor/metagist-server

repo_name: Wuzzitor/metagist-server


text:
# cloudify_library
This library uses the cloudify client to test some of the functions of cloudify manager (version 4.3.1)
This has been tested in Ubuntu 14.04 platform using python virtualenv 16.1.0

Please follow the below steps to test the library:

## Step1:

Install the virtual env, git, vim:
```
$sudo apt-get install python-virtualenv git vim -y
```

## Step2:
Create venv to test the cloudifyclient functionality:
```
$virtualenv cloudifyclient_venv
```

## Step3:
Activate the venv:
```
$source cloudifyclient_venv/bin/activate
$cd cloudifyclient_venv
```

## Step4:
Install the required python packages:
```
$pip install pip==9.0.1
$pip install prettytable
$pip install cloudify
$sudo pip install cloudify_rest_client
```
This installed cloudify-rest-client verion is 4.3.3. The list of all installed packages can be found [here](/pip_installed_packages.JPG)

## Step5:
Clone this cloudify_library repo
```
$git clone https://github.com/praveenemc/cloudify_library.git
$cd cloudify_library
```

## Step6:
Update the cloudify manager details in the **config.py** file.
Run the test code as below:
```
$python test_cfy_library.py > output_dec4.txt
```

The output file output_dec4.txt is shared here for reference and also the test_blueprint_uploaded_GUI_Dec4.JPG GUI screenshot :smile:


text:
# Merchello

Merchello is a highly configurable, open source eCommerce package for [Umbraco CMS](http://www.umbraco.com) v7 ONLY. However, this project is no longer actively developed.

If you are looking for an eCommerce solution for Umbraco v8 then I suggest you take a look at Vendr. You can follow them on Twitter here [@heyvendr](https://twitter.com/heyvendr) or signup on their website [getvendr.net](http://getvendr.net)

## Basic features

Merchello comes with the following core features, but it's also built so you can expand on it to your needs. Here's what you get right out of the box:

* Products with  options and variants
* Flat rate shipping provider (by weight or price) for a single warehouse that can be adjusted by country and region
* Cash, Paypal, Purchase & Braintree payment providers
* Both invoicing and orders, created with each purchase
* Multiple currencies
* Product Picker datatype for Umbraco that lets you connect your Merchello product with your Umbraco content.
* Extended Content on Products and Options (Similar to Nested Content) - Use existing Umbraco property editors on your products and options.
* Products & Sales Collections - Organise your products and sales efficiently
* Discounts
* Reports

## Downloading

Look on the releases tab

## Documentation / Website

Our documentation is a tad outdated, but it's all we have at the moment. We are always looking for help with the docs ;)

[https://merchello.readme.io/](https://merchello.readme.io/)

## Contribute

We would love and need your help. If you want to contribute to Merchello's core, the easiest way to get started is to fork the project on [GitHub](https://github.com/merchello/Merchello) and open src/Merchello.sln in Visual Studio.

The Merchello.Web.UI.Client project is where the backoffice JavaScript files are, and if you are looking to update anything in there. Make sure you run the grunt tasks after your have made your changes. Please see the ReadMe.md in the Merchello.Web.UI.Client project root for more information.

Once you are done, just build and run. The project comes with a local SQLCE database with the Bazaar starter kit. The login for the back office is

admin
1234

We're excited to see what you do!

## Please report bugs you find!

If you don't want to dip your fingers into the core, one of the best ways you can contribute to Merchello is by letting us know if something is going wrong. This feedback is very useful to us - we can't catch them all! To view existing issues or submit one of your own, visit [https://github.com/merchello/merchello/issues](https://github.com/merchello/merchello/issues).

repository: Merchello/Merchello

branch_name: refs/heads/merchello-dev

repo_name: Merchello/Merchello