text:
---
title: "Lifecycle"
date: 2019-03-13
draft: false
type: "page"

weight: 9
---

Most `hof app` commands are run from the application directory.
The following commands are used in the application lifecycle.

### Application Lifecycle

##### Deploy, Shutdown

```sh
hof app deploy
hof app shutdown
```

##### Moving code

```sh
hof app push
hof app pull
```

_Note, push and pull do_ __not__ _require the application to be deployed._

##### Updating to a new Studios version

```sh
hof app update "<version>"
```

##### Resetting the application

```sh
hof app reset
```

### Database Lifecycle

When you change the data model within your types
you will need to run a database migration.

_note this is not all changes, the following, and maybe some undocumented ones_

```yaml
type:
  owned: ...
  visibility: ...
  fields: ...
  relations: ...
```

##### Update the development database

While developing, you will be changing the
shape and relations of you data and models.
To make your development server match the
latest state you desire, run:

```
hof db reset
```

##### Create a checkpoint

When you are ready to update your production,
user facing server, you will create a checkpoing.
To create a checkpoint for your
This will create a new set of migrations
and move the "latest" to the current state.

```sh
hof db checkpoint
```

Now, when you reset, the database is reset to this point.
This will overwrite the database with the seed data
and should nly be sued in development.

_The checkpoint command will not effect your data.
It will only make the outstanding migrations
and create a new point where reset works from (in development)._

##### Completely reset the database

```sh
hof db reset --hard
```

__This will reset the tables, migration history,
and restore to the current desired state with seed data.__

#### Renaming fields and other design

Renaming fields and other design paths
often requires adding a "rename" field.

```yaml
  ...
  name: <old-name>
  rename: <new-name>
```

Then, do the app and database updates:

```sh
hof app push
hof db checkpiont
```

_(this gets harder with development, and the interaction or replication
with / for production. More notes and documentation needed)_

and then making then name
the new name.

```yaml
  ...
  name: <new-name>
```

and finally

```sh
hof app push
```

See the more advanced section
for further details.

#### Complex changes

Changing the type of a field, possibly with the name as well,
can create changes which would destroy existing data.
In these cases, it is often better to

1. create new field
1. migrate database
1. transform data
1. delete old field
1. migrate database

As we find more of these cases,
we will add extra configuration and transformations
to enable the process to become more smooth.

Please [reach out to us](/getting-help)
if you are engaging is any complex use-cases.

### Function Lifecycle

coming soon

repository: hofstadter-io/studios-docs

repo_name: hofstadter-io/studios-docs


text:
AVR
---
- spi
- attiny serial output and input (SoftwareSerial uses pin-change interrupts)
  check out: https://github.com/frank26080115/Arduino-UsiSerial-Library/
- updates for attiny84

MSP430
------
- document watchdog class

Changes to [cherry-pick](https://coderwall.com/p/sgpksw/git-cherry-pick-from-another-repository):
- ~~Fix examples [24f4da3](../../pull/1/commits/24f4da3da3708afffd84b18a1d0eae57e9efe090), [22a0c5e](../../pull/1/commits/22a0c5e7e95045155747080efe3635d3282b1631), [a00cdc6](../../pull/1/commits/a00cdc6fc1ee24cae271a7311230b0f440f8d6db)~~
- ~~Break header dependencies on Arduino.h [8bc5132](../../pull/1/commits/8bc51324a0a8600c6d9ac1b4640dca0f62cff15f), [c9826eb](../../pull/1/commits/c9826ebaf46e34b78b040b64785bccfb3ba6918c)~~
- Serial output for attiny84 (attiny85) [f76e69f](../../pull/1/commits/f76e69ffd1273028b8b831aa7603468d7f8a4fe5)
- ~~Reset WDT when enabling [0499c7a](../../pull/1/commits/0499c7abadb38f652cfb558203f3cfce84af30fc)~~
- Sleep and wake functions [9e34dda](../../pull/1/commits/9e34ddab7566d718a68a2f7b30f1cbf3192ddc96), [f53e65](../../pull/1/commits/bf53e651a071eaeaada8dfcc20f4c5533d0a0473), [27a7f34](../../pull/1/commits/27a7f3430aff0aec37fd08fb0d87d0e1e8d0a27b), [42b7317](../../pull/1/commits/42b731722ea856d91c36a9fae940b68708cdcd32). ~~(Note that some of these commits contain bug-fixes which should be merged separately.)~~
  - timer millisecond divisor (what about msp430?)
  - check differences between atmega328 timer and attiny84/5
  - platformio

license: MIT

repository: icaven/Interrupted

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: icaven/Interrupted


text:
2.25 - John Henry Thompson - Invent Your Future

[Yoga](../../../yoga.md) > [Patanjali's Yoga Sutras - A Comparison](../../patanjani.md) > [Book 2](../book-2.md) >

### 2.25

**तदभाबात्संयोगाभावो हानं तद्दृशेः कैवल्यम् ॥२५॥**
tad-abhābāt-saṁyoga-abhāvo hānaṁ taddṛśeḥ kaivalyam ||25||

[\[RS\] 2.25 When a lack of insight (avidya) disappears, this identification likewise disappears. Once this identification has completely disappeared, liberation (kaivalya) of the true self (drashtu) has occurred.](http://www.ashtangayoga.info/philosophy/yoga-sutra-patanjali/chapter-2/item/abhabat-sanyoga-abhavo-hanam-taddrisheh-kaivalyam/)

[\[JW\] 2.25 Since this \[non-sight\] does not exist, there is no correlation. This is the escape, the Isolation of the Seer.](http://books.google.com/books?id=YzFImjtOxUwC&pg=PA168&ci=128%2C823%2C780%2C53&source=bookclip)

[\[SS\]](http://www.amazon.com/Yoga-Sutras-Patanjali-Commentary-Satchidananda/dp/0932040381) 2.25 Without this ignorance, no such union occurs. This is the independence of the Seer.  \[p112\]

[\[EB\]](http://www.amazon.com/Yoga-Sutras-Patanjali-Translation-Commentary/dp/0865477361/ref=sr_1_1?ie=UTF8&s=books&qid=1250508322&sr=1-1) 2.25 By the removal of ignorance, conjunction is removed. This is the absolute freedom of the seer. \[p234\]

[<Page 2.24](224.md)  [Page 2.26>](226.md)

(**तद्**, tad) = whose
(**अभाव**, abhāva) = to overcome; to disappear
(**संयोग**, saṁyoga) = unity; bond; identification
(**हान**, hāna) = reliquish; cease
(**तत्**, tat) = that; which; whose
(**दृशेः**, dṛśeḥ) = the seer
(**कैवल्यम्**, kaivalyam) = liberation; redemption

gha_language: HTML

gha_license_id: MIT


text:
---
layout: default
---

# 1998-01-11 - Re: rant on the morality of confidentiality (fwd)

## Header Data

From<EMAIL_ADDRESS>(Dr.Dimitri Vulis KOTM)

To<EMAIL_ADDRESS>Message Hash: 0033baf7ae99814fcf445cbcd3113bff7f3eadc7a5807fcfe3289ef9bbf7cf17

Message ID<EMAIL_ADDRESS>Reply To<EMAIL_ADDRESS>UTC Datetime: 1998-01-11 05:39:31 UTC

Raw Date: Sun, 11 Jan 1998 13:39:31 +0800

## Raw message

```
{% raw  %}From<EMAIL_ADDRESS>(Dr.Dimitri Vulis KOTM)
Date: Sun, 11 Jan 1998 13:39:31 +0800
To<EMAIL_ADDRESS>Subject: Re: rant on the morality of confidentiality (fwd)
In-Reply-To<EMAIL_ADDRESS>Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

Jim Choate<EMAIL_ADDRESS>writes:

> > 1)  secrecy
>
> If you don't know something you either can't take advantage of it or else
> you have to rediscover it on your own. It is clear that if everyone had to
> re-invent the wheel at every step then not much would get done.

If you come up with a mathematical result that can be useful in finance,
you can sometimes make very substantial money either trading for yourself
or selling your result to others who trade. obviously if you publish it
in the open lierature, you can no longer do this.

Folks who work for the NSA and its foreign counterparts generally don't
publish anything, even stuff that would be totally useless to the enemies.

> > 2)  responsibility for publishing
>
> Nobody has a responsbility to publish. Science is a completely voluntary
> pursuit. I would contend personaly that if you don't publish you arent'
> doing science but rather mental masturbation (a rather selfish pursuit I
> suspect).

There have been scientists most of whose work was published after their deaths.
There probably have been scientists whose notes were lost after their deaths,
so we don't know who they were. There have been great writers most of whose
works were discovered and published after their deaths, and are still great
works of lierature.

Instead of talking about obligations or responsiiblities, try to come up
with an economic incentive to publish.  It works best.

> > 3)  working for the government at the expense of unwilling payors
>
> I don't think this is relevant to the issue at all.

Oh yes it is. I pay their salaries with my taxes, I want to see their results.
[snip]

---

Dr.Dimitri Vulis KOTM
Brighton Beach Boardwalk BBS, Forest Hills, N.Y.: +1-718-261-2013, 14.4Kbps

{% endraw %}
```

## Thread

+ Return to [January 1998](/archive/1998/01)

+ Return to<EMAIL_ADDRESS>(Dr.Dimitri Vulis KOTM)](/authors/dlv_at_bwalk_dm_com_dr_dimitri_vulis_kotm_)"
+ Return to "[Jim Choate <ravage@ssz.com>](/authors/jim_choate_ravage_at_ssz_com_)"

+ 1998-01-11 (Sun, 11 Jan 1998 12:55:58 +0800) - [Re: rant on the morality of confidentiality (fwd)](/archive/1998/01/ee3c880914d646b8d08503eca8f36dbee9545c34cb9683f9ca6578d7b89e0c94) - _Jim Choate<EMAIL_ADDRESS>  + 1998-01-11 (Sun, 11 Jan 1998 13:39:31 +0800) - Re: rant on the morality of confidentiality (fwd) -<EMAIL_ADDRESS>(Dr.Dimitri Vulis KOTM)_


text:
---
title: Discord
sidebar_position: 2
description: Understand the basics for getting started and running the OpenBB Boton Discord.
keywords: [discord, how to, explanation, openbb bot, openbb, guide, bot guide, commands, community]
---

import HeadTitle from<EMAIL_ADDRESS>
<HeadTitle title="Discord - Bot | OpenBB Docs" />

## Getting Started with Discord

Now that you have added the bot to your Discord you can get started with running commands.

If you're new to OpenBB Discord Bot, here's a quick guide to get you started.

To use OpenBB, you need to use slash commands, which are special commands that start with a / symbol. To autoselect commands if you are on Desktop you can hit ```TAB```

<div className="flex justify-center h-full w-[800px] rounded-r-[4px]">
  <img
    className="h-full object-cover"
    alt="gif describing step"
    src="https://openbb-web-assets.s3.amazonaws.com/docusaurus-openbb-bot-walkthrough-gifs/page1.gif"
  />
</div>

You can type / in the chat to see a list of available slash commands for OpenBB Bot. One of the most useful slash commands is ```/help```, which shows you all the commands and how to use them. Some of the most popular commands are:

- ```/cd ticker: AMD``` Shows the daily chart for a given stock ticker.
- ```/c3m ticker: AMD``` Shows the 3-month chart for a given stock ticker.
- ```/flow ticker: AMD``` Shows the recent options flow for the given stock ticker.

That's it! You're ready to explore the market with OpenBB Discord Bot!

Check out the Reference section for more commands or type ```/help``` in your chat to see what else we can do!

repository: conrad-strughold/GamestonkTerminal

branch_name: refs/heads/main

repo_name: conrad-strughold/GamestonkTerminal


text:
# Background

PRSice-2 is one of the dedicated PRS programs which automates many of the steps from the previous page that used a sequence of PLINK functions (plus some QC steps).
On this page you will run a PRS analysis using PRSice-2, which implements the standard C+T method.

## Obtaining PRSice-2
`PRSice-2` can be downloaded from:

| Operating System | Link |
| -----------------|:----:|
| Linux 64-bit | [v2.3.3](https://github.com/choishingwan/PRSice/releases/download/2.3.3/PRSice_linux.zip) |
| OS X 64-bit | [v2.3.3](https://github.com/choishingwan/PRSice/releases/download/2.3.3/PRSice_mac.zip) |

and can be directly used after extracting the file.

In this tutorial, you will only need `PRSice.R` and `PRSice_XXX` where XXX is the operation system

## Required Data

This analysis assumes that you have the following files (or you can download it from [here](https://drive.google.com/file/d/1x_G0Gxk9jFMY-PMqwtg6-vdEyUPp5p5u/view?usp=sharing)):

|File Name | Description|
|:-:|:-:|
|**Height.QC.gz**| The post QC base data file. While PRSice-2 can automatically apply most filtering on the base file, it cannot remove duplicated SNPs|
|**EUR.QC.bed**| This file contains the genotype data that passed the QC steps |
|**EUR.QC.bim**| This file contains the list of SNPs that passed the QC steps |
|**EUR.QC.fam**| This file contains the samples that passed the QC steps |
|**EUR.height**| This file contains the phenotype data of the samples |
|**EUR.cov**| This file contains the covariates of the samples |
|**EUR.eigenvec**| This file contains the principal components (PCs) of the samples |

## Running PRS analysis
To run PRSice-2 we need a single covariate file, and therefore our covariate file and PCs file should be combined. This can be done with `R` as follows:

=== "without data.table"

    ```R
    covariate <- read.table("EUR.cov", header=T)
    pcs <- read.table("EUR.eigenvec", header=F)
    colnames(pcs) <- c("FID","IID", paste0("PC",1:6))
    cov <- merge(covariate, pcs, by=c("FID", "IID"))
    write.table(cov,"EUR.covariate", quote=F, row.names=F)
    q()
    ```

=== "with data.table"

    ```R
    library(data.table)
    covariate <- fread("EUR.cov")
    pcs <- fread("EUR.eigenvec", header=F)
    colnames(pcs) <- c("FID","IID", paste0("PC",1:6))
    cov <- merge(covariate, pcs)
    fwrite(cov,"EUR.covariate", sep="\t")
    q()
    ```

which generates **EUR.covariate**.

PRSice-2 can then be run to obtain the PRS results as follows:

=== "Linux"
    ```bash
    Rscript PRSice.R \
        --prsice PRSice_linux \
        --base Height.QC.gz \
        --target EUR.QC \
        --binary-target F \
        --pheno EUR.height \
        --cov EUR.covariate \
        --base-maf MAF:0.01 \
        --base-info INFO:0.8 \
        --stat OR \
        --or \
        --out EUR
    ```

=== "OS X"
    ```bash
    Rscript PRSice.R \
        --prsice PRSice_mac \
        --base Height.QC.gz \
        --target EUR.QC \
        --binary-target F \
        --pheno EUR.height \
        --cov EUR.covariate \
        --base-maf MAF:0.01 \
        --base-info INFO:0.8 \
        --stat OR \
        --or \
        --out EUR
    ```

=== "Windows"
    ```bash
    Rscript PRSice.R ^
        --prsice PRSice_win64.exe ^
        --base Height.QC.gz ^
        --target EUR.QC ^
        --binary-target F ^
        --pheno EUR.height ^
        --cov EUR.covariate ^
        --base-maf MAF:0.01 ^
        --base-info INFO:0.8 ^
        --stat OR ^
        --or ^
        --out EUR
    ```

The meaning of the parameters are as follow:

| Paramter | Value | Description|
|:-:|:-:|:-|
|prsice|PRSice_xxx| Informs `PRSice.R` that the location of the PRSice binary |
|base| Height.QC.gz| Informs `PRSice` that the name of the GWAS summary statistic |
|target| EUR.QC| Informs `PRSice` that the input genotype files should have a prefix of `EUR.QC` |
|binary-target| F| Indicate if the phenotype of interest is a binary trait. F for no |
|pheno| EUR.height| Provide `PRSice` with the phenotype file |
|cov| EUR.covariate| Provide `PRSice` with the covariate file |
|base-maf| MAF:0.01| Filter out SNPs with MAF < 0.01 in the GWAS summary statistics, using information in the `MAF` column|
|base-info| INFO:0.8| Filter out SNPs with INFO < 0.8 in the GWAS summary statistics, using information in the `INFO` column|
|stat| OR| Column name of the column containing the effect size|
|or|-| Inform `PRSice` that the effect size is an Odd Ratio|
|out | EUR | Informs `PRSice` that all output should have a prefix of `EUR`|

This will automatically perform "high-resolution scoring" and generate the "best-fit" PRS (in **EUR.best**), with associated plots of the results.
Users should read Section 4.6 of our paper to learn more about issues relating to overfitting in PRS analyses.

??? note "Which P-value threshold generates the "best-fit" PRS?"
    0.3

??? note "How much phenotypic variation does the "best-fit" PRS explain?"
    0.161237

repository: choishingwan/PRS-Tutorial

repo_name: choishingwan/PRS-Tutorial


text:
---
title: "MySQL and TypeORM."
id: "TIL 0054"
date: "2018-12-26"
---

Below are a few thoughts and notes on using MySQL with TypeORM.

#### MySQL

* The default location for MySQL installation (on Mac) is: /usr/local/mysql
* If you get an error when running: ```mysql --version``` it likely means you do not have mysql added to your $PATH. Check this by:
* ```echo $PATH```
* If it is not there, you will need either add it to your session via: ```export path=$PATH:/usr/local/mysql/bin```
* Or you can add it to your .bash_profile file, this is typically located at: /usr
* In order to start your MySQL session, in terminal, run: ``` mysql -h hostNameGoesHere -u usernameGoesHere -p ```
* You can start or stop your MySQL server from System Preferences.
* To access a specific database, you can run: ```mysql -h hostNameGoesHere -u usernameGoesHere -p databaseNameGoesHere```
* In MySQL terms, Schemas and Databases are synonyms.
* You can install MySQL Workbench separately as a GUI for interfacing with MySQL. (I tried using DBeaver, but I had some issues with the MySQL Driver, so have not got it working yet.)

#### TypeORM

If you run into the following error when trying to connect to MySQL from TypeORM:

``` Error: ER_NOT_SUPPORTED_AUTH_MODE: Client does not support authentication protocol requested by server; consider upgrading MySQL client ```

The reason this happens is explained in detail [here](https://github.com/mysqljs/mysql/issues/1959), but in short, MySQL 8.0.4 introduced a new default authentication mechanism 'caching_sha2_pasword'. This is more secure than the previous method used by MySQL, which is 'mysql_native_password'. Now, TypeORM, under the hood, uses mysqljs (I think). Work is being done in order to support this new authentication, however, as of writing, it has not been merged into master. As such, in order to get around this, on MySQL, you need to do the following:

```
ALTER USER 'userName'@'hostName' IDENTIFIED WITH mysql_native_password BY 'passwordHere';
SELECT plugin FROM mysql.user WHERE User = 'root';
```

Thereafter, you need to run (from the MySQL terminal):

1. ```FLUSH PRIVILEGES;```
2. ```quit```
3. Stop MySQL server.
4. Start MySQL server.

You should not be able to run TypeORM again and hopefully it will connect. If not, you may find some guidance by reviewing the following:

* [TypeORM issue](https://github.com/typeorm/typeorm/issues/2093)
* [mysqljs issue](https://github.com/mysqljs/mysql/issues/1507)
* [mysqljs PR](https://github.com/mysqljs/mysql/pull/1962)
* [mysqljs issue](https://github.com/mysqljs/mysql/issues/1959)
* [MySQL documentation](https://dev.mysql.com/doc/refman/8.0/en/caching-sha2-pluggable-authentication.html)

#### TypeORM and Nest.js

Ultimately, I dug into all of the above in order to add a MySQL database to my Itemly API. The work-in-progress code is [here](https://github.com/nicholaspretorius/itemly/tree/itemly-mysql).

repository: nicholaspretorius/npgh

gha_language: JavaScript

repo_name: nicholaspretorius/npgh


text:
# OCP support in DCI

The OCP agent deploys OCP using the OpenShift installer with container images.
Required images are retrieved directly from Quay.io.

## Supported versions

| topic    | Architecture |
| -------- | ------------ |
| OCP-4.12 | x86\_64      |
| OCP-4.11 | x86\_64      |
| OCP-4.10 | x86\_64      |
| OCP-4.9  | x86\_64      |
| OCP-4.8  | x86\_64      |
| OCP-4.7  | x86\_64      |

Only x86_64 is supported; contact your EPM if you would like a specific architecture (or version) not listed here.

## FAQ

1. Where to find more documentation about the Red Hat OpenShift Container Platform Life Cycle?

    - [Red Hat OpenShift Container Platform Life Cycle official document](https://access.redhat.com/support/policy/updates/openshift/)

repository: redhat-cip/dci-openshift-agent

gha_language: Shell

repo_name: redhat-cip/dci-openshift-agent


text:
---
layout: post
title: "Deep Learning: Chapter 8"
date: 2017-07-04 02:36:00
categories: Learning
---

# 8 Optimization for Training Deep Models

This chapter focuses on one particular case of optimization: finding the parameters $\theta$ of a neural network that significantly reduce a cost function $J(\theta)$, which typically includes a performance measure evaluated on the entire training set as well as additional regularization terms.

## 8.1 How Learning Differs from Pure Optimization

### 8.1.1 Empirical Risk Minimization

### 8.1.2 Surrogate Loss Functions and Early Stopping

### 8.1.3 Batch and Minibatch Algorithms

standard error of the mean: $\sigma / \sqrt{n}$

large numbers of examples that all make very similar contributions to the gradient

Minibatch sizes are generally driven by the following factors:
  * Larger bathces provide a more accurate estimate of the gradient, but with less than linear return.
  * Multicore architectures are usually underutilized by extremely small batches.
  * Parallel processing
  * Specific sizes of arrays
  * Small batches can offer a regularizing effect.

Some algorithms are more sensitive to sampling error than others:
  * either because they use information that is difficult to estimate accurately with few sampels.
  * or because they use information in ways that amplify sampling errors more.

It is also crucial that the minibatches be selected randomly.
  * shuffle the order of the dataset once and then store itin shuffled fashion.

## 8.2 Challenges in Neural Network Optimization

### 8.2.1 Ill-Conditioning

### 8.2.2 Local Minima

**model identifiability**
  * weight space symmetry

### 8.2.3 Plateaus, Saddle Points and Other Flat Regions

### 8.2.4 Cliffs and Exploding Gradients

### 8.2.5 Long-Term Dependencies

### 8.2.6 Inexact Gradients

### 8.2.7 Poor Correspondence between Local and Global Structure

### 8.2.8 Theoretical Limits of Optimization

## 8.3 Basic Algorithms

### 8.3.1 Stochastic Gradient Descent

### 8.3.2 Momentum

### 8.3.3 Nesterov Momentum

## 8.4 Parameter Initialization Strategies

Unfortunately, these optimal criteria for initial weights often do not lead to optimal performance. Three different reasons:
  * wrong criteria
  * the properties may not persist after learning
  * the criteria might succeed at improving the speed of optimization but inadvertently increase generalization error.

There are a few situations where we may set some biases to nonzero values:
  * if a bias is for an output unit.
  * choose the bias to avoid causing too much saturation at initialization.
  * a control unit.

## 8.5 Algorithms with Adaptive Learning Rates

**delta-bar-delta**

### 8.5.1 AdaGrad

**Algorithm 8.4** The AdaGrad algorithm

### 8.5.2 RMSProp

**Algorithm 8.5** The RMSProp algorithm

 **Algorithm 8.6** RMSProp algorithm with Nesterov momentum

### 8.5.3 Adam ???

### 8.5.4 Choosing the Right Optimization Algorithm

hahaha: The choice of which algorithm to use, at this point, seems to depend largely on the user's familiarity with the algorithm(for ease of hyperparameter tuning).

## 8.6 Approximate Second-Order Methods

### 8.6.1 Newton's Method

### 8.6.2 Conjugate Gradients

Conjugate gradients is a method to efficiently avoid the calculation of the inverse Hessian by iteratively descending conjugate directions.

### 8.6.3 BFGS ???

## 8.7 Optimization Strategies and Meta-Algorithms

### 8.7.1 Batch Normalization

### 8.7.2 Coordinate Descent

### 8.7.3 Polyak Averaging

When applying Polyak averaging to non-convex problems, it is typical to use an exponentially decaying running average:

$$
\hat{\theta}^{(t)} = \alpha \hat{\theta}^{(t-1)} + (1 - \alpha) \theta^{(t)}.
$$

### 8.7.4 Supervised Pretraining

greedy supervised pretraining

transfer learning

teacher student network

### 8.7.5 Designing Models to Aid Optimization

In practice, it is more important to choose a model family that is easy to optimize than to use a powerful optimization algorithm.

ReLU

linear paths or skip connections

### 8.7.6 Continuation Methods and Curriculum Learning

**Continuation methods**

Traditional continuation methods are usually based on smoothing the objective function.

**Curriculum learning**


text:
# hydra-consent-app-express

This is an exemplary consent application that implements ORY Hydra's consent flow. It uses NodeJS and express.

# DEV

Build image : docker build -t hydra-consent-mock .

repository: flaugere/hydra-consent-app-express

repo_name: flaugere/hydra-consent-app-express


text:
---
layout: post
title: Go out and empathise!
description: How we’re using Experience Principles to keep each other honest at Deliveroo.
categories: Article
date:   2017-11-23 12:01:00
---

In the last three years, the Deliveroo Content, Research and Design team has grown from a single designer to a team of nearly thirty designers, researchers and content writers, with no signs of stopping any time soon. (*[We’re hiring](https://deliveroo.design/) by the way.*)

This is great. It means we can support the product teams as they grow (over 250 people now work in our product and tech organisation), we have capacity and time to do better work, and we can also think about what processes, [rituals and artifacts](https://www.vantigeinc.com/blog/bid/267686/Artifacts-Legends-and-Rituals-Keys-to-your-Company-Culture) we need as we grow.

We’ve grown fast, which means change in our team culture has happened fast too. We’re very proud of the (incredible) people in the team, but sometimes you need more than talent when there are so many moving parts and everyone is embedded in their own product team and project, with less time to all hang out.

We’re doing a few things to help us grow well — including setting up a UI infrastructure team to work on our design systems, constantly iterating on how we critique and review work and improving our working patterns and team rituals. But sometimes even these are hard to share across our disciplines.
> # **The other thing I notice– helping the rest of the business understand what we as designers, researchers and writers actually *do* is a constant task.**

I get asked the question ‘what does the product design team work on’ more often than I would have expected — despite the fact that our partners in the rest of the business are very smart and technically savvy. The fact is, from the outside it’s hard to understand how we think and what we’re up to every day.

While the whole company doesn’t need to know exactly how the magic happens, the basic principles of user-centred design, empathy and designing usable interfaces would allow for design thinking to permeate further into the company culture and also allow us to share a lexicon when talking about our work.

We wanted to align ourselves and educate those around us, so we started talking about principles — if we can’t explain everything we do, we can at least tell people some of the things that we believe.

### Enter our Experience Principles

![](https://cdn-images-1.medium.com/max/7016/1*4jqpktbRdfmSWXzry5XfEg.jpeg)

**Our goals for these principles were two-fold:**

* Allow us as a team to have better discussions about the quality of our output, and easily bring new joiners to the same shared conversations.

* Introduce conversations about user needs, scaleable design and things we care about to the product teams and wider organisation.

After hours post it note-ing and whiteboarding (and some good advice from [Stanley Wood](), thank you sir) we ended up with a list of seven principles that fitted the following criteria:

1. **Feel uniquely ours**
While it would have been tricky to write a set of good experience principles that no-one has ever used before, we wanted to make sure our tone of voice was clear in writing them.

1. **Feel directly actionable by anyone, even outside our team**
Our dream is that these principles are used in rooms that we’re not in. That means engineers, product managers, customer support folks, even up to our CEO, can find something they can use in them.

1. **Are general to all of our disciplines**
Our team (Content, Research and Design, acronym CRD) is made up of three equal but different disciplines. Going deep on principles that primarily related to only UI, or research techniques, wouldn’t have been usable to all three.

1. **Are opinionated (you could argue against them)**
It’s easy to write principles like ‘make things usable’ — there is no clear sacrifice to doing this, it’s just good practice. We wanted our principles to be opinionated and have some cost tradeoff, a proxy for which we decided was that we could point to *exceptional* companies who had chosen not to demonstrate them. This turned out to be really hard.

Some were about being able to work more efficiently at scale, some were about ensuring we were designing for the right people, some were more about our internal working culture. We whittled these further, down to four immutable and clearly distinctive ideals.

![](https://cdn-images-1.medium.com/max/7016/1*HDn-G_IVpfKelrU6cT6ZMA.jpeg)

![](https://cdn-images-1.medium.com/max/7016/1*fONQDcUfO81rIslv8Nm-xA.jpeg)

![](https://cdn-images-1.medium.com/max/7016/1*BCZvjGVQGbnrXoZtzaDjxQ.jpeg)

![Our principle posters, illustrated by [Sam Ailey](https://samailey.co.uk/)](https://cdn-images-1.medium.com/max/7016/1*xOr1ptGSncCm-2fdTwfpWg.jpeg)*Our principle posters, illustrated by [Sam Ailey](https://samailey.co.uk/)*

What was interesting was that what we ended up with, we were confident we were already doing in some capacity — but in articulating them we could double down on them. Still, some would ask — if they’re so obvious and everyone already agrees,* why have them at all?*

The answer is — these things aren’t always obvious to everyone. Designers, researchers and UX writers, and even other people in a product team, may read them and see them as no-brainers, but by being first principles-based and general, we can educate others too.

By stating them we can double down on them ourselves and point at them to explain the things we say, and as we grow, new people on the team can read them and understand our beliefs immediately.

There are only four so far, which has the added advantage of meaning I can remember them all without looking. We may add more in the future, or update these, but for now we’ve agreed on four things. That was hard enough.

Below these sit team and discipline specific principles, which are much more focused on single user groups and execution. Teams can add and use those as they wish, but these four are enough for the business as a whole to get on board with what we’re up to and how we think.

We’re at the start of this journey — building one of the pillars of our plans to scale design. Watch this space to see how these go!

_This was originally posted on the Deliveroo [Design blog](https://medium.com/deliveroo-design/go-out-and-empathise-2dc7758bb57b)_

extension: markdown

gha_language: SCSS


text:
# Update-RelayRocketLECert
Automatically handles the copying of a renewed Let's Encrypt SSL certificate to the location that Relay Rocket needs

## Certbot Installation and Initial Execution
Relay Rocket uses Ubuntu 18.04LTS and NGINX.  That version of Ubuntu already comes with SNAP installed (https://snapcraft.io/docs/installing-snapd).  The commands below are summarized from https://certbot.eff.org/lets-encrypt/ubuntubionic-nginx
```bash
sudo snap install core; sudo snap refresh core
sudo apt-get remove certbot
sudo snap install --classic certbot
sudo ln -s /snap/bin/certbot /usr/bin/certbot
sudo certbot certonly
```
If for some reason you get an error when issuing the snap command, you may need to manually install snapd.
```bash
sudo apt-get update
sudo apt install snapd
```

The very first time you execute the certbot command you will be prompted to go through the initial setup.  You will be asked a few questions.   You must
agree in order to register with the ACME server. Do you agree?
 We'd like to send you email about our work encrypting the web,
EFF news, campaigns, and ways to support digital freedom.

No names were found in your configuration files. Please enter in your domain
name(s) (comma and/or space separated)  (Enter 'c' to cancel): test.school.org
Requesting a certificate for test.nnnc.org
Performing the following challenges:
http-01 challenge for test.school.org
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/test.school.org/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/test.school.org/privkey.pem
   Your certificate will expire on 2021-06-16. To obtain a new or
   tweaked version of this certificate in the future, simply run
   certbot again. To non-interactively renew *all* of your
   certificates, run "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le
```

## Primary Server Script Installation
Each of the following sections list instructions to follow in order to complete the installation.  An automatation script may be developed in the future that will perform these tasks upon execution, but that is not included at this time.

### Create Directory
You will need to create a folder inside the /opt path
```bash
sudo mkdir /opt/scripts
```

### File Locations
The following files will need to be created.  This can be done with a file transfer or creating the file directly on the server and pasting the file contents into the file.
* [certbot2lightspeed.bash](https://github.com/northeastnebraskanetworkconsortium/Update-RelayRocketLECert/blob/main/PrimaryRocket/certbot2lightspeed.bash) - /opt/scripts/
* [.environmentFile](https://github.com/northeastnebraskanetworkconsortium/Update-RelayRocketLECert/blob/main/PrimaryRocket/.environmentFile) - /opt/scripts/
* [rocket-letsencrypt.service](https://github.com/northeastnebraskanetworkconsortium/Update-RelayRocketLECert/blob/main/PrimaryRocket/rocket-letsencrypt.service) - /etc/systemd/system/
* [rocket-letsencrypt.timer](https://github.com/northeastnebraskanetworkconsortium/Update-RelayRocketLECert/blob/main/PrimaryRocket/rocket-letsencrypt.timer) - /etc/systemd/system/

### Make Script Executable
The certbot2lightspeed.bash file must be executable for this process to work.  Regardless how you got that file on the system (manual creation or file transfer), it's recommended to verify if the file is executable or not.  Run the following command
```bash
ls /opt/scripts -al
```
You will get an output similar to
```bash
drwxr-xr-x 2 root root 4096 Mar 19 11:31 .
drwxr-xr-x 3 root root 4096 Mar 19 11:27 ..
-rw-r--r-- 1 root root 1043 Mar 19 11:30 certbot2lightspeed.bash
-rw-r--r-- 1 root root  584 Mar 19 11:31 .environmentFile
```
The permissions for certbot2lightspeed.bash need to be "-rwxr-xr-x".  To change update to those permissions, execute the following command
```bash
 sudo chmod 755 /opt/scripts/certbot2lightspeed.bash
 ```

### File Modification
The only file that requires any customization is the .environmentFile, located in /opt/scripts/.  The first argument of this file must contain the FQDN of the SSL certificate that Let's Encrypt is generating for the relayrocket.
The only other modification that is necessary is if there are multiple Relay Rocket servers in a farm that share the certificate.  Then the certificate must be copied to the other server.  The second and third arguments must be populated to include the appropriate values.

### Enable and Start Services
Once the files have been placed in the correct folders and the .environmentFile has been modified, the services need to be enabled.
```bash
systemctl enable rocket-letsencrypt.service
systemctl enable rocket-letsencrypt.timer
```
The service successfully runs when there is no output that follows the running of that command, if running as root.  If running as a non-root user you will be prompted for your user password (commands only work if user is in sudoers file).
Next, you need to start the timer file.  You do not need to start the .service file as the .timer file will start it at the appropriate time.
```bash
systemctl start rocket-letsencrypt.timer
```
If you would like to manually verify the service is loaded, you may execute the following command:
```bash
systemctl status rocket-letsencrypt.timer
```
You will get an output similar to
```bash
● rocket-letsencrypt.timer - Timer copies certs to rocket directory and to other server
   Loaded: loaded (/etc/systemd/system/rocket-letsencrypt.timer; disabled; vendor preset: enabled)
   Active: active (waiting) since Tue 2021-03-16 11:08:21 CDT; 2 days ago
  Trigger: Thu 2021-03-18 23:32:00 CDT; 11h left

Mar 16 11:08:21 relayrocket1 systemd[1]: Started Timer copies certs to rocket directory and to other server.
```

To check if the timers are enabled at any given point, you can execute this command
```bash
systemctl list-timers
```
You will get an output similar to
```bash
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Fri 2021-03-19 12:00:57 CDT  22min left    Fri 2021-03-19 11:04:09 CDT  34min ago    anacron.timer                anacron.service
Fri 2021-03-19 13:32:00 CDT  1h 53min left Fri 2021-03-19 10:51:09 CDT  47min ago    snap.certbot.renew.timer     snap.certbot.renew.service
Fri 2021-03-19 14:16:20 CDT  2h 37min left Thu 2021-03-18 14:16:20 CDT  21h ago      systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2021-03-19 18:06:29 CDT  6h left       Fri 2021-03-19 02:17:09 CDT  9h ago       motd-news.timer              motd-news.service
Fri 2021-03-19 19:28:55 CDT  7h left       Fri 2021-03-19 11:33:39 CDT  5min ago     apt-daily.timer              apt-daily.service
Fri 2021-03-19 23:32:00 CDT  11h left      n/a                          n/a          rocket-letsencrypt.timer     rocket-letsencrypt.service
Sat 2021-03-20 06:42:16 CDT  19h left      Fri 2021-03-19 06:49:26 CDT  4h 49min ago apt-daily-upgrade.timer      apt-daily-upgrade.service
Mon 2021-03-22 00:00:00 CDT  2 days left   Thu 2021-03-18 14:01:26 CDT  21h ago      fstrim.timer                 fstrim.service

8 timers listed.

Pass --all to see loaded but inactive timers, too.
```
In the sample output above, the "11h left" in the 2nd column indicates the timer is started and is counting down until it will run next.  Columns 3 and 4 with values of "n/a" just mean the timer has not yet been run.  Notice you can see both the rocket-letsencrypt.timer and snap.certbot.renew.timer (which the later was setup by the original Certbot installation).

### Manually Test Script
As long as you have completed setup above, you can manually run the script by starting executing the rocket-letsencrypt.service file.
```bash
systemctl start rocket-letsencrypt.service
```
After the .service file has been executed at least once (either manually or by the .timer), one or two small files are generated for the sole purpose of marking the last time the script was ran (/opt/scripts/lastexecuted) and the last time the script copied and renamed the certificate (/opt/scripts/lastcopied).  The contents of the files just show you which user was used to execute the script, which will be root.  It's the date/time stamp of those files that tells you when it was executed last.

## Secondary Server Script Installation (optional)
Each of the following sections list instructions to follow in order to complete the installation for the secondary server.  An automatation script may be developed in the future that will perform these tasks upon execution, but that is not included at this time.

### Multiple Server Prequisites
In order to seemlessly transfer the files between servers, the sending server must have a public/private key pair generated with the public key copied to the receiving server. The following command elevates the key generation to root, since systemd uses root for the execution of the timer.
```bash
sudo -H  ssh-keygen -t rsa -b 4096
```
You will be prompted to enter a save location.  The default location of '/root/.ssh/id_rsa' is fine.  Next, you will be prompted to enter a passphrase, but it can be left empty.  Go ahead and leave it empty.

Next, you must copy the public key to the remote server.  Again, the following command elevates to copy of the key from the root user, since systemd uses root for the execution of the timer.
```bash
# Where <ftpuser> represents the ftp user on the remote server and <<IP_ADDRESS>> represents the IP address of the local server
sudo -H ssh-copy-id<EMAIL_ADDRESS>```
In a multiple server configuration, only one server needs to be configured with Certbot; the other server(s) simply need to receive the generated SSL certificate and have them placed in the correct location.

### The following commands are to be performed on the secondary server
### Create Directories
You will need to create a folder inside the /opt path
```bash
sudo mkdir /opt/scripts
sudo mkdir /usr/local/rocket/letsencrypt
```

### Change Folder Permissions
The folder to receive the scripts from the other server needs to have proper permissions of the account that will be used.
```bash
sudo chown <user>:<user> /usr/local/rocket/letsencrypt
```
* please note that the <user> references the actual user account, i.e. adminacct

### File Locations
The following files will need to be created.  This can be done with a file transfer or creating the file directly on the server and pasting the file contents into the file.
* [copy-certificates.bash](https://github.com/northeastnebraskanetworkconsortium/Update-RelayRocketLECert/blob/main/SecondaryRocket/copy-certificates.bash) - /opt/scripts/
* [copy-certificates.service](https://github.com/northeastnebraskanetworkconsortium/Update-RelayRocketLECert/blob/main/SecondaryRocket/copy-certificates.service) - /etc/systemd/system/
* [copy-certificates.timer](https://github.com/northeastnebraskanetworkconsortium/Update-RelayRocketLECert/blob/main/SecondaryRocket/copy-certificates.timer) - /etc/systemd/system/

### Make Script Executable
The copy-certificates.bash file must be executable for this process to work.  Regardless how you got that file on the system (manual creation or file transfer), it's recommended to verify if the file is executable or not.  Run the following command
```bash
ls /opt/scripts -al
```
You will get an output similar to
```bash
drwxr-xr-x 2 root root 4096 Mar 19 11:31 .
drwxr-xr-x 3 root root 4096 Mar 19 11:27 ..
-rw-r--r-- 1 root root 1043 Mar 19 11:30 copy-certificates.bash
```
The permissions for copy-certificates.bash need to be "-rwxr-xr-x".  To change update to those permissions, execute the following command
```bash
 sudo chmod 755 /opt/scripts/copy-certificates.bash
 ```

### Enable and Start Services
Once the files have been placed in the correct folders and the .environmentFile has been modified, the services need to be enabled.
```bash
systemctl enable copy-certificates.service
systemctl enable copy-certificates.timer
```
The service successfully runs when there is no output that follows the running of that command, if running as root.  If running as a non-root user you will be prompted for your user password (commands only work if user is in sudoers file).
Next, you need to start the timer file.  You do not need to start the .service file as the .timer file will start it at the appropriate time.
```bash
systemctl start copy-certificates.timer
```
If you would like to manually verify the service is loaded, you may execute the following command:
```bash
systemctl status copy-certificates.timer
```
You will get an output similar to
```bash
● copy-certificates.timer - Timer copies certs to rocket directory and to other server
   Loaded: loaded (/etc/systemd/system/copy-certificates.timer; disabled; vendor preset: enabled)
   Active: active (waiting) since Tue 2021-03-16 11:08:21 CDT; 2 days ago
  Trigger: Thu 2021-03-18 23:32:00 CDT; 11h left

Mar 16 11:08:21 relayrocket1 systemd[1]: Started Timer copies certs to rocket directory and to other server.
```

To check if the timers are enabled at any given point, you can execute this command
```bash
systemctl list-timers
```
You will get an output similar to
```bash
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
Fri 2021-03-19 12:00:57 CDT  22min left    Fri 2021-03-19 11:04:09 CDT  34min ago    anacron.timer                anacron.service
Fri 2021-03-19 13:32:00 CDT  1h 53min left Fri 2021-03-19 10:51:09 CDT  47min ago    snap.certbot.renew.timer     snap.certbot.renew.service
Fri 2021-03-19 14:16:20 CDT  2h 37min left Thu 2021-03-18 14:16:20 CDT  21h ago      systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Fri 2021-03-19 18:06:29 CDT  6h left       Fri 2021-03-19 02:17:09 CDT  9h ago       motd-news.timer              motd-news.service
Fri 2021-03-19 19:28:55 CDT  7h left       Fri 2021-03-19 11:33:39 CDT  5min ago     apt-daily.timer              apt-daily.service
Fri 2021-03-19 23:32:00 CDT  11h left      n/a                          n/a          copy-certificates.timer      copy-certificates.service
Sat 2021-03-20 06:42:16 CDT  19h left      Fri 2021-03-19 06:49:26 CDT  4h 49min ago apt-daily-upgrade.timer      apt-daily-upgrade.service
Mon 2021-03-22 00:00:00 CDT  2 days left   Thu 2021-03-18 14:01:26 CDT  21h ago      fstrim.timer                 fstrim.service

8 timers listed.

Pass --all to see loaded but inactive timers, too.
```
In the sample output above, the "11h left" in the 2nd column indicates the timer is started and is counting down until it will run next.  Columns 3 and 4 with values of "n/a" just mean the timer has not yet been run.  Notice you can see both the rocket-letsencrypt.timer and snap.certbot.renew.timer (which the later was setup by the original Certbot installation).

### Manually Test Script
As long as you have completed setup above, you can manually run the script by starting executing the copy-certificates.service file.
```bash
systemctl start copy-certificates.service
```
After the .service file has been executed at least once (either manually or by the .timer), one small file is generated for the sole purpose of marking the last time the script was ran (/opt/scripts/lastexecuted).  The contents of the files just show you which user was used to execute the script, which will be root.  It's the date/time stamp of that file that tells you when it was executed last.

 ## Known Issue for Multi-Server Environments
 When more than one Lightspeed server is in place, the public DNS will likely contain multiple public IP addresses to represent the single FQDN it is requesting the certificate for.  As a result, there a chance that the Certbot renewal service will attempt to access the challenge response by visiting the wrong server (noted as Secondary).  Since Certbot is not present on the secondary servrer, the temporary webserver that is stood up for the renewal process is absence and the challenge fails.

To manually circumvent this, modify the firewall rules to temporarily block access to the secondary Lightspeed server, therefore forcing all traffic to fail and to be re-requested to the primary Lightspeed server which contains the challenge.  This manual process has worked once, but due to lack of resources and time, it has not been tested very much.

 It is possible to add a rule to the script to utilize the firewall's API to temporarily disable the rule to the secondary server, but that is currently out of the scope of this script.


text:
js-LetterPairs
==============

Fuzzy matching of strings based on common letter pairs in words. This is a javascript implementation of the string similarity algorithm found
[here](http://www.catalysoft.com/articles/StrikeAMatch.html). Perhaps we can call it the Letter Pairs Algorithm.

License: MIT

Author: Paul Harper

repository: benekastah/js-FuzzyMatch

repo_name: benekastah/js-FuzzyMatch


text:
---
id: jdbc
title: "Bloodhound: JBDC Module"
sidebar_label: JBDC
---

The module implements multiple actors involving the connection to JDBC databases.

## Proxy

### `UpstreamJdbcActor`

An upstream actor that acts as a backend for a route.

::note
The current implementation is **synchronous**
:::

**class:** `com.apifortress.afthem.modules.jdbc.actors.proxy.UpstreamJdbcActor`

**configuration:**

* `url`: a JDBC url, such as `jdbc:postgresql://localhost:5432/mydb?user=john&password=111aa`
* `driver`: the fully qualified path of the jdbc driver, such as `org.postgresql.Driver`
* `max_rows`: a limiter to the number of returned rows. Default: `100`

repository: leftxs/sauce-docs

repo_name: leftxs/sauce-docs


text:
[![Run on Repl.it](https://repl.it/badge/github/tirthajyoti-ghosh/freelance-job-scraper)](https://repl.it/github/tirthajyoti-ghosh/freelance-job-scraper)

# Freelance Job Scraper

> Ruby Capstone Project of Microverse, which students have to complete a real-world-like project within 72 hours according to [this project specifications](https://www.notion.so/microverse/Build-your-own-scraper-f54eaca54d8a4d758a5f0141468127a8)

This web scraper is a freelance job scraper that scrapes freelance jobs from these three websites: `freelancer.com`, `guru.com`, `peopleperhour.com` with keywords taken from the user input and exports them to 3 separate CSV files.

![demo-image](https://user-images.githubusercontent.com/57726348/77246333-4b02a400-6c4c-11ea-89e1-5a32c81321b9.png)

## Built With

- Ruby
- Nokogiri gem
- HTTParty gem

## Project Structure

```
├── README.md
├── bin
│   └── main.rb
└── lib
    └── scraper.rb
    └── csv_exporter.rb
└── rspec
    └── scraper_spec.rb
    └── csv_exporter_spec.rb
    └── spec_helper.rb
```

## Video Presentation

Feel free to check out this [link](https://www.loom.com/share/7e4744e6ccd84860858f4be44fc3f212) for a 5min video walkthrough :)

## Deployment

1) Git clone this repo and cd the to the `freelance-job-scraper` directory.
2) Run `bundle install` in command line to install Nokogiri and HTTParty Gem.
3) Run `ruby bin/main.rb`.
4) Input keywords in separate lines. Press enter key on a new line to begim the search.
5) Tada! 'freelance.com-jobs.csv', 'guru.com-jobs.csv', and 'peopleperhour.com-jobs.csv' would be created at the root directory respectively :)

## Run tests

1) Git clone this repo and cd the to the `freelance-job-scraper` directory.
2) Install rspec with `gem install rspec`.
3) Run `rspec` in Command Line.
4) `15 examples, 0 failures` will be shown on the screen.

## Future releases
- User can select which sites they want to scrape
- Add more sites for scraping
- User can specify how many jobs he/she wants to scrape

## Author

👤 **Tirthajyoti Ghosh**

- Github: [@tirthajyoti-ghosh](https://github.com/tirthajyoti-ghosh)
- Twitter: [@terrific_ghosh](https://twitter.com/terrific_ghosh)
- Linkedin: [Tirthajyoti Ghosh](https://www.linkedin.com/in/tirthajyoti-ghosh/)

## 🤝 Contributing

Contributions, issues and feature requests are welcome!

Feel free to check the [issues page](https://github.com/tirthajyoti-ghosh/freelance-job-scraper/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc).

## Show your support

Give a ⭐ if you like this project!

## Acknowledgments

- Microverse
- Nokogiri gem
- HTTParty Parser
- Freelancer.com
- Guru.com
- Peopleperhour.com

## 📝 License

This project is [MIT](lic.url) licensed.

repository: tirthajyoti-ghosh/freelance-job-scraper

branch_name: refs/heads/development

gha_language: Ruby

repo_name: tirthajyoti-ghosh/freelance-job-scraper


text:
# test
fuelphp test

##Installation step by step

###clone from repository
```
git clone https://github.com/liversohn/test
cd test
```

###setup submodules
```
git submodule init
git submodule update
```

###download composer for fuel core and update
```
cd fuel/core
curl -sS https://getcomposer.org/installer | php
php composer.phar update
```

###setup apache docroot into test/public
###setup host for the vhost in /etc/hosts

run the host in browser

repository: liversohn/test

repo_name: liversohn/test


text:
Sequence scripts
================

Scripts which define sequences of requests that should perform a specific task in an application.
Sequence scripts must be implemented in Zest, and are used by the optional 'sequence' add-on that is available from the ZAP Marketplace.


text:
# Definition

A **definition** is a linking of the name to the value or to the [function](/ride/functions.md) body.

## Examples

Linking the name to the value.

``` ride
let x = 5 + 5
```

Linking the name to the function body.

``` ride
func f(x: Int) = {
  x + 5
}
```


text:
# Developer Handbook

## Table of Contents

- [Getting started](#getting-started)
- [Common tasks](#common-tasks)
- [Dependency management](#dependency-management)
  - [Continuous Integration](#continuous-integration)
- [Package architecture and layout](#package-architecture-and-layout)
  - [Packages shipping Sass](#packages-shipping-sass)
    - [Entrypoint behavior](#entrypoint-behavior)
- [Commit conventions](#commit-conventions)
  - [Commit message format](#commit-message-format)
  - [Type](#type)
  - [Subject](#subject)
  - [Body](#body)
  - [Footer](#footer)
  - [Examples](#examples)
- [Coding style](#coding-style)
  - [Class names](#class-names)
  - [Sass documentation](#sass-documentation)
  - [Start a new `block` or `element`?](#start-a-new-block-or-element)
  - [Red flags](#red-flags)
  - [Files and folders](#files-and-folders)
  - [Working on JavaScript-framework-specific styles](#working-on-javascript-framework-specific-styles)
  - [Using `npm link`/`yarn link`](#using-npm-linkyarn-link)
  - [Pointing NPM dependency of `@carbon/styles` right to the source code](#pointing-npm-dependency-of-carbonstyles-right-to-the-source-code)
- [Maintainers](#maintainers)
  - [Working with icons and pictograms](#working-with-icons-and-pictograms)
  - [Code Patterns](#code-patterns)
    - [Deprecating a component](#deprecating-a-component)
  - [Publishing](#publishing)
    - [Publishing older library versions](#publishing-older-library-versions)
- [FAQ](#faq)
    - [How do I install a dependency?](#how-do-i-install-a-dependency)
    - [CI is failing saying that it cannot find a dependency in offline mode](#ci-is-failing-saying-that-it-cannot-find-a-dependency-in-offline-mode)
    - [How do I fix the repo state if I cancel during a publish?](#how-do-i-fix-the-repo-state-if-i-cancel-during-a-publish)

## Getting started

Carbon is built using a collection of packages all built in the same Git
repository. You might have heard this setup described as a
[monorepo](https://en.wikipedia.org/wiki/Monorepo).

As a result, we use two pieces of tooling to help us manage installing
dependencies and publishing our packages. These include:

- [Yarn workspaces](https://yarnpkg.com/lang/en/docs/workspaces/) for handling
  dependencies across all packages
- [Lerna](https://lerna.js.org/) for publishing packages, tagging versions, and
  more

In order for you to install all the dependencies in this project, you'll need to
[install Yarn](https://yarnpkg.com/en/docs/install) and run the following
command in your terminal:

```bash
yarn install
```

This will install all of the dependencies for every package in our project. In
addition, it allows us to link between packages that we are developing.

This strategy is particularly useful during development, and tooling like Lerna
will pick up on when packages are linked in this way and will automatically
update versions when publishing new versions of packages.

Next up, you'll most likely want to build all of the package files so that
things don't fail while you are working on a package. To do this, you can run
the following command:

```bash
yarn build
```

Afterwards, you should be good to go! For more information about how we handle
dependencies, take a look at our write-up [here](#dependency-management).

## Common tasks

While working on Carbon, here are some of the top-level tasks that you might
want to run:

| Command                           | Usage                                                                                |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------- |
| `yarn build`                      | Uses `lerna` to run the `build` script in each package                                                        |
| `yarn clean`                      | Resets the state of the project by removing all `node_modules` and running the `clean` script in each package |
| `yarn doctoc`                     | Runs `doctoc` on all files in the `doctoc` directory                                                          |
| `yarn format`, `yarn format:diff` | Format files using Prettier, check if files have been formatted                                               |
| `yarn sync`                       | Sync package files across the project                                                                         |
| `yarn lint`                       | Run eslint on files in the project                                                                            |

In addition, you can use `yarn` to run `bin` files using the `yarn <bin>`
syntax. For example, if you wanted to use `lerna` to run a script in every
package you could do the following:

```bash
# Access $(yarn bin)/lerna and pass `run build` to the executable
yarn lerna run build
```

## Dependency management

In light of potential `npm` security issues
[[1]](https://blog.npmjs.org/post/175824896885/incident-report-npm-inc-operations-incident-of)
[[2]](https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes),
we are addressing some of the issues with installing dependencies from a live
registry by taking advantage of
[Yarn's offline feature](https://yarnpkg.com/blog/2016/11/24/offline-mirror/).
The majority of steps taken are inspired by
[this tweet](https://twitter.com/leeb/status/1017607265115750400) from Lee
Byron.

### Continuous Integration

We specify a `.yarnc` file in this project that sets the path for Yarn's
[offline cache](https://yarnpkg.com/features/offline-cache) to the folder
`.yarn/cache`. This folder contains all the tarballs for the packages that the
project uses.

> The way it works is simple: each time a package is downloaded from a remote
> location ... a copy will be stored within the cache. The next time this same
> package will need to be installed, Yarn will leverage the version stored
> within cache instead of downloading its original source.

This ensures that packages are available no matter if the network goes down or
the npm registry is unavailable.

## Package architecture and layout

### Packages shipping Sass

If a package in elements is shipping Sass-based files, then it will follow a
certain number of conventions.

The first convention is that each of these packages will have a `scss` folder
that contains all the Sass files for the package. For example, `@carbon/colors`
would have a folder at `@carbon/colors/scss` in the import path for Sass.

To include the entire package, there are two options within this `scss` folder:
the `index.scss` entrypoint for modules and an entrypoint for inline support.
The `index.scss` entrypoint would be found at<EMAIL_ADDRESS>and would work for teams that are using tools like eyeglass or have already
setup `node-sass`'s `includePaths` option to include `node_modules`.

The other entrypoint option is for inline support. This option will work without
having to use eyeglass or something like `node-sass`'s `includePaths` option.
Each package that ships a `scss` folder will include this entrypoint, and the
name will reflect the package name. For example, `@carbon/colors` would have an
entrypoint available at<EMAIL_ADDRESS>
#### Entrypoint behavior

The entrypoints of our Sass packages will output CSS (side-effects) by default,
unless there is no corresponding CSS to output. These side-effects help with
quickly using a package, but sometimes an application developer will want to
control behavior in order to manage side-effects. For these cases, we expose
additional files that you can include in your project, most notably a common
`scss/mixins.scss` file.

For example, in `@carbon/colors` we can import the `carbon--colors` mixin by
importing<EMAIL_ADDRESS>These types of files are guaranteed
to have no, or minimal, side-effects. The only side-effects that are emitted are
global variable initializations as this is required behavior in newer versions
of Sass.

Using these `mixins.scss` entrypoints allows you as an application developer to
control when these side-effects are applied in your project.

## Commit conventions

This project follows a structured format for writing commit messages. The main
benefit of this approach is that we can use these details to automatically
generate things like changelogs, in addition to clarifying what changes
correspond to when looking at our Git history.

### Commit message format

_Parts of this section are duplicated from
[Angular's commit conventions](https://github.com/angular/angular/blob/master/CONTRIBUTING.md#-commit-message-guidelines)_.

Each commit message consists of a **header**, a **body** and a **footer**. The
header has a specific format that includes a type, a scope and a subject:

```git
<type>(<scope>): <subject>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
```

The **header** is mandatory and the **scope** of the header is optional. There
are a few validation rules that we also enforce, namely that:

- The header must always be fewer than **72** characters
- Any line in the commit body must be fewer than **80** characters

Most of these rules are to help with integration of `git` with common tools.

_Note: we check for this commit format using a tool called
[`commitlint`](https://commitlint.js.org/#/)_.

### Type

Must be one of the following:

- **build**: Changes that affect the build system or external dependencies
- **chore**: Changes that do not affect the meaning of the code (white-space,
  formatting, missing semi-colons, etc.)
- **ci**: Changes to our CI configuration files and scripts
- **docs**: Documentation only changes
- **feat**: A new feature
- **fix**: A bug fix
- **perf**: A code change that improves performance
- **refactor**: A code change that neither fixes a bug nor adds a feature
- **revert**: A code change that reverses a previous commit
- **test**: Adding missing tests or correcting existing tests

### Subject

The subject contains a succinct description of the change:

- use the imperative, present tense: "change" not "changed" nor "changes"
- don't capitalize the first letter
- no dot (.) at the end

### Body

Just as in the subject, use the imperative, present tense: "change" not
"changed" nor "changes". The body should include the motivation for the change
and contrast this with previous behavior.

### Footer

The footer should contain any information about Breaking Changes.

Breaking Changes should start with the word BREAKING CHANGE: with a space or two
newlines. The rest of the commit message is then used for this.

### Examples

  Feature (`feat`)

```diff
// Adding new functionality to a piece of code is considered a feature.
// This can be seen as extending an existing API
-function MyComponent({ propA }) {
+function MyComponent({ propA, propB }) {
  // ...
}
```

  Bug fix (`fix`)

```diff
// Updating an implementation to correct a fault in the existing code is
// considered a bug fix
function add(a, b) {
-  return a - b;
+  return a + b;
}
```

  Chore (`chore`)

Running things like formatting, or generally any project clean-up tasks, can be
considered a chore that we are doing to keep things up-to-date.

## Coding style

### Class names

Prefix all class names with `#{$prefix}--` in SCSS, which is replaced with
`cds--` by default, and design systems inheriting Carbon can override. This
prefix prevents potential conflicts with class names from the user.

**HTML**

```html
<div
  class="cds--inline-notification cds--inline-notification--error"
  role="alert">
  <div class="cds--inline-notification__details">...</div>
</div>
```

**SCSS**

```scss
.#{$prefix}--inline-notification {
  ...
}

.#{$prefix}--inline-notification__details {
  ...
}
```

Follow BEM naming convention for classes. Again, the only thing we do
differently is prefix all classes with `#{$prefix}--`.

```scss
.#{$prefix}--block
.#{$prefix}--block__element
.#{$prefix}--block--modifier
```

Avoid nesting selectors, this will make it easier to maintain in the future.

```scss
// Don't do this
.#{$prefix}--inline-notification {
  .#{$prefix}--btn {
    &:hover {
      svg {
        ...
      }
    }
  }
}

// Do this instead
.#{$prefix}--inline-notification .#{$prefix}--btn {
    &:hover svg {
      ...
    }
  }
}
```

### Sass documentation

[SassDoc](http://sassdoc.com) is used to document the Carbon Sass source.
SassDoc annotations start each line with `///`; do not use `///` in non-SassDoc
comments.

For consistency, capitalize types (used in `@type`, `@param`, `@return`) and
descriptions (used in `@param`, `@return`, `@deprecated`, `@example`, `@link`).

The following annotations are used:

**Required annotations**

- [Description](http://sassdoc.com/annotations/#description) - can be one line
  or multiple lines
- [`@access`](http://sassdoc.com/annotations/#access) - `public` or `private`,
  where public items make up our public API
- [`@group`](http://sassdoc.com/annotations/#group) - typically a package or
  component name
- [`@type`](http://sassdoc.com/annotations/#type) - allowed on **variables**,
  (e.g. `Map`, `Color`, `Number`)
- [`@param`](http://sassdoc.com/annotations/#parameter) - allowed on
  **functions** and **mixins**, include the type, name, and description, with a
  default value if there is one (e.g.
  `@param {Map} $breakpoints [$carbon--grid-breakpoints] - A map of breakpoints where the key is the name`)
- [`@return`](http://sassdoc.com/annotations/#return) - allowed on
  **functions**, include the type and description (e.g.
  `@return {Number} In px`)
- [`@alias`](http://sassdoc.com/annotations/#alias) - do not include the `$` if
  aliasing a variable
- [`@content`](http://sassdoc.com/annotations/#content) - allowed on **mixins**,
  describe the usage of content
- [`@deprecated`](http://sassdoc.com/annotations/#deprecated) - context around
  possible replacements or when the item will no longer be available

  **Optional annotations**

- [`@example`](http://sassdoc.com/annotations/#example) - if the usage isn't
  straight forward or there are multiple use cases
- [`@link`](http://sassdoc.com/annotations/#link) - if there's a related link to
  reference

  **Examples**

```scss
// Variable example

/// Primary interactive color; Primary buttons
/// @type Color
/// @access public
/// @group @carbon/themes
$interactive-01: map-get($carbon--theme, interactive-01) !default;

// Mixin example

/// Create the container for a grid. Will cause full-bleed for the grid unless
/// max-width properties are added with `make-container-max-widths`
/// @param {Map} $breakpoints [$carbon--grid-breakpoints] - A map of breakpoints where the key is the name
/// @access private
/// @group @carbon/grid
@mixin carbon--make-container($breakpoints: $carbon--grid-breakpoints) {
}

// Function example

/// Compute the type size for the given type scale step
/// @param {Number} $step - Type scale step
/// @return {Number} In px
/// @access public
/// @group @carbon/type
@function carbon--get-type-size($step) {
}
```

### Start a new `block` or `element`?

A nested element can use a new block name as long as the styles are independent
of the parent.

```html
<div class="cds--component">
  <button class="cds--component-button">Button</button>
</div>
```

:point_up: The `#{$prefix}--component-button` class implies that this button has
independent styles from its parent. Generally, it's preferred to start a new
block.

### Red flags

Avoid names with multiple `__element` names:

- :x: `.#{$prefix}--card__list__item`
- :white_check_mark: `.#{$prefix}--card-item`
- :white_check_mark: `.#{$prefix}--card__item`

### Files and folders

All react components belong in `packages/react/src/components` in their own
folder.

All Component styles belong in `packages/styles/scss/components` in their own
folder.

### Working on JavaScript-framework-specific styles

JavaScript-framework-specific is _not_ recommended as we strive to create styles
that are framework-neutral. However, there are some rare cases where
framework-specific cannot be avoided, and some of those make sense to be in
maintained by core style library here.

There are a couple ways to work on framework-specific style.

### Using `npm link`/`yarn link`

This is the most straightforward way. When in the directory of your
`@carbon/styles` folder, run the following command:

```bash
yarn link
```

You should see a success message similar to:

```bash
success Registered "@carbon/styles".
info You can now run `yarn link "@carbon/styles"` in the projects where you want to use this package and it will be used instead.
```

Now, go to the folder where `carbon-components-angular` is located and run:

```bash
yarn link @carbon/styles
```

You should see a success message similar to:

```bash
success Using linked package for "@carbon/styles".
```

The `yarn link` command will allow us to point the `@carbon/styles` package
under `node_modules` to the folder on our filesystem. So, if we make a change in
`@carbon/styles` and re-compile the project it will update in the Storybook
environment for `carbon-components-angular`.

In addition, if you would like to have your changes to styles automatically
compile and update Storybook you can run the following command in the
`@carbon/styles` folder on your machine:

```bash
yarn gulp watch -s
```

This will run the `watch` command in `gulpfile.js`. As a result, whenever you
make a change to the project styles it will automatically copy over into the
`scss` folder which Storybook uses in `carbon-components-angular`.

### Pointing NPM dependency of `@carbon/styles` right to the source code

Though the above approach is the most straightforward, it involves the overhead
of having to run the build process at `@carbon/styles`, in addition to one at
the framework variant repo, upon every Sass code change.

To avoid such overhead, you can point NPM dependency of `@carbon/styles` right
to the source code, though there is a caveat that our future change to the
directory structure, etc. may make such steps no longer work. Here are the
steps:

```sh
> cd /path/to/carbon-components-angular/node_modules/@carbon/styles
> mv scss scss.orig
> ln -s /path/to/@carbon/styles/scss scss
```

Then edits of `.scss` files in `/path/to/@carbon/styles/scss` will be reflected
to the development environment of your framework variant repository. You don't
need to do anything in `@carbon/styles` side.

## Maintainers

### Working with icons and pictograms

We get work submitted by the IBM Brand team, along with other designers at IBM,
that contributes new or updated assets to our icons or pictograms packages. When
you are requested to review these Pull Requests, here are some common things to
look for:

1. Do the assets follow a param-case naming convention?

If not, we'll need to request changes so that they are named using the
`param-case` convention.

2. Is the CI check failing because of missing metadata?

If so, you will need to help out the contributor by going into the package and
running `node tasks/scaffold.js` to seed the metadata information required for
the contribution.

_Note: the scaffold task will only apply to the main metadata file, for new
icons category information will have to be added by hand_

3. Is the CI check failing because of a merge conflict?

If so, you will need to help out the contributor by resolving the merge
conflicts for the Pull Request.

4. Is the CI check failing because of a snapshot change?

If so, you will need to help out the contributor by updating the snapshot based
on the changes. To update snapshot, you'll need to rebuild the relevant packages
and then run Jest.

For example, if icons changed you will want to run the following commands:

```bash
yarn lerna run build --scope='@carbon/icons-react' --include-dependencies
yarn test:e2e -u
```

If pictograms changed, it would be:

```bash
yarn lerna run build --scope='@carbon/pictograms-react' --include-dependencies
yarn test:e2e -u
```

5. Does the Pull Request have an appropriate title?

If not, then you will need to update it to the correct commit convention for the
contribution.

6. Does the Pull Request remove an asset that used to exist?

If so, remind the contributor that we can only remove assets in a major release.
If an asset needs to be removed, they should add the asset back in under its
original name and add it to the corresponding `deprecated.yml` file. They can
still contribute the newly named asset, and it is recommended that they specify
the replacement for the icon in `deprecated.yml` under the `reason` field.

In the event that a change needs to be reflected immediately due to a change in
business relationship or other matter, the asset must still be deprecated and
not removed to avoid a breaking change.

To reflect the change immediately, both the Carbon website and the IDL website
should be updated to no longer show the file in the icon or pictogram library.
[Here's an example PR](https://github.com/carbon-design-system/carbon-website/pull/2781)

### Code Patterns

#### Deprecating a component

Mistakes totally happen, and sometimes we'll need to figure out a strategy to
remove a component from the system. When this happens, we need to make sure that
users of Carbon know that:

1. The component is going to continue to work, deprecating a component does not
   break any existing code
2. That we're going to remove this component in the next major release to give
   them enough time to prepare

In certain cases, we'll also want to support bug fixes for deprecated
components. Most of the time we will state that deprecated components will no
longer receive priority fixes, but we'll still accept outside contributions.

In order to deprecate a component in our React codebase, we have the following
pattern that we tend to use:

```jsx
// SomeComponent.js
// React imports
import { warning } from '../../internal/warning';

let didWarnAboutDeprecation = false;

function SomeComponent() {
  if (__DEV__) {
    warning(
      didWarnAboutDeprecation,
      'The `SomeComponent` component has been deprecated and will be removed ' +
        'in the next major release of `carbon-components-react`'
    );
    didWarnAboutDeprecation = true;
  }
}
```

_Note: if available, you should add a closing sentence specifying what component
to use instead, or share a link for more information. This may look like:_

```jsx
warning(
  didWarnAboutDeprecation,
  'The `SomeComponent` component has been deprecated and will be removed ' +
    'in the next major release of `carbon-components-react`. Please use the ' +
    '`SomeOtherComponent` component instead'
);

warning(
  didWarnAboutDeprecation,
  'The `SomeComponent` component has been deprecated and will be removed ' +
    'in the next major release of `carbon-components-react`. Please visit ' +
    'ibm.biz/<some-hash> for more information'
);
```

### Publishing

#### Publishing older library versions

We offer ad-hoc backwards-support for older version of the system. This work is
primarily driven by external contributors who may still need these older
versions for legacy code. When updates are received and merged into the
codebase, the release process will be a bit different than the one described
above.

For example, with
[`carbon-components-react`](https://github.com/carbon-design-system/carbon-components-react)
we have specific branches for older major versions like `v5` or `v6`. If we
wanted to publish an update to either of these major versions, this process
would look like:

- Checkout the branch locally, making sure to pull in the latest from upstream
- Manually update `package.json` with the new version to publish in a branch
  called `chore/release-vX.Y.Z` and a commit message: `chore(release): vX.Y.Z`
- Create a Pull Request with this new branch and commit message
- Once this is merged into the branch, checkout locally and pull latest. Now we
  can publish by running `npm publish .`, if you want to do a dry run first you
  can do `npm publish . --dry-run`. This is helpful when dependencies may be
  different than in newer versions of the system

One important thing to verify is that `package.json` has a `publishConfig` field
that looks like the following:

```json
{
  "publishConfig": {
    "tag": "<VERSION>.x"
  }
}
```

For example, `carbon-components-react` v5 would look like:

```json
{
  "publishConfig": {
    "tag": "5.x"
  }
}
```

This tag verifies that when we publish we do not publish to the `latest` tag but
instead to the major-specific tag for the package.

After running `npm publish .` and seeing the package publish to the registry,
you could create a git tag by running:

```bash
git tag -a vX.Y.Z # The commit message should match vX.Y.Z
```

You should then push this tag to the project by running:

```bash
git push upstream vX.Y.Z
```

This helps keep track of what versions have been published and snapshotting the
code at that point in time.

## FAQ

#### How do I install a dependency?

When installing a dependency, you can run `yarn add <dependency-name>` as
normal. The only difference now is that you also will check in the corresponding
tarball entry in `.yarn/cache` as well so that we don't have to fetch this
dependency from the live registry during Continuous Integration builds.

#### CI is failing saying that it cannot find a dependency in offline mode

Most likely this is due to Yarn mistakenly removing, or forgetting to add, a
dependency to our offline mirror. Typically, running the following set of
commands should reset the project back to a valid state and should bring back
any missing dependencies or fetch new ones.

```bash
yarn clean
yarn cache clean
yarn
```

#### How do I fix the repo state if I cancel during a publish?

The first things Lerna will do are create a git tag and update `package.json`
versions. If you cancel before any packages publish, then you can do the
following:

```bash
# Delete the specific tag, usually something like v0.1.0
git tag -d name-of-tag
```

```bash
# Undo the last commit
git reset HEAD~

# Remove all staged files
git checkout -- .
```

You should be good to go after this!

repository: carbon-design-system/carbon

repo_name: carbon-design-system/carbon


text:
# ARGLE
## Automatic Requirements for GL Extensions

There are many useful libraries to make handling portable OpenGL loading easier. [GLEW](http://glew.sourceforge.net) and [The OpenGL Loader Generator](https://bitbucket.org/alfonse/glloadgen/wiki/Home) both do this job admirably. However, in order to check for requirements or build a custom loader, you must first know what you are trying to load.

Many "argles" have been bargled in this quest, and ARGLE hopes to help.

ARGLE is a code scanner that takes C or C++ source, extracts all things that look like calls to OpenGL functions, cross-references them with the relevant extension or core version of OpenGL, and produces a summary report.

If an extension of OpenGL is *guaranteed* to be part of later versions, it will also note the highest revision of OpenGL that contains such extensions, and lists any that remain past that point. This can be useful for retrofitting easy-to-communicate requirements to existing code. For example, the first few tutorials in [Learning Modern 3D Graphics Programming](http://arcsynthesis.org/gltut) will be reported as requiring OpenGL 2.0 and GL_ARB_vertex_array_object, but it will then note that all such calls are contained in OpenGL 3.0. (These programs actually require OpenGL 3.3 to *run*, but this is because of run-time configuration and the shaders that it loads from external files. ARGLE cares only about functions that you directly compile against.)

## Syntax

ARGLE's syntax is pretty simple:

```
argle [-v] [filenames]
```

Using the `-v` option sets "verbose" mode where it justifies the requirements by listing each function name it found and the extension it corresponds to. The filenames are the filenames scanned. If you set `-` as a filename, it will read from standard input. That means that you can check the minimum version of an unfamiliar token in someone else's code with a command like:

```
echo glBindBufferBase | argle -
```

If a token doesn't correspond to anything that ARGLE recognizes, it will report a minimum OpenGL requirement of 1.1. This doesn't necessarily mean that OpenGL 1.1 features are in use; however, it is the minimum requirement for all extant OpenGL loader programs.

repository: michaelcmartin/argle

repo_name: michaelcmartin/argle


text:
Pattern: Inconsistent file name via regex

Issue: -

## Description

Enforce a certain file naming convention using a regular expression.

The convention can be configured using a regular expression (the default is `camelCase.js`). Additionally
exporting files can be ignored with a second configuration parameter.

```json
"filenames/match-regex": [2, "^[a-z_]+$", true]
```

With these configuration options, `camelCase.js` will be reported as an error while `snake_case.js` will pass.
Additionally the files that have a named default export (according to the logic in the `match-exported` rule) will be
ignored.  They could be linted with the `match-exported` rule.

repository: Adroiti/docs-for-code-review-tools

repo_name: Adroiti/docs-for-code-review-tools


text:
# Automated Directory Watcher.

I created this application to watch a directory structure for change and then execute some kind of command. I like Guard but the problem with Guard is it's requirement for Ruby and my environment doesnt allow Ruby, just java.

NOTE: this application requires at a minimum Java 7

## Parameters

    -action "C:\\cygwin\\bin\\bash.exe --login /cygdrive/c/hello.sh"
    -recursive
    -workingdir "C:\cygwin\bin"
    -sensitivity 10000
    -dir "c:\temp\deep\"

repository: psenger/DirectoryWatcher

gha_language: Java

repo_name: psenger/DirectoryWatcher


text:
# Changelog

All notable changes to this project will be documented in this file. See [standard-version](https://github.com/conventional-changelog/standard-version) for commit guidelines.

## [3.0.0](https://github.com/dessant/support-requests/compare/v2.1.2...v3.0.0) (2022-12-04)

### ⚠ BREAKING CHANGES

* the action now requires Node.js 16

### Bug Fixes

* update dependencies ([98a49e5](https://github.com/dessant/support-requests/commit/98a49e5fe14d2ac577c5040929acade12296b906))
* update docs ([d40910d](https://github.com/dessant/support-requests/commit/d40910dc927308b57f739e1208a98dc383a7c33e))

### [2.1.2](https://github.com/dessant/support-requests/compare/v2.1.1...v2.1.2) (2021-10-02)

### [2.1.1](https://github.com/dessant/support-requests/compare/v2.1.0...v2.1.1) (2021-07-09)

### Bug Fixes

* update GitHub API calls ([fa1e92b](https://github.com/dessant/support-requests/commit/fa1e92b447253f0739c784bec76cff1ffca26a74))

## [2.1.0](https://github.com/dessant/support-requests/compare/v2.0.1...v2.1.0) (2021-07-09)

### Features

* default `github-token` to `github.token` ([#7](https://github.com/dessant/support-requests/issues/7)) ([731cce0](https://github.com/dessant/support-requests/commit/731cce00ca4b42a6ffd5daf63d11386d592c6567))
* document the use of personal access tokens ([6ba0377](https://github.com/dessant/support-requests/commit/6ba0377537d5719b6b907feabd5e5e3057321cee))

### Bug Fixes

* declare required permissions ([692a08a](https://github.com/dessant/support-requests/commit/692a08a4e543e181bc7feb42e2c7c7fe1b3c9d08))
* lock temporarily unlocked issues even after an error ([182adbd](https://github.com/dessant/support-requests/commit/182adbde03cf78d5a21b696ed2023a2c3d7197c7))

### [2.0.1](https://github.com/dessant/support-requests/compare/v2.0.0...v2.0.1) (2021-01-01)

### Bug Fixes

* update dependencies ([f502ca6](https://github.com/dessant/support-requests/commit/f502ca66a0381e462f29149e7e0b41eae901fc61))

## [2.0.0](https://github.com/dessant/support-requests/compare/v1.0.1...v2.0.0) (2020-08-24)

### ⚠ BREAKING CHANGES

* The deployment method and configuration options have changed.

### Features

* move to GitHub Actions ([4777aa0](https://github.com/dessant/support-requests/commit/4777aa0377f867dbeb97eccd63414255a1fc739a))

### [1.0.1](https://github.com/dessant/support-requests/compare/v1.0.0...v1.0.1) (2019-10-25)

### Bug Fixes

* update dependencies ([7372f4f](https://github.com/dessant/support-requests/commit/7372f4f530e0c33f1d20a91ec3ee54adf137ea35))

## [1.0.0](https://github.com/dessant/support-requests/compare/v0.4.3...v1.0.0) (2019-06-10)

### Features

* update dependencies ([64530c9](https://github.com/dessant/support-requests/commit/64530c9))

### BREAKING CHANGES

* probot < 9.2.13 no longer supported.

## [0.4.3](https://github.com/dessant/support-requests/compare/v0.4.2...v0.4.3) (2019-01-20)

### Bug Fixes

* apply stricter config validation ([c5b97f4](https://github.com/dessant/support-requests/commit/c5b97f4))

## [0.4.2](https://github.com/dessant/support-requests/compare/v0.4.1...v0.4.2) (2018-10-03)

### Bug Fixes

* allow latest version of node ([df959cb](https://github.com/dessant/support-requests/commit/df959cb))

## [0.4.1](https://github.com/dessant/support-requests/compare/v0.4.0...v0.4.1) (2018-09-26)

### Bug Fixes

* allow more versions of node to be used ([7481973](https://github.com/dessant/support-requests/commit/7481973))

# [0.4.0](https://github.com/dessant/support-requests/compare/v0.3.1...v0.4.0) (2018-07-23)

### Features

* notify maintainers about configuration errors ([6886c26](https://github.com/dessant/support-requests/commit/6886c26))

## [0.3.1](https://github.com/dessant/support-requests/compare/v0.3.0...v0.3.1) (2018-06-27)

# [0.3.0](https://github.com/dessant/support-requests/compare/v0.2.1...v0.3.0) (2018-06-24)

### Bug Fixes

* account for missing label object when label is removed ([eb1e76d](https://github.com/dessant/support-requests/commit/eb1e76d))
* add `_extends` option to config schema ([62d0c05](https://github.com/dessant/support-requests/commit/62d0c05))

### Features

* add option for setting lock reason ([e91b1c8](https://github.com/dessant/support-requests/commit/e91b1c8))
* add support for mentioning the issue author ([b43e76e](https://github.com/dessant/support-requests/commit/b43e76e))
* also comment when issue is locked and set lock reason ([67fad24](https://github.com/dessant/support-requests/commit/67fad24))
* extend settings from a different repository ([6affa95](https://github.com/dessant/support-requests/commit/6affa95))

## [0.2.1](https://github.com/dessant/support-requests/compare/v0.2.0...v0.2.1) (2018-06-01)

### Bug Fixes

* set main module path ([e9f828f](https://github.com/dessant/support-requests/commit/e9f828f))

# [0.2.0](https://github.com/dessant/support-requests/compare/v0.1.2...v0.2.0) (2018-05-06)

### Features

* validate config options ([2833846](https://github.com/dessant/support-requests/commit/2833846))

## [0.1.2](https://github.com/dessant/support-requests/compare/v0.1.1...v0.1.2) (2017-11-12)

### Bug Fixes

* comment only if issue is not locked ([a68e322](https://github.com/dessant/support-requests/commit/a68e322))

## [0.1.1](https://github.com/dessant/support-requests/compare/v0.1.0...v0.1.1) (2017-11-11)

### Bug Fixes

* set exact node and npm versions for Glitch deployment ([cbd8374](https://github.com/dessant/support-requests/commit/cbd8374))

# 0.1.0 (2017-11-03)

repository: dessant/support-requests

repo_name: dessant/support-requests


text:
---
layout: post
status: publish
published: true
title: Ansible tagging - why?
author:
  display_name: iguy
  login: iguy
  email<EMAIL_ADDRESS>  url: ''
author_login: iguy
author_email<EMAIL_ADDRESS>date: 2017-12-28
syntax_highlighting:
  enabled: true
  css: main.css
categories:
- ansible
tags:
- scripts
comments: []
---
In recent times I have been utilizing Ansible nearly constantly for a variety of automated deployments from Openstack, AWS and Azure.
Through this there have been a variety of different approaches I've run into on how to structure Ansible Playbooks.  Some have unique playbooks for each different status change by having a playbook to start the enviornment and one to stop it.  Others have a single extra_var that is passed in to determine the state of the environment and that handles starting and stopping the space.   I've even seen the state of the enviornment be split out into different playbooks in different repos.

The one that I simply don't get is using tagging in ansible for starting/stopping/installing the environment.  In this design there is a single playbook that is used for all the different states an environment can be in.   Example of it would be something like this from a command line:

```bash
ansible-playbook -i inventory MyApp.yml --tags start,common,assigntags,security
```
In this you run everything that is marked with start, common, assigntags and security.  Along with that the un-tagged items always run.

Pros to using Tagging:

1. Allow skipping over a given sections (plays or tasks) of the playbook

Cons to using Tagging:

1. Easy to create spagetti code
1. Difficult to debug as more tags are introduced and their interactions

Example:

```yaml
[...]
- name: My first action
  hosts: appserver
  roles: app-make-it-go
  tags:
      - common, security, start

- name: My second action
  hosts: appserver
  roles: app-configure
  tags:
      - common
```

Now this says if you pass in the `security` tag, only the first play will execute.

What if the role has some tasks that are marked with `common` and you didn't pass that in to that first task?

How does the caller know that some steps won't run while others will?

I spent 6 hours debugging one odd issue I was having working with an existing playbook that utilized tags and ultimately I ended up removing all the tags and creating purpose built playbooks to run instead.   This allowed me to follow the logic clearly and find that the issue was one caused because the role had tags and was expecting a certain state when that task ran.  Because of the tags used, that state was skipped in a variety of situations.

I highly encourage folks who build ansible playbooks to think two, three, four, five times about using tags.  It might make it easy when the playbook is first created when everything and every flow is in your head.  It will more likely make whoever has to fix have to unwind the complexity added to the playbook to save a couple files.

Please.. think of the maintainers.


text:
# znc-modules
Various ZNC modules

## mysqlauth.cpp

A module which allows a custom MySQL query as authentication method. Optionally it can Create and Clone an user account if no account exists. Allows custom networks and modules to be configured on creation. Automatically loads NickServ with the supplied password for nickserv authentication.

### Commands:

* `AutoClearChanBuffer [yes|no]` : Whether newly created users should have auto clear channel buffers
* `CloneUser [user]` : Sets the user to clone if no configured user matches
* `CreateUser [yes|no]` : Whether the plugin should create a user when no configured user matches
* `DenyLoadMod [yes|no]` : Whether newly created users are allowed to load modules
* `DisableCloneUser` : Unsets the clone user
* `SetQuery [query]` : Sets the query to use to check for authentication, use ? for replacing data. If the query returns a 'realname' column, it will set the realname of the user.
* `SetQueryArgs [arg1] [arg2] ...` : Sets the mapping of ? to values. Use {password} and {user} for password and user values respectively.
* `GetQuery` : Prints the active query
* `LoadNetworkMods` : Which network modules to load automatically
* `LoadUserMods` : Which user modules to load automatically
* `UserMods` : Shows the network + user modules that are loaded automatically
* `SetNetworks [net "server" ...] | ...` : a pipe delimited list of network definitions as 'netname "server1" "..."'
* `Networks` : Show the configured networks

### Example:

```
status> loadmod mysqlauth localhost znc znc_secret znc
mysqlauth> setquery SELECT `display_name` AS realname FROM `wp_users` WHERE `user_nicename` = ? AND `user_pass` = SHA2(?,256)
mysqlauth> setqueryargs {user} {password}
```

### Compiling:

To compile, you need the mysql-connector-cpp library, after instaling:

```
LIBS=-lmysqlcppconn znc-buildmod mysqlauth.cpp
```

And copy the generated `mysqlauth.so` to `~/.znc/modules/`


text:
# Label-free prediction of three-dimensional fluorescence images from transmitted-light microscopy

[![Build Status](https://github.com/AllenCellModeling/pytorch_fnet/workflows/Build%20Master/badge.svg)](https://github.com/AllenCellModeling/pytorch_fnet/actions)
[![Documentation](https://github.com/AllenCellModeling/pytorch_fnet/workflows/Documentation/badge.svg)](https://allencellmodeling.github.io/pytorch_fnet/)
![Combined outputs](./resources/PredictingStructures-1.jpg?raw=true "Combined outputs")

## Support

This code is in active development and is used within our organization. We are currently not supporting this code for external use and are simply releasing the code to the community AS IS. The community is welcome to submit issues, but you should not expect an active response.

For the code corresponding to our Nature Methods paper, please use the `release_1` branch [here](https://github.com/AllenCellModeling/pytorch_fnet/tree/release_1).

## System requirements

We recommend installation on Linux and an NVIDIA graphics card with 12+ GB of RAM (e.g., NVIDIA Titan X Pascal) with the latest drivers installed.

## Installation

- We recommend an environment manager such as [Conda](https://docs.conda.io/en/latest/miniconda.html).
- Install Python 3.6+ if necessary.
- All commands listed below assume the bash shell.
- Clone and install the repo:

```shell
git clone https://github.com/AllenCellModeling/pytorch_fnet.git
cd pytorch_fnet
pip install .
```

- If you would like to instead install for development:

```shell
pip install -e .[dev]
```

- If you want to run the demos in the examples directory:

```shell
pip install .[examples]
```

## Demo on Canned AICS Data
This will download some images from our [Integrated Cell Quilt repository](https://open.quiltdata.com/b/allencell/tree/aics/pipeline_integrated_cell/) and start training a model
```shell
cd examples
python download_and_train.py
```
When training is complete, you can predict on the held-out data with
```shell
python predict.py
```

## Command-line tool

Once the package is installed, users can train and use models through the `fnet` command-line tool. To see what commands are available, use the `-h` flag.

```shell
fnet -h
```

The `-h` flag is also available for all `fnet` commands. For example,

```shell
fnet train -h
```

## Train a model

Model training is done through the the `fnet train` command, which requires a json indicating various training parameters. e.g., what dataset to use, where to save the model, how the hyperparameters should be set, etc. To create a template json:

```shell
fnet train --json /path/to/train_options.json
```

Users are expected to modify this json to suit their needs. At a minimum, users should verify the following json fields and change them if necessary:

- `"dataset_train"`: The name of the training dataset.
- `"path_save_dir"`: The directory where the model will be saved. We recommend that the model be saved in the same directory as the training options json.

Once any modifications are complete, initiate training by repeating the above command:

```shell
fnet train --json /path/to/train_options.json
```

Since this time the json already exists, training should commence.

## Perform predictions with a trained model

User can perform predictions using a trained model with the `fnet predict` command. A path to a saved model and a data source must be specified. For example:

```shell
fnet predict --json path/to/predict_options.json
```

As above, users are expected to modify this json to suit their needs. At a minimum, populate the following fields and/or copy and paste corresponding dataset values from `/path/to/train_options.json`

e.g.:
```shell
    "dataset_kwargs": {
        "col_index": "Index",
        "col_signal": "signal",
        "col_target": "target",
        "path_csv": "path/to/my/train.csv",
    ...
    "path_model_dir": [
        "models/model_0"
    ],
    "path_save_dir": "path/to/predictions/dir",
```

This will use the model save `models/dna` to perform predictions on the `some.dataset` dataset. To see additional command options, use `fnet predict -h`.

Once any modifications are complete, initiate training by repeating the above command:

```shell
fnet predict --json path/to/predict_options.json
```

## Citation

If you find this code useful in your research, please consider citing our manuscript in Nature Methods:

```
@article{Ounkomol2018,
  doi = {10.1038/s41592-018-0111-2},
  url = {https://doi.org/10.1038/s41592-018-0111-2},
  year  = {2018},
  month = {sep},
  publisher = {Springer Nature America,  Inc},
  volume = {15},
  number = {11},
  pages = {917--920},
  author = {Chawin Ounkomol and Sharmishtaa Seshamani and Mary M. Maleckar and Forrest Collman and Gregory R. Johnson},
  title = {Label-free prediction of three-dimensional fluorescence images from transmitted-light microscopy},
  journal = {Nature Methods}
}
```

## Contact

Gregory Johnson
E-mail<EMAIL_ADDRESS>
## Allen Institute Software License

Allen Institute Software License – This software license is the 2-clause BSD license plus clause a third clause that prohibits redistribution and use for commercial purposes without further permission.
Copyright © 2018. Allen Institute.  All rights reserved.

Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. Redistributions and use for commercial purposes are not permitted without the Allen Institute’s written permission. For purposes of this license, commercial purposes are the incorporation of the Allen Institute's software into anything for which you will charge fees or other compensation or use of the software to perform a commercial service for a third party. Contact<EMAIL_ADDRESS>for commercial licensing opportunities.

gha_license_id: NOASSERTION