text:
---
title:  "Cassandra nodetool authentication using the internal authorizer"
date:   2017-07-27 00:00:00 -0600
categories: cassandra nodetool
---
I learned about a new feature in Cassandra 3.6+ today, the ability to enable nodetool authentication by using Cassandra's [built-in authorizer.](http://docs.datastax.com/en/cassandra/3.0/cassandra/configuration/secureConfigNativeAuth.html) This turned out to be very useful, as I no longer need to manage a username/password in CQL in addition to a username/password in JMX. I'll quickly go through the steps I took to set this up. I did it in Docker, but the steps should be the same in a VM as well.

First, Cassandra's internal authentication/authorization needs enabled. There are two lines in `cassandra.yaml` that need changed:

```diff
- authenticator: AllowAllAuthenticator
- authorizer: AllowAllAuthorizer
+ authenticator: PasswordAuthenticator
+ authorizer: CassandraAuthorizer
```

This will enable authentication when you try to log in with cql, or when an app tries to connect with cql. The default username and password is `cassandra:cassandra`. Now, we want to use that same username/password (or any unique username/password we create) for nodetool. Let's set up nodetool auth using Cassandra's internal database.

The nodetool auth config is set up using Java flags. We will need to add and remove a few flags in the `cassandra-env.sh` file. Let's start with adding flags. Add the following to your `cassandra-env.sh`:

* `JVM_OPTS="$JVM_OPTS -Djava.security.auth.login.config=$CASSANDRA_HOME/cassandra-jaas.config"`
* `JVM_OPTS="$JVM_OPTS -Dcassandra.jmx.authorizer=org.apache.cassandra.auth.jmx.AuthorizationProxy"`

This flag tells Cassandra to use the `cassandra-jaas.config` file to set up its auth. The content of this file is important. If you downloaded Cassandra as a tar, this file may already exist. If not, it needs created with the following content, in the `$CASSANDRA_HOME` directory:
```
// Delegates authentication to Cassandra's configured IAuthenticator
CassandraLogin {
  org.apache.cassandra.auth.CassandraLoginModule REQUIRED;
};
```

We also need to remove (or comment) a few flags (if they exist) from `cassandra-env.sh`. These are the flags that set up the legacy jmx auth. The flags that need removed are:
* `-Dcom.sun.management.jmxremote.password.file=/etc/cassandra/jmxremote.password`
* `-Dcom.sun.management.jmxremote.access.file=/etc/cassandra/jmxremote.access`

Last, start Cassandra and ensure you get an error running nodetool with no username/password:
```
Exception in thread "main" java.lang.SecurityException: Authentication failed! Credentials required
```

You should now be able to run nodetool with a username/password and get success:
`nodetool -u cassandra -pw cassandra status`

Next steps: create a unique username/password with cql, and try using it to authenticate to nodetool.

---
### Further reading:
Here is an [example](https://github.com/dcparker88/cassandra-kubernetes/blob/f9d1c769c34111354e6973f2133430e12a24a26c/image/Dockerfile#L22-L24) of me configuring this type of auth in a Docker container, that I am going to use in Kubernetes. This will be useful because I will only need to have one set of credentials that I manage through cql. I won't need to manage a separate set, and a separate jmx.password file with those credentials.

gha_language: CSS


text:
# aws-ebs-csi-driver operator

An operator to deploy the [AWS EBS CSI driver](https://github.com/openshift/aws-ebs-csi-driver) in OKD.

This operator is installed by the [cluster-storage-operator](https://github.com/openshift/cluster-storage-operator).

#### Note: authoritative YAML files to deploy the driver are in github.com/openshift/cluster-storage-operator/tree/master/assets/csidriveroperators/aws-ebs

# Quick start

Before running the operator manually, you must remove the operator installed by CSO/CVO

```shell
# Scale down CVO and CSO
oc scale --replicas=0 deploy/cluster-version-operator -n openshift-cluster-version
oc scale --replicas=0 deploy/cluster-storage-operator -n openshift-cluster-storage-operator

# Delete operator resources (daemonset, deployments)
oc -n openshift-cluster-csi-drivers delete deployment.apps/aws-ebs-csi-driver-operator deployment.apps/aws-ebs-csi-driver-controller daemonset.apps/aws-ebs-csi-driver-node
```

To build and run the operator locally:

```shell
# Create only the resources the operator needs to run via CLI
oc apply -f https://raw.githubusercontent.com/openshift/cluster-storage-operator/master/assets/csidriveroperators/aws-ebs/standalone/10_cr.yaml

# Build the operator
make

# Set the environment variables
export DRIVER_IMAGE=quay.io/openshift/origin-aws-ebs-csi-driver:latest
export PROVISIONER_IMAGE=quay.io/openshift/origin-csi-external-provisioner:latest
export ATTACHER_IMAGE=quay.io/openshift/origin-csi-external-attacher:latest
export RESIZER_IMAGE=quay.io/openshift/origin-csi-external-resizer:latest
export SNAPSHOTTER_IMAGE=quay.io/openshift/origin-csi-external-snapshotter:latest
export NODE_DRIVER_REGISTRAR_IMAGE=quay.io/openshift/origin-csi-node-driver-registrar:latest
export LIVENESS_PROBE_IMAGE=quay.io/openshift/origin-csi-livenessprobe:latest
export KUBE_RBAC_PROXY_IMAGE=quay.io/openshift/origin-kube-rbac-proxy:latest

# Run the operator via CLI
./aws-ebs-csi-driver-operator start --kubeconfig $MY_KUBECONFIG --namespace openshift-cluster-csi-drivers
```

repository: openshift/aws-ebs-csi-driver-operator

branch_name: refs/heads/master

extension: md

gha_language: Go

license_type: permissive

repo_name: openshift/aws-ebs-csi-driver-operator


text:
<!-- Summarize the bug encountered concisely -->

## What is the current bug behavior?

<!-- What actually happens -->

## What is the expected correct behavior?

<!-- What you should see instead -->

## Know commit with the bug

```bash
git rev-parse HEAD
```

```
commit-id
```

## Steps to reproduce

<!-- How one can reproduce the issue -->

license: MIT

repository: gesiscss/orc

gha_language: HTML

gha_license_id: MIT

repo_name: gesiscss/orc


text:
# Project 1

## Usage of Git, Docker, Automated Testing, and Continuous Integration

There are many components in the software development industry that helps build software in a fast manner to increase productivity. Of all major components, they include using Git, Docker, automated testing, and continuous integration.

Git is a very commonly used VCS (Version Control System) that allows users to track changes made to their files while maintaining a history of what have been done. If an error is ever made, users are allowed to go back to specific versions of the file before the error was made. Git makes collaboration much easier by merging the changes make by all users into one branch or source. This ensure that Git is very useful regardless if the user is working as part of a team or individually.

Docker is a tool that uses containers to make it simpler to create, deploy and run applications. It allows developers to build and test their code in any environment to be able to catch bugs early in the application development cycle. By using Docker, it helps streamline the process of development, save time on the builds and allow developers to run tests in parallel. Docker can integrate with version control systems like GitHub as well as Integration tools to create an image that can be added to the Docker registry. This would handle the inconsistencies between the different types of environment.

Automated testing the best way for developers to increase the effectiveness, efficiency and coverage of their software testing. With manual testing, test engineers strive to catch all defects before the product is released yet they often reappear, even when following the best manual testing processes. An automated testing tool is able to playback pre-recorded actions, check whether the results match the expected behavior and then report the success of failure of the test to the test engineer. Automated testing can be extended to perform tasks that are not possible with manual testing.

Continuous Integration (or CI) is a development practice that requires developers to integrate code into the share repository several times a day. With CI, errors can be detected and located early and easily. Since there is frequent integration occurring, there is less back-tracking needed to discover where something went wrong and developer are allowed to focus more on building the features of the product. Continuous Integration is very cheap compared to not integrating continuously in development.

These features are considered as essential components of successful development projects. The results from helping build software in a secure and fast manner increases the productivity and competitiveness of a company.

---

## GitFlow:

### Typical workflow when using GitFlow is:

1. git pull (or  git fetch)

2.  **Repository:**  A basic element of GitHub that contains all project files and documentation, and also stores each file’s revision history. It can be labeled as public or private and can have multiple collaborators.

2. **Clone:** A  copy of a repository that is stored locally on a user’s computer. It is also defined as the act of making the copy.

3. **Fork:** A personal copy of another user’s repository that is stored on one’s account. It allows a user to make changes to the project without affecting the original repository/project.

4. **Branch:** A parallel version of a repository that is contained with the repo but does not affect the primary or master branch. This allows developers to work freely without disrupting the master (or main) version.

5. **Commit:** An individual change to a file or a set of files. When a commit is made, a unique ID is created to keep record of the changes committed as well as who made them and when it was created. They usually contain a brief description of what changes were made as the commit message.

6. **Merge:** To take the change from one branch (or fork) of a repository and apply them to another. A merge can also be done through a pull request.

7. **Checkout:** To change a user's current working branch to another branch. This can also be used to create a new branch.

8. **Push:** To send committed changes to a remote repository on GitHub so that others may access and view the changes.

9. **Pull:** To fetch and merge changes into current branch.

10. **Remote Add / Remove / Show:**
    - Remote add: To add a new remote to the repository
    - Remote remove: To remove a remote. All remote-tracking branches for the remote are removed
    - Remote show: To provide information about the remote

11. **Status:** A visual representation within a pull request that shows whether the developer’s commits meets the conditions set for the repository they are contributing to.

12. **Master Branch:** The default development branch automatically created when a git repository is created.

**View EXAMPLES [here](git.md)**

---

*View [changelog](P1_CHANGELOG.md)*


text:
---
title: CFSSL Installation
linktitle: CFSSL
description: Installing CFSSL for PKI infrastructure and TLS certificates.

categories: []
keywords: []

menu:
  docs:
    parent: "installation"
    weight: 3

draft: false
---

# cfssl setup

Cfssl and cfssljson utilities are required for PKI infrastructure and TLS certificates.

Download and install cfssl and cfssljson from the official repositories:

```bash
$ yum install -y wget
$ wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 \
     https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
$ chmod +x cfssl_linux-amd64 cfssljson_linux-amd64
$ sudo mv cfssl_linux-amd64 /usr/local/bin/cfssl
$ sudo mv cfssljson_linux-amd64 /usr/local/bin/cfssljson
```

Make sure that cfssl version is 1.2.0 or higher:

```bash
$ cfssl version
Version: 1.2.0
Revision: dev
Runtime: go1.6
```

> Cfssljson cannot print version to the command line.

### Install kubectl

Kubectl communicates with Kubernetes API server. Install and setup kubectl from the official binaries:

```bash
$ wget https://storage.googleapis.com/kubernetes-release/release/v1.10.2/bin/linux/amd64/kubectl
$ chmod +x kubectl
$ sudo mv kubectl /usr/local/bin/
```

Make sure that kubectl version is 1.10.2 or higher:

```bash
$ kubectl version --client
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.2", GitCommit:"81753b10df112992bf51bbc2c2f85208aad78335", GitTreeState:"clean", BuildDate:"2018-04-27T09:22:21Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"linux/amd64"}
```
Done!

Now you can proceed to [Certificate configuration](/kubernetes/installation/2certificates).


text:
# slack-jobs-bot - (Work in progress)
A slack bot that searches jobs for you

## How to use

First, you have to add a bot to a slack channel.
To do so, follow these steps:

1. Visit https://<yourteam>.slack.com/services/new/bot
2. Add bot integration
3. Get the API Token

After, just set the token and the bot name in src/server.js

Then, just run:

```javascript
npm start
```

Type job <term> in slack and wait for the response.

repository: vilellaj/slack-jobs-bot

repo_name: vilellaj/slack-jobs-bot


text:
OpenExRt\Client
========

[![Build Status](https://travis-ci.org/danbelden/open-exchange-rates.svg?branch=master)](https://travis-ci.org/danbelden/open-exchange-rates)
[![Scrutinizer Code Quality](https://scrutinizer-ci.com/g/danbelden/open-exchange-rates/badges/quality-score.png?b=master)](https://scrutinizer-ci.com/g/danbelden/open-exchange-rates/?branch=master)
[![Maintainability](https://api.codeclimate.com/v1/badges/5e7fc4fc1c3659fb3f39/maintainability)](https://codeclimate.com/github/danbelden/open-exchange-rates/maintainability)
[![Latest Stable Version](https://poser.pugx.org/danbelden/open-exchange-rates/version.svg)](https://packagist.org/packages/danbelden/open-exchange-rates)
[![Total Downloads](https://poser.pugx.org/danbelden/open-exchange-rates/downloads.svg)](https://packagist.org/packages/danbelden/open-exchange-rates)

A PHP 5+, wrapper for the [openexchangerates.org](https://openexchangerates.org) API.

# Requirements

This PHP library requires PHP version 5.3.3 or greater, although may work in even weaker versions.
- This 5.3.3 definition is due to travis test coverage assurances

# Installation

## Composer

To install this package with composer, run the following command:

```
composer require danbelden/open-exchange-rates "^1.0"
```

# Documentation

Please see the documentation [README](https://github.com/danbelden/open-exchange-rates/tree/master/docs) for an example use of each method in this library.

Enjoy.

repository: danbelden/open-exchange-rates

gha_language: PHP

repo_name: danbelden/open-exchange-rates


text:
# GeoVis-stack
Full tool stack for Geo-Visualization (based on [Sim-City Stack](https://github.com/indodutch/sim-city-stack)) using docker files and docker-compose.

The goal of this stack is to set up a demo infrastructure of the sim-city stack, using  it is not meant for production deployment!

First, install docker and docker-compose.

Put your simulation scripts in the `simcity-slurm/simulations/` directory with their respective `.json` description
in the `simcity-webservice/simulations/` directory. Resource description should be on the `simcity-webservice/resources/` directory. Check the [documentation](http://sim-city-stack.readthedocs.io/en/latest/NewSimulation.html) for more information on adding simulations to the system.

Then, run a test infrastructure with
```
docker-compose up --build
```
The sim-city frontend is now available on http://localhost:8008/.

Commonsense is running on localhost:3003. The sim-city-webservice is now available on localhost/explore/
There is a CouchDB database running for tasks jobs on on localhost/couchdb/
A webdav server is running on localhost/webdav/

These parts are strung together using nginx that is also running in a docker container.

Finally, a slurm cluster is running to run simulations.

# The Docker Components

## commonsense
This docker container runs the front end.

## simcity-webservice
This docker hosts the simcity-webservice. The simulations directory is copied into the docker when it is built.
Changing the files in this directory therefore requires rebuilding the docker image.

The sim-city-webservice docker is accessible over SSH on port 30022 (user `simcity`, password `simcity`).

## simcity-slurm
This docker hosts a slurm cluster with 2 nodes. The simulations directory is copied into the docker when it is built
into /home/xenon/simulations. Changing the files in this directory therefore requires rebuilding the docker image.

It is running an toned down version of ubuntu 14.04.
All simulations are run as the xenon user. If your simulation depends on certain software add it to the Dockerfile.

The slurm docker is accessible over SSH on port 10022 (user `xenon`, password `javagat`).

## simcity-couchdb
This docker hosts the couchdb. It is a standard couchdb install with a little local configuration.
It runs on port 5784 with user `simcityadmin`, password `simcity`

## simcity-webdav
This docker hosts a webdav server on port 8080. The user is `webdav` with password `vadbew`

## simcity-nginx
This docker hosts the nginx http server. Its configuration links the different docker components together.
It also hosts static content on localhost/www/. You can add your own static content in the www directory,
which gets copied into the docker image when it is built.

repository: GlamGeoVis/geovis-stack

repo_name: GlamGeoVis/geovis-stack


text:
---
author: makumbe
comments: true
date: 2017-07-10 08:00:10+00:00
layout: post
link: http://blog.daanalytics.nl/2017/07/10/exploring-oracle-business-analytics/
slug: exploring-oracle-business-analytics
title: Exploring Oracle Business Analytics
wordpress_id: 2134
categories:
- Oracle Business Analytics
tags:
- OAC
- Oracle Business Analytics
- Oracle Data Visualization
---

In the blogpost about ["Gathering new Knowledge"](http://blog.daanalytics.nl/2017/07/07/gathering-new-knowledge/) I decided to investigate a few different areas of the Oracle atmosphere. Oracle Business Analytics was one of them. In a series of different blogposts I will cover different parts of the Oracle Business Analytics  product suite. At the end of this post there will be a list of different links to the blogposts I will be sharing.

I will begin with a post I created earlier. This is because of the importance of the subject. One crucial element in Oracle Analytics is the Oracle BI Server. Thanks to [Christian Berg](https://twitter.com/nephentur?lang=en), we were able to go to the [Core of Oracle Analytics](http://blog.daanalytics.nl/2017/06/22/going-to-the-core-of-oracle-analytics/).

Last month Oracle released a new version of [Oracle Data Visualization V3.0](http://wp.me/pVzHx-yG). In this upgraded version you can expect some new functionality regarding:

  * connections to data sources & data preparation,

  * enhanced data flow

  * intuitive data visualization process setup & formatting

  * comprehensive system management toolset

When the posts are ready, I will post the links below. I hope you will find my findings interesting. Please share your comments.

  * [Going to the Core of Oracle Analytics](http://blog.daanalytics.nl/2017/06/22/going-to-the-core-of-oracle-analytics/)

  * [Oracle Data Visualization V3.0](http://blog.daanalytics.nl/2017/07/06/oracle-data-visualization-v3-0/)

  * [Oracle Mobile Analytics](http://blog.daanalytics.nl/2017/07/12/oracle-mobile-analytics/)

This post is written as part of my [Gathering new Knowledge](http://blog.daanalytics.nl/2017/07/07/gathering-new-knowledge/) series.

Thanks for reading.

extension: markdown


text:
---
layout: post
title: "User Intent Classification using Memory Networks: A Comparative Analysis for a Limited Data Scenario"
date: 2017-06-19 20:12:07
categories: arXiv_CV
tags: arXiv_CV Classification Memory_Networks Recommendation
author: Arjun Bhardwaj, Alexander Rudnicky
mathjax: true
---

* content
{:toc}

##### Abstract
In this report, we provide a comparative analysis of different techniques for user intent classification towards the task of app recommendation. We analyse the performance of different models and architectures for multi-label classification over a dataset with a relative large number of classes and only a handful examples of each class. We focus, in particular, on memory network architectures, and compare how well the different versions perform under the task constraints. Since the classifier is meant to serve as a module in a practical dialog system, it needs to be able to work with limited training data and incorporate new data on the fly. We devise a 1-shot learning task to test the models under the above constraint. We conclude that relatively simple versions of memory networks perform better than other approaches. Although, for tasks with very limited data, simple non-parametric methods perform comparably, without needing the extra training data.

##### Abstract (translated by Google)

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

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


text:
---
title: MNW Cougars
layout: default
modal-id: 1
date: 2014-07-18
client_slug: mnw
img: mnw-logo.jpg
alt: image-alt
project-date: July 2014
client: MNW Cougars
category: Training
description: Training students at Manson Northwest Webster

---

Tucker's passion for athletic training, organization of workouts, and attention to detail helped our girls basketball team get the best summer results I've seen in my five years of coaching.
- Bret Larson

Starting as the summer strength and conditioning for the Manson Northwest Webster girl’s athletic programs in 2014, I have continued to provide training plans for the MNW girl’s athletic teams during their athletic seasons. Focusing on basic strength and power development, we have seen great improvements in the athletic abilities of our athletes here. Staying in contact with the coaches online has allowed the MNW girl’s teams to keep a more consistent strength and conditioning routine during the year.

    Previous

    Next

repository: sherzberg/tucker

branch_name: HEAD

repo_name: sherzberg/tucker


text:
# Quill composer for NodeBB

This plugin activates the WYSIWYG Quill composer for NodeBB. Please ensure that:

* The markdown plugin is disabled (see note below, re: markdown)
* Any other composers (i.e. nodebb-plugin-composer-default) are disabled
* **Warning** This composer saves its data in a unique format that is only compatible with Quill. If you switch to Quill, any posts made with Quill cannot be migrated back to Markdown.

## Migration concerns

### nodebb-plugin-composer-default/nodebb-plugin-markdown

If you used the default composer, chances are you also had the markdown plugin active. If that is the case, any posts made before the switch are still in markdown format, and are not saved into html (in a manner than quill can digest). A migrator tool has been bundled with v1.1 of the Quill Composer, which you can use to migrate posts in markdown and html into the Quill-compatible format.

### nodebb-plugin-redactor

Your posts should automatically work with Quill. Redactor saves HTML into the database, and the Quill plugin is set up so it can digest that html and backport it to Quill's internal format if the post is edited. That said, when you edit a post originally made in Redactor, you'll see the html tags, which are now extraneous. You can remove them as part of your edit. Alternatively, you can use the bundled migrator to convert posts to the Quill-compatible format.

## Contributors Welcome
This plugin is in its early stages. If you'd like to look at the [documentation](https://quilljs.com/docs/) and add a feature, or take a look at the GitHub Issues and do something from there then please do. All pull requests lovingly reviewed.

## Screenshots

### Desktop

![Desktop](/screenshots/desktop.png)

### Mobile

![Mobile](/screenshots/mobile.png)

repository: msgpo/nodebb-plugin-composer-quill

repo_name: msgpo/nodebb-plugin-composer-quill


text:
## Resubmission
This is a resubmission. In this version I have:
* Added short examples to all exported functions and shortened existing examples. All examples now run locally, on travis-ci, and on Appveyor and in under 5 seconds.

## Test environments
* local macOS / OS X install, R 3.4.1
* ubuntu 12.04 (on travis-ci), R 3.3.2
* win-builder (devel and release)

## R CMD check results
There were 0 ERRORs.

There were 0 WARNINGs.

There were 1 NOTEs.

Maintainer: ‘David Benkeser<EMAIL_ADDRESS>New submission

According to [this](https://mailman.stat.ethz.ch/pipermail/r-devel/2014-March/068497.html), this note is safe to ignore.

## Downstream dependencies
Nothing to report.

## Additional Notes
Initial submission of package, version 1.0.0

repository: guhjy/drtmle

repo_name: guhjy/drtmle


text:
# {r2eng}

ɑː ˈtuː /eng/

[![Project Status: WIP – Initial development is in progress, but there
has not yet been a stable, usable release suitable for the
public.](https://www.repostatus.org/badges/latest/wip.svg)](https://www.repostatus.org/#wip)
[![R build
status](https://github.com/matt-dray/r2eng/workflows/R-CMD-check/badge.svg)](https://github.com/matt-dray/r2eng/actions)
[![codecov](https://codecov.io/gh/matt-dray/r2eng/branch/master/graph/badge.svg)](https://codecov.io/gh/matt-dray/r2eng)
[![Launch Rstudio
Binder](http://mybinder.org/badge_logo.svg)](https://mybinder.org/v2/gh/matt-dray/try-r2eng/master?urlpath=rstudio)
[![rostrum.blog post](https://img.shields.io/badge/rostrum.blog-post-008900?style=flat&labelColor=black&logo=data:image/gif;base64,R0lGODlhEAAQAPEAAAAAABWCBAAAAAAAACH5BAlkAAIAIf8LTkVUU0NBUEUyLjADAQAAACwAAAAAEAAQAAAC55QkISIiEoQQQgghRBBCiCAIgiAIgiAIQiAIgSAIgiAIQiAIgRAEQiAQBAQCgUAQEAQEgYAgIAgIBAKBQBAQCAKBQEAgCAgEAoFAIAgEBAKBIBAQCAQCgUAgEAgCgUBAICAgICAgIBAgEBAgEBAgEBAgECAgICAgECAQIBAQIBAgECAgICAgICAgECAQECAQICAgICAgICAgEBAgEBAgEBAgICAgICAgECAQIBAQIBAgECAgICAgIBAgECAQECAQIBAgICAgIBAgIBAgEBAgECAgECAgICAgICAgECAgECAgQIAAAQIKAAAh+QQJZAACACwAAAAAEAAQAAAC55QkIiESIoQQQgghhAhCBCEIgiAIgiAIQiAIgSAIgiAIQiAIgRAEQiAQBAQCgUAQEAQEgYAgIAgIBAKBQBAQCAKBQEAgCAgEAoFAIAgEBAKBIBAQCAQCgUAgEAgCgUBAICAgICAgIBAgEBAgEBAgEBAgECAgICAgECAQIBAQIBAgECAgICAgICAgECAQECAQICAgICAgICAgEBAgEBAgEBAgICAgICAgECAQIBAQIBAgECAgICAgIBAgECAQECAQIBAgICAgIBAgIBAgEBAgECAgECAgICAgICAgECAgECAgQIAAAQIKAAA7)](https://www.rostrum.blog/2020/11/14/hello-r2eng/)

Make R speakable\!

The goal of {r2eng} (as in ‘R to English’) is to take an R expression
and ‘translate’ it to an English sentence.

The package is intended to:

  - improve communication between teachers and learners
  - make R discussions in English more accessible to non-English
    speakers
  - provide an extra audio evaluation tool for users who are blind or
    have low vision
  - be of interest to any R user that’s curious about how R expressions
    might be vocalised

The project was inspired by [Amelia
McNamara](https://twitter.com/AmeliaMN)‘s useR\! 2020 talk called
’Speaking R’ ([YouTube](https://www.youtube.com/watch?v=ckW9sSdIVAc),
[slides](https://www.amelia.mn/SpeakingR/#1)).

This project is a work in progress and highly opinionated. Contributions
are welcome, but please see the [Code of Conduct](#conduct).

## Installation

You can install the development version of {r2eng} from GitHub with:

``` r
remotes::install_github("matt-dray/r2eng")
```

This package depends on {lintr}, {purrr} and {rlang}.

## Examples

The main function in the package is `translate()`. It uses [non-standard
evaluation](http://adv-r.had.co.nz/Computing-on-the-language.html), so
you pass it a bare R expression like this:

``` r
r2eng::translate(variable <- 1, speak = TRUE)
# Original expression: variable <- 1
# English expression: variable gets 1
```

Set `speak = TRUE` for a system call that will read the English sentence
out loud (macOS only).

A more complex example:

``` r
obj <- r2eng::translate(
  hello <- c(TRUE, FALSE, 'banana' %in% c('apple', 'orange')),
  speak = FALSE
)

obj
# Original expression: hello <- c(TRUE, FALSE, "banana" %in% c("apple", "orange"))
# English expression: hello gets a vector of open paren TRUE , FALSE , string "banana" matches a vector of open paren string "apple" , string "orange" close paren close paren
```

### Methods

An `r2eng` object has the methods `speak` and `evaluate`.

Use `speak` to launch a system call that will vocalise the translated
English sentence for the given R expression (macOS only).

``` r
r2eng::speak(obj)
```

Use `evaluate` to evaluate the expression.

``` r
r2eng::evaluate(obj, speak = FALSE)
hello
# [1]  TRUE FALSE FALSE
```

Use `print` to print the R expression and English sentence.

``` r
print(obj)
# Original expression: hello <- c(TRUE, FALSE, "banana" %in% c("apple", "orange"))
# English expression: hello gets a vector of open paren TRUE , FALSE , string "banana" matches a vector of open paren string "apple" , string "orange" close paren close paren
```

From your r2eng object you can access the original R expression
(`r_expression`), English translation (`eng_expression`), quoted
expression (`quoted_expression`). You can also access the parse tree
output via {lintr} (`translation_map`):

``` r
head(obj$translation_map)
#                   token  text         eng
# 40                 expr
# 1                SYMBOL hello       hello
# 3                  expr
# 2           LEFT_ASSIGN    <-        gets
# 38                 expr
# 4  SYMBOL_FUNCTION_CALL     c a vector of
```

### Further examples

Here’s an example using the pipe (`%>%`) and two types of ‘equals’:

``` r
library(magrittr)
r2eng::translate(
  mtcars %>% filter(mpg > 22) %>% mutate(gear4 = gear == 4),
  speak = FALSE
)
# Original expression: mtcars %>% filter(mpg > 22) %>% mutate(gear4 = gear == 4)
# English expression: mtcars then filter of open paren mpg is greater than 22 close paren then mutate of open paren gear4 = gear double equals 4 close paren
```

This example uses the ‘plus’ constructor from {ggplot2}:

``` r
r2eng::translate(
  ggplot(diamonds, aes(x=carat, y=price, color=cut)) + geom_point() + geom_smooth(),
  speak = FALSE
)
# Original expression: ggplot(diamonds, aes(x = carat, y = price, color = cut)) + geom_point() +
#  Original expression:     geom_smooth()
# English expression: ggplot of open paren diamonds , aes of open paren x = carat , y = price , color = cut close paren close paren plus geom_point of open paren close paren plus geom_smooth of open paren close paren
```

This example shows what happens when you pass vectors:

``` r
r2eng::translate(
  plot(x = c(1, 2, 3), y = c(5, 6, 7)),
  speak = FALSE
)
# Original expression: plot(x = c(1, 2, 3), y = c(5, 6, 7))
# English expression: plot of open paren x = a vector of open paren 1 , 2 , 3 close paren , y = a vector of open paren 5 , 6 , 7 close paren close paren
```

### Passing a string

The `translate()` function understands the meaning of `=` when used for
assignment versus specifying arguments, but feeding an expression such
as `x = c(1, 2, 3)` would confuse `translate()` that you want to pass an
argument `c(1, 2, 3)` to the parameter `x`.

This is because `translate()` uses [non-standard
evaluation](http://adv-r.had.co.nz/Computing-on-the-language.html).

In such cases, you must use `translate_string()` instead:

``` r
r2eng::translate_string("x = c(1, 2, 3)", speak = FALSE)
# Original expression: x = c(1, 2, 3)
# English expression: x gets a vector of open paren 1 , 2 , 3 close paren
```

Another exceptional case for `translate_string()` is when piping and
expression:

``` r
"non_english <- c('ceci n est pas une pipe', 'Ich bin ein Berliner', '我其實唔識講廣東話')" %>%
  r2eng::translate_string(speak = FALSE)
# Original expression: non_english <- c("ceci n est pas une pipe", "Ich bin ein Berliner",
#  Original expression:     "我其實唔識講廣東話")
# English expression: non_english gets a vector of open paren string "ceci n est pas une pipe" , string "Ich bin ein Berliner" , string "我其實唔識講廣東話" close paren
```

## RStudio addin

Installing this package also installs an [RStudio
addin](https://rstudio.github.io/rstudioaddins/).

Select an R expression in the editor and then under ‘Addins’, go to
‘Speak R Expression In English’ under ‘R2ENG’. The selected text will
be spoken by your computer.

You could bind this addin to a keyboard shortcut in RStudio by going to
‘Tools’, then ‘Modify Keyboard Shortcuts…’. Perhaps Cmd +
Shift + V.

As with the rest of this package, vocalisation is only possible for
macOS and with speakers.

Another Addin function is also available, ‘Print R Expression In
English’, which prints a selected R expression and its English
translation

## Contributions and Code of Conduct

Contributions are welcome from everyone. Please first [add an
issue](https://github.com/matt-dray/r2eng/issues) if a relevant one one
doesn’t already exist.

Please note that the {r2eng} project is released with a [Contributor
Code of
Conduct](https://contributor-covenant.org/version/2/0/CODE_OF_CONDUCT.html).
By contributing to this project, you agree to abide by its terms.

gha_language: R

gha_license_id: NOASSERTION


text:
[![Build Status](https://secure.travis-ci.org/cam-technologies/time-booker.png)](http://travis-ci.org/cam-technologies/time-booker) [![Dependency Status](https://david-dm.org/cam-technologies/time-booker.png)](https://david-dm.org/cam-technologies/time-bookerp) [![devDependency Status](https://david-dm.org/cam-technologies/time-booker/dev-status.png)](https://david-dm.org/cam-technologies/time-booker#info=devDependencies) [![Coverage Status](https://coveralls.io/repos/cam-technologies/time-booker/badge.png)](https://coveralls.io/r/cam-technologies/time-booker)
Time-Booker
===========

Web based time booking application, build using the **MEEN** stack. This application will allow users to manually enter work times in blocks of hours and minutes for each day of the week.

[Click here to see it in action!](http://time-booker.herokuapp.com/)

## Technologies Used

* **Client Side:**
    * [EmberJS](http://emberjs.com/)
    * [HTML5](http://www.w3.org/TR/2011/WD-html5-20110525/)
    * [CSS3](http://www.w3.org/TR/2001/WD-css3-roadmap-20010523/)
    * [Bootstrap 3](http://getbootstrap.com/)

* **Server Side:**
    * [NodeJS](http://nodejs.org/)
    * [ExpressJS](http://expressjs.com/)
    * [Stylus](http://learnboost.github.io/stylus/)
    * [Socket.IO](http://socket.io/)

* **Development & Deployment:**
    * [Gulp](http://gulpjs.com/)
    * [Bower](http://bower.io/)
    * [Travis CI](https://travis-ci.org/)

* **Test:**
    * [Qunit](http://qunitjs.com/)
    * [Karma](http://karma-runner.github.io/)
    * [Phantom](http://phantomjs.org/)
    * [Selenium](http://www.seleniumhq.org/)

## Directory Layout

**Development:**

    time-booker/
      |- client/                --> all client code
      |  |- src/                    --> client source code files
      |  |  |- app/                     --> ember.js app code
      |  |  |- assets/                  --> static files like fonts, images, fonts
      |  |  |  |- fonts/                    --> fonts
      |  |  |  |- images/                   --> image files
      |  |  |  |- styles/                   --> css & sass files
      |  |  |- vendor/                  --> 3rd party client and test libraries
      |  |  |- index.html               --> app main file
      |  |  |- favicon.ico              --> favicon icon
      |  |- test/                   --> client test code
      |  |  |- config/                  --> configuration files for unit (karma) and e2e (protactor) tests
      |  |  |- e2e/                     --> e2e test files
      |  |  |- unit/                    --> unit test files
      |  |- .jshintrc               --> JavaScript code quality tool for client code
      |- server/                --> all server code
      |  |- src/                    --> server source code files
      |  |- test/                   --> server test code
      |  |  |- config/                  --> configuration files for unit (karma) test
      |  |  |- unit/                    --> unit test files
      |  |- .jshintrc               --> JavaScript code quality tool for server code
      |- .bowerrc               --> specify where bower dependencies should be installed
      |- .editorconfig          --> define and maintain consistent coding styles between different editors
      |- .gitignore             --> specify directories and files to be to ignored by git
      |- bower.json             --> specify client site dependencies
      |- CHANGELOG.md           --> record of changes made to a project
      |- gulpfile.js            --> front-end and JavaScript workflow tasks runner
      |- package.json           --> specify module npm dependencies
      |- README.md              --> summary of the project

**Build:**

    build/
      |- dist                       --> distribution source code that goes to production
      |  |- client/                     --> client code
      |  |  |- assets/                    --> emberJS-agnostic presentation artifacts
      |  |  |  |- fonts/                     --> fonts
      |  |  |  |- images/                    --> image files
      |  |  |  |- styles/                    --> css files
      |  |  |     |- app.min-12345.css          --> concat & minify app css files
      |  |  |     |- lib.min-12345.css          --> concat & minify 3rd party lib css files
      |  |  |- scripts/                   --> js files
      |  |  |  |- app.min-12345.js           --> concat, minify angular app js files and cached html templates
      |  |  |  |- lib.min-12345.js           --> concat & minify 3rd party lib js files
      |  |  |- index.html                 --> app main file
      |  |- server/                     --> server code
      |- docs/                      --> app documentation
      |- test-reports/              --> app test-reports (coverage, failure screenshots etc.)

## Installation & Configuration

### Platform & tools

You need to install Node.js and then the development tools. Node.js comes with a package manager called
[npm](http://npmjs.org) (requires npm version >= 1.3.0 for this project) for installing NodeJS applications and libraries.
Note you should run these commands as admin.
* [Install node.js](http://nodejs.org/download/) (requires node.js version >= 0.10.0)
* [Install Gulp](http://gulpjs.com/) as global npm modules (requires node.js version >= 0.10.0):

    ```bash
    $ npm install -g gulp
    ```

* [Install Bower](http://http://bower.io/) as global npm modules (requires node.js version >= 0.10.0):

    ```bash
    $ npm install -g bower
    ```
* [Install Migrate](https://github.com/visionmedia/node-migrate) as global module.
    ```bash
    $ gulp migrate
    ```

### App
Run the following commands to download Time-Booker app:
    ```
    git clone git@github.com:cam-technologies/time-booker.git
    ```

* Install local dependencies:

    ```bash
    $ npm install
    $ gulp install
    ```
* Make sure all [bower](bower.json) dependencies are added to [index.html](client/src/app/index.html) after ```gulp wiredep``` task was executed:

    ```HTML
    <!-- bower:css -->
       <link rel="stylesheet" href=".."/>
    <!-- endbower -->
    <!-- bower:js -->
       <script src=".."></script>
    <!-- endbower -->
    ```

> **Note:** Verify that all 3rd party dependencies from [package.json](package.json) and [bower.json](bower.json) are installed on your local machine. If you have followed the instructions and there have been no errors when executing the above commands, the dependencies should be installed.

* Apply al database migrations

    ```bash
    $ migrate
    ```

## Running App

### Start the Server (development env)
* Run the server:

    ```bash
    $ node server/src/server.js
    ```

* Browse to the application at [http://localhost:3000](http://localhost:3000)

### Start the Server (production env)
* Run the server:

    ```bash
    $ gulp build
    $ cd build/dist
    $ npm install --production
    $ NODE_ENV=production node server/server.js
    ```

* Browse to the application at [http://localhost:5000](http://localhost:5000)

## Gulp tasks
The best way to learn about the gulp tasks is by familiarizing yourself with [Gulp](http://gulpjs.com/) and then reading through the documented [gulpfile.js](gulpfile.js) script.

###Sub Tasks:###
| Command                          | Description |
| -------------------------------- | ----------- |
| `gulp clean` | will delete `build` and `client/src/tmp` directories |
| `gulp copy` | will copy project files that haven't been copied by 'compile' task e.g. (fonts, etc.) into 'build' folder |
| `gulp csslint` | will run linter against css files in `client/src/assets/styles` |
| `gulp jshint:client` | will run linter against client javascript files |
| `gulp jshint:server` | will run linter against server javascript files |
| `gulp htmlhint` | will run linter against html files |
| `gulp images` | will minify images `client/src/assets/images` |
| `gulp templates` | |
| `gulp bower` | will install all bower components specify in [`bower.json`](bower.json) from bower repository |
| `gulp bower-install`    | will do the same as `bower` task but also inject bower components to [`index.html`](client/src/index.html) |
| `gulp watch` |  will watching for file changes and run linter tasks against specific files, in addition browser will be refreshed with every change |
| `gulp compile` | will concatenate, minify, cdnize and revesion sources and place them by default into the `build/dist` directory |
| `gulp webdriver_update` | will update/install the selenium webdriver |
| `gulp help` | will print all tasks with description of each task |

###Main Tasks:###
The main gulp tasks are descriptive more in `development`, `test`, `build` and `release` sections.

| Command                          | Description |
| -------------------------------- | ----------- |
| `gulp install` | will install bower dependencies and generate config-env.js file |
| `gulp` | will run default task that watches for changes and run `jshint`, `csslint`, `htmlhint` |
| `gulp test:e2e` | will run e2e tests |
| `gulp test:unit` | will run unit tests |
| `gulp test` | will run both the e2e and unit test tasks |
| `gulp build` | will create build that is ready for uploading to the server |
| `gulp bump` | will increment version number in [`package.json`](package.json) and [`bower.json`](bower.json)|
| `gulp changelog` | will generate changelog in [`CHANGELOG.md`](CHANGELOG.md) |
| `gulp release` | will release and push [`package.json`](package.json) and [`CHANGELOG.md`](CHANGELOG.md) to GitHub repo |
| `gulp migrate` | will run the data base migrations |

## Development
Whenever you're working on project, start with:

```bash
$ gulp
```
This default gulp task will install bower dependencies, build dev enviroment, monitor the source files and run `compass`, `jshint` and `htmlhint` tasks every time a file changes. The default gulp task also includes [Live Reload](http://livereload.com/), so you no longer have to refresh your page after making changes! The following code must be add to the end of the `body` tag in [index.html](public/index.html):

```html
<script src="http://localhost:35729/livereload.js?snipver=1"></script>
```

## Test
App test-reports (coverage, failure screenshots etc.) can be found under `build/test-reports/` directory.

* **Unit test examples:**

   This will run test against `PhantomJS` and code specify in `src/` folder:
   ```bash
   $ gulp test:unit
   ```
   This will run test against `Chrome` and code specify in `build/dist/` folder:
   ```bash
   $ gulp test:unit --browsers=Chrome --env=production
   ```
   To run test against multiple browsers at the same time run follow task:
   **TODO: (martin)** this task is not supported yet!
   ```bash
   $ gulp test:unit --browsers=Chrome,Firefox,Safari
   ```
   > NOTE: Verify that the browsers you want to run test against are installed on your local machine. The `PhantomJS` should be already installed after you run `npm install`.

* **E2E test:**

   The E2E tests will run via the qunit test runner via the bowser or gulp
   ```bash
   $ gulp test:e2e
   ```
   Running via the browser:
   open testRunner.html in your browser and the tests will run, when running the tests in the browser you will need to clear the local storage after every run.
   Open the browser console and run the following:
   ```javascript
   localStorage.clear();
   ```

## Build
The build task get app ready for production. The build task include test:unit, test:e2e, concatenation, minification, compression, cdn etc. If there have been no errors when executing the build command, the build should be located in `build/dist` directory and this build is ready for uploading to the server!. To initiate a full build, you simply run the follow task:
```bash
$ gulp build
```

If for some reason you don't want to run the test but just generate the files - **not a good idea(!!)** - you can simply run the build task with argument `--notest`:
```bash
$ gulp build --notest
```

## Release

> Before releasing make sure there is no failing Jenkins build for this project. During the release process only [`package.json`](package.json) and [`CHANGELOG.md`](CHANGELOG.md) files should be edited and all steps should be done with **gulp tasks** and **not manually**!

- Almost all of the logic for releasing this project is done on the Jenkins server
- To push a new release:
  1. Update [`package.json`](package.json) version to new version with `gulp bump --type=(major|minor|patch)`
  2. Generate changelog with `gulp changelog`
  3. Go through the changelog, and fix any mistakes or clarify any unclear commit messages
  4. Commit and push [`package.json`](package.json) and [`CHANGELOG.md`](CHANGELOG.md) with `gulp release`
- Jenkins will detect that this commit changed the version in [`package.json`](package.json) and push out all necessary for this new release (tags, publish to private npm, etc ...)

## Commit Conventions
Use these [commit conventions](https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit) to generate a changelog from git metadata. Some example output can be found [here](https://github.com/driftyco/ionic/blob/master/CHANGELOG.md).

## Versioning

Releases will be numbered with the following format:

`<major>.<minor>.<patch>`

And constructed with the following guidelines:

* Breaking backward compatibility bumps the major (and resets the minor and patch)
* New additions without breaking backward compatibility bumps the minor (and resets the patch)
* Bug fixes and misc changes bumps the patch

For more information on SemVer, please visit <http://semver.org/>.

## Database Migrations
    * Create new migration
    ```bash
    $ migrate create <migration name>
    ```

For more information please visit <https://github.com/visionmedia/node-migrate>

Development Principles
----------------------

+ Time Booker will be developed using responsive web design techniques
+ Time Booker will be developed using suitable JavaScript and CSS frameworks
+ Time Booker will be developed in a manner that does not tie it to one specific database type
+ Time Booker will be developed in line with modern web architectural patterns
+ Time Booker will be developed in a manner that will support the addition of mobile clients in the future
+ Time Booker will be developed using Test Driven Development (TDD)
+ Time Booker will be developed using Continuous Integration, Delivery & Deployment
+ Time Booker will be developed in a manner that will support public cloud deployment
+ Time Booker will be developed using freely available tools and frameworks
+ Time Booker will be developed using tools and frameworks that are not tied to a single platform (e.g. Windows)

Contributing Code
-----------------

Time Booker follows the [Fork & Pull](https://help.github.com/articles/using-pull-requests) model
for collaborative development.

Authors
-------
[![Martin Micunda] (http://www.gravatar.com/avatar/5bce24c9beed55aaee9feca545defb8e.png?s=144)](https://github.com/martinmicunda) | [![Christopher Laughlin] (http://www.gravatar.com/avatar/2ff062148633bce06aa972be0ff1c244.png?s=144)](https://github.com/chrislaughlin) | [![Andrew McDowell] (http://www.gravatar.com/avatar/2ff06214863ce06aa972be0ff1c244.png?s=144)](https://github.com/madole)
:---:|:---:|:---:
[Martin Micunda] (https://github.com/martinmicunda) | [Christopher Laughlin] (https://github.com/chrislaughlin) | [Andrew McDowell] (https://github.com/madole)

## License
The MIT License (MIT)

Copyright (c) 2014 C.A.M. Technologies

Permission is hereby granted, free of charge, to any person obtaining a copy of
this software and associated documentation files (the "Software"), to deal in
the Software without restriction, including without limitation the rights to
use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of
the Software, and to permit persons to whom the Software is furnished to do so,
subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

 IN NO EVENT SHALL THE AUTHORS OR
COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER
IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

repository: madole/time-booker

repo_name: madole/time-booker


text:
# Power Management

With the USB tester plug I measured the following currents for the different BeachHub
devices. As all devices are powered with USB connectors the voltage is 5V in all cases.

Device                  | Min    | Max
----------------------- | ------ | ------
Router (not charging)   | 0.25 A | 0.45 A
Raspberry Pi 3 B+       | 0.38 A | 0.75 A
Mini Fan                | 0.12 A | 0.16 A

--> You can quantify power requirements of any specific device you have with lsusb -v and the MaxPower property.

## Bad Cables

It turned out that some of the USB cables I tested cause such a significant voltage
drop that the Raspberry Pi goes off. To avoid such surprises I checked all cables
used in BeachHub with the USB tester:

1. Find a constant and strong power source (charger or large power bank)
2. Connect a heavy load (empty smart phone oder battery back) with a the USB tester
   to the power source. Write down the voltage shown by the tester.
3. Now insert the cable in question between the power source and the USB tester.
   Note the voltage shown now.

If the voltage is decreased by more that 0.2V or the voltage measured in step 3
is less than 4.8V you can't run a Raspberry Pi reliable on this cable.

## Under Voltage

If the supplied voltage is too low the CPU gets throttled. With the following command you can check whether this or was the case:

    vcgencmd get_throttled

The bits in the returned integer have the following meanings:

| Bit | Meaning |
|:---:|---------|
| 0   | Under-voltage detected |
| 1   | Arm frequency capped |
| 2   | Currently throttled |
| 3   | Soft temperature limit active |
| 16  | Under-voltage has occurred |
| 17  | Arm frequency capped has occurred |
| 18  | Throttling has occurred |
| 19  | Soft temperature limit has occurred |


text:
# Open targets internal deployment guide

## Overview

Using project: `open-targets-genetics-dev`.

Currently the genetics team provides input files in a GCP bucket `gs://genetics-portal-dev-staging` (`staging`). Some of
these files are static, others are annotated with a date (variously YYMMDD and DDMMYY).

A _subset_ of these files are then _manually_ copied by the BE team to `gs://genetics-portal-dev-data` (`dev`) in a
bucket corresponding to the release.

The files in `dev` are used to run the pipeline, typically using Dataproc.

| Configuration field | Likely staging location | Standard dev location |
| --- | --- | --- |
| `variant-index.raw` | *provided by data team* | /variant-annotation/<date>/variant-annotation.parquet |
| `ensembl.lut` | *generated by BE* | /lut/homo_sapiens_core_105_38_genes.json.gz |
| `vep.homo-sapiens-cons-scores` | *should be in staging bucket* | /lut/vep_consequences.tsv |
| `interval.path` |v2g/interval/\* | /v2g/interval/\*/\*/\<date\>/data.parquet |
| `qtl.path` | v2g/qtl/\<date\>/ | v2g/qlt/\<date\> |
| `variant-disease.studies` | v2d/\<date\>/studies.parquet | v2d/studies.parquet |
| `variant-disease.toploci` | v2d/\<date\>/toploci.parquet | v2d/toploci.parquet|
| `variant-disease.finemapping` | v2d/\<date\>/finemapping.parquet/ | v2d/finemapping.parquet |
| `variant-disease.ld` | v2d/\<date\>/ld.parquet/ | v2d/ld.parquet |
| `variant-disease.overlapping` | v2d/\<date\>/locus_overlap.parquet | v2d/locus_overlap.parquet |
| `variant-disease.coloc` | coloc/\<date\>/coloc_processed_w_betas.parquet/ | v2d/coloc_processed_w_betas.parquet |
| `variant-disease.trait_efo` | v2d/\<date\>/trait_efo-2021-11-16.parquet | v2d/trait_efo.parquet |

### Variant index section

The variant index comes in parquet _from the data team_ after filtering the latest Gnomad release.

If there is no new update keep using the last one used. Currently, the variant annotation is version 190129.

### Ensembl

Genetics team do not provide the Ensembl file: we have to download it ourselves and generate the input.

It is a configuration place to bring the latest reference gene table from Ensembl. To generate this file to need to
follow the instructions [from this script](https://github.com/opentargets/genetics-backend/tree/master/makeLUTs). And
the command I use is this as an example

```python create_genes_dictionary.py -o "./" -z -n homo_sapiens_core_104_38```

The above example uses Ensembl '104'. The most recent version is '105'. If the versions have not changed from the
previous release feel free to copy the input file from the previous releases' input directory.

### VEP consequences

The TSV file is provided by the _genetics team_. If the file is not present in the staging bucket ask the Genetics team
for the most recent version.

### Interval

Provided by the genetics team: these are mainly static and haven't been updated for years. They are in a nested file
structure which _must be preserved_ because the ETL uses the file path as an input.

### QTL

Provided by the genetics team: these are updated on a regular basis.

### Recipe: set up deployment machine

We need a VM to run deployments from. Typically this only needs to be done once and then we can use the machine for
future releases.

```bash
# install dependencies
sudo apt-get install -y apt-transport-https ca-certificates dirmngr
sudo apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv 8919F6BD2B48D754

echo "deb https://packages.clickhouse.com/deb stable main" | sudo tee \
    /etc/apt/sources.list.d/clickhouse.list
sudo apt-get update

sudo apt-get install -y clickhouse-client

sudo apt install -y git \
tmux tree wget htop \
libgl1-mesa-glx libegl1-mesa libxrandr2 libxrandr2 libxss1 libxcursor1 libxcomposite1 libasound2 libxi6 libxtst6 \
apt-transport-https ca-certificates dirmngr

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh -O ~/miniconda.sh
bash ~/miniconda.sh -p $HOME/miniconda
source ~/.bashrc

# get repositories
git clone https://github.com/opentargets/genetics-backend.git
git clone https://github.com/opentargets/genetics-pipe.git

# set up conda environments
cd genetics-backend && conda env create -f environment.yaml
conda activate backend-genetics
# add elastic-search loader
# https://github.com/moshe/elasticsearch_loader
pip install elasticsearch-loader

cd loaders/clickhouse

```

### Recipe: get all inputs and run the ot-geckopipe

Use the VM in the `open-target-genetics-dev` machine called `gp-deploy`. The VM is preconfigured with the necessary
utilities to run a release.
- [ ] start deployment machine: `gcloud compute instances start "jb-release" --project "open-targets-genetics-dev" --zone "europe-west4-a"`
- [ ] SSH into deployment machine: `gcloud compute ssh --zone "europe-west4-a" "jb-release"  --tunnel-through-iap --project "open-targets-genetics-dev"`
- [ ] If not already done, clone required repository: `git clone git@github.com:opentargets/genetics-backend.git`
- [ ] set up environment: `conda activate backend-genetics`
- [ ] update Ensembl version (latest 106 Apr 22) and run script from `genetics-backend/makeLUTs`:
  - `python create_genes_dictionary.py -o "./" -z -n homo_sapiens_core_106_38`
- [ ] add ensembl file to bucket `gsutil cp -n homo_sapiens* gs://genetics-portal-dev-data/22.03/inputs/lut/`
- [ ] update variables in bash script in `/scripts/prepare_inputs.sh` (input script)
- [ ] run input script in VM to move files from staging to dev buckets
    - Most of the inputs are used for the pipeline, but there are two static datasets which are copied, sumstats (sa)
      and `v2d_credset`.
    - It's to pipe the STDOUT of the script to a file which can be provided to the genetics/data team for
      confirmation the correct files were used. `./scripts/prepare_inputs.sh >> genetics_input_log.txt`
- [ ] create a configuration file for release in `config`:
    - [ ] `cp src/main/resources/application.conf config/<release>.conf` and update as necessary.
- [ ] Run genetics-pipe. There are two options here, you can use either a Dataproc workflow (requires Scala) or
  using bash scripts. The former is easier.
  - [ ] __Workflow option__: Open the worksheet `scripts/dataproc-workflow.sc`, update top level variables (should
    only be the input and output directories) and run. You can terminate the worksheet on your local machine once it
    has started since Dataproc will run in the background. The advantage of using the workflow is that Dataproc will
    create the specified cluster, run the steps in the right order, then destroy the cluster without the need for
    any manual intervention.
  - [ ] __Script options:__:
    - [ ] update top level variables in `scripts/run_cluster.sh`: `release` and `config` should be the only changes
    necessary.
    - [ ] run script `scripts/run_cluster.sh` from root directory. This script builds a jar file, pushes it to GS
      storage, starts a cluster and runs all steps. Some of the jobs will fail because of missing dependencies. Consult
      `documentation/step_dependencies` for the correct order.
       - In general run in the following phases (some steps can be run concurrently):
          - variant-index (30m), variant-gene (180min)
          - dictionaries, variant-disease (2min), variant-disease-coloc (2min)
          - disease-variant-gene (25min)
          - scored datasets (130min)
          - manhattan (25min) (Run this _after_ the following steps)
- [ ] inform genetics team that the outputs are ready, and they will run the ML pipeline to generate the `l2g`
  outputs. The file we need for the final step (`manhattan`) is typically found under
  `genetics-portal-dev-staging/l2g/<date>/predictions/l2g.full.220128.parquet` in the staging area.
- [ ] Copy L2G file from the staging area to the development area (updating dates as necessary): `gsutil -m cp -r
  gs://genetics-portal-dev-staging/l2g/220212/predictions/l2g.full.220212.parquet/part-*
  gs://genetics-portal-dev-data/22.03/outputs/l2g/`
- [ ] Run the `manhattan` step using either scripts for the workflow `scripts/dataproc-workflow-manhattan.sc`. Note
  that the workflow assumes all prior steps have been completed and the inputs are available.
- [ ] Check all the expected output directories are present using the ammonite script `amm scripts/check_outputs.sc`.

### Recipe to create infrastructure

- [ ] Using the [genetics backend project](https://github.com/opentargets/genetics-backend.git) start two VMs: one each
  for ES and Clickhouse using the helper scripts: `infrastructure/gcp/genetics/create-clickhouse-node.sh` and
  `infrastructure/gcp/genetics/create-elasticsearch-node.sh`
- [ ] export variables for the two created VMs:(bind the internal GCP IP address, this assumes you're in a GCP VM yourself.)
  - `export ES_HOST=$(gcloud compute instances list | grep -i run | grep elasticsearch | awk '{ print $4 }' | tail -1)`
  - `export CLICKHOUSE_HOST=$(gcloud compute instances list | grep -i run | grep clickhouse | awk '{ print $4 }' | tail -1)`
- [ ] activate the correct python environment: `conda activate backend-genetics`
- [ ] run the script `loaders/clickhouse/create_and_load_everything_from_scratch.sh` in the `genetics-backend`
  repository, providing a link to the input files.
  - There can be a short delay while the instances start up and complete their installations of ES and CH. You can
    test if they are ready by running `curl $ES_HOST:9200` and `curl $CLICKHOUSE_HOST:8123` which should both return
    a non-error response.
  - Note this process is slow: ~17 hours!
  - `./create_and_load_everything_from_scratch.sh gs://genetics-portal-dev-data/22.01.2/outputs`
- [ ] Once loading is complete, 'bake' the instances so that we can deploy the images using Terraform.
  - Find the latest running image: `gcloud compute instances list --project=open-targets-genetics-dev | grep -i run |
    grep [elasticsearch|clickhouse] | awk '{ print $1 }' | tail -1`
  - Bake image using scripts in `genetics-backend/gcp/bake_[es|ch]_node.sh` with the image found above. These create
    disk images which we can deploy using the Terraform defined in the [genetics terraform repo](https://github.com/opentargets/terraform-google-genetics-portal)
     - For example:
       - `./bake_ch_node.sh $(gcloud compute instances list --project=open-targets-genetics-dev | grep -i
       run | grep clickhouse | awk '{ print $1 }' | tail -1)`
       - `./bake_es_node.sh $(gcloud compute instances list --project=open-targets-genetics-dev | grep -i run | grep elasticsearch | awk '{ print $1 }' | tail -1)`

#### Sanity checks

- You should check the size of the images and counts in ES and Clickhouse to get an idea of whether there were any
  problems in loading the data.
- Clickhouse:
  - SSH into image: `gcloud compute ssh --zone "europe-west1-c" "devgen2202-ch-11-clickhouse-gc34"  --tunnel-through-iap --project "open-targets-genetics-dev" -- -L 8123:localhost:8123`
  - Execute the following command (using either Clickhouse-client or another DB manager) to get counts:

```
SELECT table,
sum(rows) as rows,
formatReadableSize(sum(bytes)) as size
FROM system.parts
WHERE active
GROUP BY table;
```
The database in the 22.02 release shows:
```
┌─table──────────────────┬───────rows─┬─size───────┐
│ genes                  │      19569 │ 3.59 MiB   │
│ studies                │      50719 │ 2.08 MiB   │
│ variants               │   72858944 │ 5.41 GiB   │
│ v2d_by_stchr           │   20488888 │ 323.71 MiB │
│ v2d_sa_gwas            │  582828390 │ 29.51 GiB  │
│ v2g_structure          │          9 │ 3.40 KiB   │
│ v2d_coloc              │    4458533 │ 306.86 MiB │
│ l2g_by_gsl             │    3580861 │ 155.29 MiB │
│ v2d_credset            │   38834105 │ 1.34 GiB   │
│ v2d_by_chrpos          │   20488888 │ 414.83 MiB │
│ manhattan              │     279116 │ 44.22 MiB  │
│ v2g_scored             │<PHONE_NUMBER> │ 20.09 GiB  │
│ d2v2g_scored           │<PHONE_NUMBER> │ 41.05 GiB  │
│ studies_overlap        │   14570115 │ 154.52 MiB │
│ l2g_by_slg             │    3580861 │ 168.87 MiB │
│ v2d_sa_molecular_trait │  442006706 │ 14.63 GiB  │
└────────────────────────┴────────────┴────────────┘
```
As far as I know, we would not expect order of magnitude changes.

#### Updating Terraform XYZ

Using the [genetics terraform repository](ttps://github.com/opentargets/terraform-google-genetics-portal):

> For this use the master branch and remember to pull changes from the remote before making your changes

- [ ] Create a new profile which will define the deployment.
  - `cp profiles/deployment_context.devgen2111 profiles/deployment_context.devgen<release>`
  - Update the release tag above, and change `2111` to match the most recent release number to minimise the number
    of changes we need to make.
- [ ] Update the configuration in the `devgen` file created above. To see what fields are often changed you can look
  at the difference between previous releases with the command `diff deployment_context.devgen2111
  deployment_context.devgen2106`. Fields that typically always need updating:
    - `config_release_name`: matches the context file name suffix
    - `config_dns_subdomain_prefix`: same as `config_release_name`
    - `config_vm_elastic_search_image`: Image you baked earlier
    - `config_vm_clickhouse_image`: Image you baked earlier
    - `config_vm_api_image_version`: latest API. From the [API repository](https://github.com/opentargets/genetics-api)
      run `git checkout master && git pull && git tag --list` to see options. It's typically the last one.
    - `config_vm_webapp_release`: this will be the latest tagged version of the the [web app](https://github.com/opentargets/genetics-app)
    - `DEVOPS_CONTEXT_PLATFORM_APP_CONFIG_API_URL`: update URL to include `config_release_name`.
- [ ] Activate `xyz` profile
  - `make tfactivate profile=xyz`
- [ ] Set remote backend (so multiple users can share state)
  - `make tfbackendremote`
- [ ] Activate the deployment context you configured earlier.
  - `make depactivate profile=devgen<release>`
- [ ] Download all dependencies
  - `make tfinit`
- [ ] Check for existing Terraform state (things that are already deployed)
  - `terraform state list`. If this is the first time running these commands nothing will be displayed. After you
    have deployed the infrastructure running this command will show you what is currently available.
- [ ] Inspect the plan: `make tfplan`. This will show you what Terraform plans to do
- [ ] Execute the plan: `make tfapply`. Terraform will ask for confirmation of the changes.
- [ ] Push your deployed changes to github so others can use them if necessary: `git add profiles/deployment_context.
  devgen<release> && git commit -m "Deployment configuration for <release>" && git push`

### Recipe: Big Query

This step assumes that you have generated/collected all of the data as specified in the "get all inputs and run the
ot-geckopipe" recipe.

- [ ] If you don't have it already, clone the [genetics output support repository](https://github.com/opentargets/genetics-output-support)
- [ ] Update the variables under heading `Variables for sync data` in the `config.tfvars` file.
- [ ] Run the shell command `make bigquerydev`

| Configuration field | Staging location (raw data from point of view of data joining) | Dev location for running data-joining | Notes |
| --- | --- | --- | --- |
| `variant-index.raw` | *provided by data team* | /variant-annotation/<date>/variant-annotation.parquet | Copied from release to release, not updated since 2019 |
| `ensembl.lut` | *generated by BE* | /lut/homo_sapiens_core_105_38_genes.json.gz | This will be deprecated once we can use the Target Index from the ETL |
| `vep.homo-sapiens-cons-scores` | *recycled from previous release* | /lut/vep_consequences.tsv | Copied from previous release |
| `interval.path` |v2g/interval/\* | /v2g/interval/\*/\*/\*/data.parquet | Effectively static as we don't regenerate it. This has one of those annoying name.parquet components, but it's heavily nested and we can read a number higher level with a wildcard. |
| `qtl.path` | v2g/qtl/YYMMDD/ | v2g/qtl/ |
| `variant-gene.weights` | *carried over from previous release* | lut/v2g_scoring_source_weights.date.json | Copied from previous release: will be moved into ETL config in future |
| `variant-disease.studies` | v2d/YYMMDD/studies.parquet | v2d/studies.parquet | Single file |
| `variant-disease.toploci` | v2d/YYMMDD/toploci.parquet | v2d/toploci.parquet| Single file |
| `variant-disease.finemapping` | v2d/YYMMDD/finemapping.parquet/ | v2d/finemapping | We want the input renamed to get rid of the '.parquet' component |
| `variant-disease.ld` | v2d/YYMMDD/ld.parquet/ | v2d/ld.parquet | We want the input renamed to get rid of the '.parquet' component |
| `variant-disease.overlapping` | v2d/YYMMDD/locus_overlap.parquet | v2d/locus_overlap.parquet | Single file |
| `variant-disease.coloc` | coloc/YYMMDD/coloc_processed_w_betas.parquet/ | v2d/coloc_processed_w_betas.parquet |
| `variant-disease.trait_efo` | v2d/YYMMDD/trait_efo-2021-11-16.parquet | v2d/trait_efo.parquet | We want 'trait_efo' to not have the embedded date, as that is in the file path |

repository: thehyve/genetics-pipe

gha_language: Scala

repo_name: thehyve/genetics-pipe


text:
procure
=======
[![Build Status](https://travis-ci.org/martindale/procure.svg)](https://travis-ci.org/martindale/procure)
[![Coverage Status](https://coveralls.io/repos/martindale/procure/badge.png?branch=master)](https://coveralls.io/r/martindale/procure?branch=master)

transport-agnostic file procurer

# Quick Start
```javascript
var procure = require('procure');

procure('README.md', function(err, content) {
  // content read from local file...
});

procure('http://www.google.com', function(err, webpage) {
  // content read over HTTP, unparsed HTML provided
});

procure('https://api.github.com/repos/martindale/maki/releases', function(err, releases) {
  // content is a JSON array of releases
});

```

Test coverage can be measured with a simple `npm run coverage`.

repository: martindale/procure

gha_language: JavaScript

repo_name: martindale/procure


text:
# Weather service

Proxies and transforms external weather service data

## Technologies

- .NET Core

# Usage

## By ZIP code (U.S. only)

```http://localhost/api/weather/XXXXX```

## By longitude and latitude

```http://localhost/api/weather?lat=XX.XXXX&lon=XX.XXXX```

# Cloud environments

## Docker

```bash
docker build weather --tag tracking/weather
export WEATHER__URL='yourWeatherEndpointURL'
export WEATHER__IDENTIFIER='yourWeatherEndpointUserIdentifier'
export WEATHER__KEY='yourWeatherAPIKey'
docker run -p 8080:80 tracking/weather
```

Notice there are two underscores in the environment variable names. The URL is mandatory. The identifier and key
are optional.

repository: bhanafee/tracking

repo_name: bhanafee/tracking


text:
# NLMVis
A tool to visualize language models; preleminary experiments so far.

### Usage

Prepare the data using notebooks in ./pp

1) Split and pack data
2) Preprocess

Run the baselines in ./baselines

1) Use notebooks in ./pp for additional preprocessing, if necessary
2) Run the baselines in the notebooks

Top baseline with no balancing of the data or any special tricks, just base TfIdf is **NB-SVM** (variation of J. Howard's kaggle implementation for multi-label problems):

```
accuracy_score: 0.371

roc_auc_score: 0.766

hamming_loss:   0.221
```

### Run main experiments in .

1) Preprocess using respective notebooks in '.', if needed
2) Train/finetune language models
3) Train classifiers

### TODO: Visualize using tools in 'vis'

repository: arjunnlp/NLMVis

repo_name: arjunnlp/NLMVis


text:
Vanilla JS Custom Element Examples
============

## About

This project demonstrates several different ways to create custom elements in vanilla javascript.

## Dependencies

The latest version of Chrome.

## Demo

[Class Based Custom Element](https://coderfin.github.io/custom-element/class)

[Reflect (Class-less) Based Custom Element](https://coderfin.github.io/custom-element/reflect)

[Register Element (Depricated)](https://coderfin.github.io/custom-element/register-element)

## Notes

Class based custom elements are currently the suggested way to create new custom elements.  Register element is the old way of creating custom elements and should not be used.  Reflect is an interesting way of creating custom elements without using classes.

## License

Created by [coderfin](https://github.com/coderfin).
This code is licensed under the MIT style license found as part of this project.

## Changelog
- Initial Release

repository: coderfin/custom-element

repo_name: coderfin/custom-element


text:
## Task-manager MERN project

### Frontend run

To start frontend application use this commands

```
$ cd client
$ yarn
$ yarn start
```

### Backend run

To start backend application use this commands

```
$ yarn
$ yarn server
```

### Env file

Add your mongodb URI and secret word.
Look .env.example

repository: knezewski/taskManagerMERN

repo_name: knezewski/taskManagerMERN


text:
---
layout: post
title: "NM-Net: Mining Reliable Neighbors for Robust Feature Correspondences"
date: 2019-03-31 01:50:37
categories: arXiv_CV
tags: arXiv_CV
author: Chen Zhao, Zhiguo Cao, Chi Li, Xin Li, Jiaqi Yang
mathjax: true
---

* content
{:toc}

##### Abstract
Feature correspondence selection is pivotal to many feature-matching based tasks in computer vision. Searching for spatially k-nearest neighbors is a common strategy for extracting local information in many previous works. However, there is no guarantee that the spatially k-nearest neighbors of correspondences are consistent because the spatial distribution of false correspondences is often irregular. To address this issue, we present a compatibility-specific mining method to search for consistent neighbors. Moreover, in order to extract and aggregate more reliable features from neighbors, we propose a hierarchical network named NM-Net with a series of convolution layers taking the generated graph as input, which is insensitive to the order of correspondences. Our experimental results have shown the proposed method achieves the state-of-the-art performance on four datasets with various inlier ratios and varying numbers of feature consistencies.

##### Abstract (translated by Google)

##### URL
[http://arxiv.org/abs/1904.00320](http://arxiv.org/abs/1904.00320)

##### PDF
[http://arxiv.org/pdf/1904.00320](http://arxiv.org/pdf/1904.00320)


text:
---
title: "0. Install Requirements"
description: "Install Node.js to get started with Doks."
lead: "Install Node.js to get started with Doks."
date: 2020-11-18T08:20:35+01:00
lastmod: 2020-11-18T08:20:35+01:00
draft: false
images: []
menu:
  tutorial:
    parent: "tutorial"
weight: 020
toc: true
---

## Node.js

Doks uses npm to centralize dependency management, making it [easy to update]({{< relref "how-to-update" >}}) resources, build tooling, plugins, and build scripts:

- Download and install [Node.js](https://nodejs.org/) (it includes npm) for your platform.

{{< alert icon="👉" text="Check that you minimally have installed the latest long term support (LTS) version of Node.js, by running node --version in your terminal." />}}

### Check Node.js install

```bash
node --version
```

### Check npm install

```bash
npm --version
```


text:
Ketchup
===========

**Ketchup** is a mod for [Kerbal Space Program][ksp] which implements a programmable CPU and associated devices.

Description
---------------
The CPU is an implementation of the [DCPU-16][dcpu] [spec][dcpu-spec], originally designed by
[Markus "Notch" Persson][notch] for the game [0x10c][0x10c]. Emulation of the CPU is provided by the
[Tomato][tomato] library. Implementations of the [monitor][monitor-spec], [keyboard][keyboard-spec],
[clock][clock-spec], [floppy drive][floppy-spec], and [3D vector display][3d-vector-display-spec] devices are also
provided.

Ketchup is currently in the alpha stage, with *many* features and improvements to be made. Most notably, there
currently exist no devices capable of interacting with the vessel, so using the CPU for flight control is not
currently possible. However, any program written for the DCPU-16 should be able to run within Kerbal Space
Program.

Releases
------------
Release information and downloads may be found on the GitHub [releases][releases] page.

Building
------------
In order to build Ketchup two assemblies are required from your Kerbal Space Program installation. Because there
are no obvious distribution licenses for these libraries, they cannot be commited to source control.

1. Make a `KSP` directory under the `Dependencies` directory.
2. From the `KSP_Data/Managed` directory under your Kerbal Space Program installation, copy the following files to
   the previously created directory: `Assembly-CSharp.dll` and `UnityEngine.dll`.
3. Execute `msbuild` (.NET) or `xbuild` (Mono) to build.

You must use the `Tomato.dll` found in the `Dependencies` directory, as it is modified to be usable by Kerbal
Space Program. Or you may build your own copy from the `ksp-compat` [branch][tomato-ksp-compat] of my Tomato fork.

Installation
----------------
If you built from source, navigate to the `Output/Debug` or `Output/Release` directory depending on the
configuration of your build. Copy the entire `Ketchup` directory to the `GameData` directory in your Kerbal Space
Program installation.

If you are installing from a pre-packaged distribution, simply extract the `Ketchup` directory to the `GameData`
directory in your Kerbal Space Program installation.

Usage
---------
Two new parts will appear in game under the "Pods" section of the craft editor: the *ENIAK-16S Computer* and the
*ENIAK-16L Computer*, these "Mechanical Kerbal Brains" replace the *RC-001S Remote Guidance Unit* and the
*RC-L01 Remote Guidance Unit* respectively. The computers will consume twice as much electricity as a remote
guidance unit however. If you wish to use the 3D vector display, add the
*Suspended Particle Excited Display, Rev 3 (SPED-3)* part found under the "Utility" section. Construct a rocket
normally with one of the new parts.

When you're ready to launch, right click on the computer part to bring up its context menu. Among the usual
options will be several options to toggle the interface of several devices. Toggle each of them on.

![Ketchup Windows](Documentation/Images/ketchup-0.5.0.png)

### Computer
The computer window allows you to control power to the computer via the **PWR** button, it also displays if the
computer is powered off, is halted, or is running by showing the average clock speed.

### Firmware
The firmware window allows you to flash the built-in firmware/bios. The firmware contains the first code that is
executed by the CPU when it powers on an is usually used to bootstrap the computer from other media. The firmware
device comes preloaded with a default firmware which will search for a floppy drive and load the first sector
(512 words) from the floppy into memory and execute it. If the program on the floppy disk is longer than 512 words
additional bootstrap code would be required to load additonal sectors into memory. Alternatively, a custom
firmware may be used to load additional sectors into memory. One such firmware, `firmware_127sectors_v1.dasm`, is
provided in the `Contrib/Firmware` directory of the distribution. As its name suggests, it automatically reads the
first 127 sectors (65024 words) from the floppy disk into memory. This actually, takes some time, so do not be
alarmed if your program takes some time to load. To use this firmware, first assemble it into a big-endian binary
image using a DCPU-16 assembler, such as [Organic][organic]. Then create a directory:
`Kerbal Space Program/saves/<profilename>/Ketchup/Firmware` under your Kerbal Space Program installation path.
Now, when you press the **Flash** button in the firmware window, you should be given the option to use the
custom firmware.

### Keyboard
The keyboard window contains a single button, **Attach**, which when enabled sends your keyboard input to the
computer.

### LEM-1802
The LEM-1802 window displays the standard monitor. The monitor's resolution of 128x96 pixels might be very small,
so the buttons at the bottom allow you to change the scaling of the display.

### M35FD
The M35FD window allows you to interact with the M35FD floppy drive. Each vessels maintains its own copies of
floppy disks, but you may retrieve standard floppy disks via the **Get Disk** button. The **Get Disk** button will
always give you the option to retrieve a blank disk, but it will also list any floppy disk images you have in
`Kerbal Space Program/saves/<profilename>/Ketchup/FloppyDisks`. Image files may end in `.bin` or `.img`. Standard
object code generated by a DCPU-16 assembler may be used as a floppy disk image. See the previous discussion under
*Firmware* for how to load programs larger than a single sector.

Once you have retrieved a list, it will be listed under the vessel's available disks. At this point you have three
options to manipulate the disk, you can use the **Label** button to change the label of the disk, the **Protect**
button to enable write protection on the disk, and **Destroy** to destroy the disk forever. If the M35FD is empty
you may press the **Insert** button, at which point you may select an available disk to insert into the drive.
When inserted, the disk's label will be displayed and you then have the option to press the **Eject** button to
eject it.

### Time Warp Note

When a computer is powered on on a vessel, time warp is limited to 4x. Computers have a clock speed of 100KHz,
relative to game time (up to 400KHz relative to real time).

Issues
----------
Please check the GitHub [issue tracker][issues] for a list of all current issues (bugs or enhancements).

Name
--------
*Ketchup* is derived predominantly from the Tomato project, and its name begins with a *K* so... yeah.

[0x10c]: http://0x10c.com/
[3d-vector-display-spec]: http://dcpu.com/3d-vector-display/
[clock-spec]: http://dcpu.com/clock/
[dcpu]: http://dcpu.com/
[dcpu-spec]: http://dcpu.com/dcpu-16/
[floppy-spec]: http://dcpu.com/floppy-drive/
[issues]: https://github.com/dbent/Ketchup/issues
[keyboard-spec]: http://dcpu.com/keyboard/
[ksp]: https://kerbalspaceprogram.com/
[monitor-spec]: http://dcpu.com/monitor/
[notch]: https://mojang.com/notch/
[organic]: https://github.com/SirCmpwn/organic
[releases]: https://github.com/dbent/Ketchup/releases
[tomato]: https://github.com/SirCmpwn/Tomato
[tomato-ksp-compat]: https://github.com/dbent/Tomato/tree/ksp-compat

repository: MSylvia/Ketchup

repo_name: MSylvia/Ketchup


text:
---
title: "Use sensuctl with Bonsai"
linkTitle: "Use sensuctl with Bonsai"
description: "Use sensuctl with Bonsai, the Sensu asset hub, to install dynamic runtime asset definitions and check for outdated dynamic runtime assets."
weight: 50
version: "6.8"
product: "Sensu Go"
platformContent: false
menu:
  sensu-go-6.8:
    parent: sensuctl
---

Sensuctl supports installing dynamic runtime asset definitions directly from [Bonsai, the Sensu asset hub][1], and checking your Sensu backend for outdated dynamic runtime assets.
You can also use `sensuctl command` to install, execute, list, and delete commands from Bonsai or a URL.

## Install dynamic runtime asset definitions

To install a dynamic runtime asset definition directly from Bonsai, use `sensuctl asset add <ASSET_NAME>:<ASSET_VERSION>`.
Replace `<ASSET_NAME>` with the complete name of the dynamic runtime asset from Bonsai.
An asset's complete name includes both the part before the forward slash (sometimes called the Bonsai namespace) and the part after the forward slash.

{{< figure src="/images/go/sensuctl_bonsai/name_namespace_location_bonsai_asset.png" alt="Bonsai page for the Sensu InfluxDB handler showing the location of the asset namespace and name" link="/images/go/sensuctl_bonsai/name_namespace_location_bonsai_asset.png" target="_blank" >}}

Replace `<ASSET_VERSION>` with the asset version you want to install.
To automatically install the latest version of the plugin, you do not need to specify the version: `sensuctl asset add <ASSET_NAME>`.

{{% notice note %}}
**NOTE**: Specify the asset version you want to install to maintain the stability of your observability infrastructure.
If you do not specify a version to install, Sensu automatically installs the latest version, which may include breaking changes.
{{% /notice %}}

For example, to install version 3.7.0 of the [sensu/sensu-influxdb-handler][4] dynamic runtime asset:

{{< code shell >}}
sensuctl asset add sensu/sensu-influxdb-handler:3.7.0
{{< /code >}}

The response should be similar to this example:

{{< code text >}}
fetching bonsai asset: sensu/sensu-influxdb-handler:3.7.0
added asset: sensu/sensu-influxdb-handler:3.7.0

You have successfully added the Sensu asset resource, but the asset will not get downloaded until
it's invoked by another Sensu resource (ex. check). To add this runtime asset to the appropriate
resource, populate the "runtime_assets" field with ["sensu/sensu-influxdb-handler"].
{{< /code >}}

You can also use the `--rename` flag to rename the dynamic runtime asset on install:

{{< code shell >}}
sensuctl asset add sensu/sensu-influxdb-handler:3.7.0 --rename influxdb-handler
{{< /code >}}

{{% notice note %}}
**NOTE**: Sensu does not download and install dynamic runtime asset builds onto the system until they are needed for command execution.
Read the [asset reference](../../plugins/assets#dynamic-runtime-asset-builds) for more information about dynamic runtime asset builds.
{{% /notice %}}

## Check your Sensu backend for outdated dynamic runtime assets

To check your Sensu backend for dynamic runtime assets that have newer versions available on Bonsai, use `sensuctl asset outdated`.
This will print a list of dynamic runtime assets installed in the backend whose version is older than the newest version available on Bonsai:

{{< code shell >}}
sensuctl asset outdated
{{< /code >}}

If outdated assets are installed on the backend, the response will be similar to this example:

{{< code text >}}
          Asset Name                  Bonsai Asset          Current Version  Latest Version
----------------------------  ----------------------------  ---------------  --------------
sensu/sensu-influxdb-handler  sensu/sensu-influxdb-handler       3.6.1            3.7.0
{{< /code >}}

## Extend sensuctl with commands

Use `sensuctl command` to install, execute, list, and delete commands from Bonsai or a URL.

### Install commands

To install a sensuctl command from Bonsai or a URL:

{{< code shell >}}
sensuctl command install <ALIAS> (<ASSET_NAME>:<ASSET_VERSION> | --url <ARCHIVE_URL> --checksum <ARCHIVE_CHECKSUM>) <FLAGS>
{{< /code >}}

To install a command plugin, use the Bonsai asset name or specify a URL and SHA512 checksum.

**To install a command using the Bonsai asset name**, replace `<ASSET_NAME>` with the complete name of the asset from Bonsai.
`:<ASSET_VERSION>` is only required if you require a specific version or are pinning to a specific version.
If you do not specify a version, sensuctl will fetch the latest version from Bonsai.

Replace `<ALIAS>` with a unique name for the command.
For example, for the [Sensu EC2 Discovery Plugin][3], you might use the alias `sensu-ec2-discovery`.
`<ALIAS>` is required.

Replace `<FLAGS>` with the flags you want to use.
Run `sensuctl command install -h` to view flags.
Flags are optional and apply only to the `install` command — they are not saved as part of the command you are installing.

To install a command from the [Sensu EC2 Discovery Plugin][3] with no flags:

{{< code shell >}}
sensuctl command install sensu-ec2-discovery portertech/sensu-ec2-discovery:0.3.0
{{< /code >}}

**To install a command from a URL**, replace `<ARCHIVE_URL>` with a command URL that points to a tarball (for example, https://path/to/asset.tar.gz).
Replace `<ARCHIVE_CHECKSUM>` with the checksum you want to use.
Replace `<ALIAS>` with a unique name for the command.

Replace `<FLAGS>` with the flags you want to use.
Run `sensuctl command install -h` to view flags.
Flags are optional and apply only to the `install` command — they are not saved as part of the command you are installing.

For example, to install a command-test dynamic runtime asset via URL with no flags:

{{< code shell >}}
sensuctl command install command-test --url https://github.com/amdprophet/command-test/releases/download/v0.0.4/command-test_0.0.4_darwin_amd64.tar.gz --checksum 8b15a170e091dab42256fe64ca7c4a050ed49a9dbfd6c8129c95506a8a9a91f2762ac1a6d24f4fc545430613fd45abc91d3e5d3605fcfffb270dcf01996caa7f
{{< /code >}}

{{% notice note %}}
**NOTE**: Dynamic runtime asset definitions with multiple asset builds are only supported via Bonsai.
{{% /notice %}}

### Execute commands

To execute a sensuctl command plugin via its dynamic runtime asset's bin/entrypoint executable:

{{< code shell >}}
sensuctl command exec <ALIAS> <GLOBAL_FLAGS> <FLAGS>
{{< /code >}}

Replace `<ALIAS>` with a unique name for the command.
For example, for the [Sensu EC2 Discovery Plugin][3], you might use the alias `sensu-ec2-discovery`.
`<ALIAS>` is required.

Replace `<GLOBAL_FLAGS>` with the globlal flags you want to use.
Run `sensuctl command exec -h` to view global flags.
To pass `<GLOBAL_FLAGS>` flags to the bin/entrypoint executable, make sure to specify them after a double dash surrounded by spaces.

Replace `<FLAGS>` with the flags you want to use.
Run `sensuctl command exec -h` to view flags.
Flags are optional and apply only to the `exec` command — they are not saved as part of the command you are executing.

{{% notice note %}}
**NOTE**: When you use `sensuctl command exec`, the [environment variables](../environment-variables) are passed to the command.
{{% /notice %}}

For example:

{{< code shell >}}
sensuctl command exec <COMMAND> <GLOBAL_FLAG_1> <GLOBAL_FLAG_2> --cache-dir /tmp -- --<FLAG_1> --<FLAG_2>=<value>
{{< /code >}}

Sensuctl will parse the --cache-dir flag, but bin/entrypoint will parse all flags after the ` -- `.

In this example, the full command run by sensuctl exec would be:

{{< code shell >}}
bin/entrypoint <GLOBAL_FLAG_1> <GLOBAL_FLAG_2> --<FLAG_1> --<FLAG_2>=<value>
{{< /code >}}

### List commands

To list installed sensuctl commands:

{{< code shell >}}
sensuctl command list <FLAGS>
{{< /code >}}

Replace `<FLAGS>` with the flags you want to use.
Run `sensuctl command list -h` to view flags.
Flags are optional and apply only to the `list` command.

### Delete commands

To delete sensuctl commands:

{{< code shell >}}
sensuctl command delete <ALIAS> <FLAGS>
{{< /code >}}

Replace `<ALIAS>` with a unique name for the command.
For example, for the [sensu/sensu-ec2-handler][3], you might use the alias `sensu-ec2-handler`.
`<ALIAS>` is required.

Replace `<FLAGS>` with the flags you want to use.
Run `sensuctl command delete -h` to view flags.
Flags are optional and apply only to the `delete` command.

[1]: https://bonsai.sensu.io/
[3]: https://bonsai.sensu.io/assets/sensu/sensu-ec2-handler
[4]: https://bonsai.sensu.io/assets/sensu/sensu-influxdb-handler

repository: sensu/sensu-docs

branch_name: refs/heads/main

repo_name: sensu/sensu-docs


text:
#MenuScript

App for making menus

##Purpose
This app allows users to create and share menus online.

##Tech
Built with Python/Flask on the backend.

*Dependcies*
flask-sqlalchemy
flask-whooshalchemy
sqlalchemy-migrate
flask_wtf

repository: gardoroman/menuscript

gha_language: Python

repo_name: gardoroman/menuscript


text:
![Build Status](https://github.com/fair-workflows/nanopub/workflows/Python%20application/badge.svg)
[![Coverage Status](https://coveralls.io/repos/github/fair-workflows/nanopub/badge.svg?branch=main)](https://coveralls.io/github/fair-workflows/nanopub?branch=main)
[![PyPI version](https://badge.fury.io/py/nanopub.svg)](https://badge.fury.io/py/nanopub)
[![fair-software.eu](https://img.shields.io/badge/fair--software.eu-%E2%97%8F%20%20%E2%97%8F%20%20%E2%97%8F%20%20%E2%97%8F%20%20%E2%97%8B-yellow)](https://fair-software.eu)

# nanopub
The ```nanopub``` library provides a high-level, user-friendly python interface for searching, publishing and retracting nanopublications.

# Setup
Install using pip:
```
pip install nanopub
```

To publish to the nanopub server you need to setup your profile. This allows the nanopub server to identify you. Run
the following interactive command:
```
setup_profile
```
It will add and store RSA keys to sign your nanopublications, publish a nanopublication with your name and ORCID iD to
declare that you are using using these RSA keys, and store your ORCID iD to automatically add as author to the
provenance of any nanopublication you will publish using this library.

## Quick Start

### Publishing nanopublications
```python

from nanopub import Publication, NanopubClient
from rdflib import Graph, URIRef, RDF, FOAF

# Create the client, that allows searching, fetching and publishing nanopubs
client = NanopubClient()

# Either quickly publish a statement to the server
client.claim('All cats are gray')

# Or: 1. construct a desired assertion (a graph of RDF triples)
my_assertion = Graph()
my_assertion.add( (URIRef('www.example.org/timbernerslee'), RDF.type, FOAF.Person) )

# 2. Make a Publication object with this assertion
publication = Publication.from_assertion(assertion_rdf=my_assertion)

# 3. Publish the Publication object. The URI at which it is published is returned.
publication_info = client.publish(publication)
print(publication_info)
```

### Searching for nanopublications
```python
from nanopub import NanopubClient

# Search for all nanopublications containing the text 'fair'
results = client.find_nanopubs_with_text('fair')
print(results)

# Search for nanopublications whose assertions contain triples that are ```rdf:Statement```s.
# Return only the first three results.
results = client.find_nanopubs_with_pattern(
                pred='http://www.w3.org/1999/02/22-rdf-syntax-ns#type',
                obj='http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement',
                max_num_results=3)
print(results)

# Search for nanopublications that introduce a concept that is a ```p-plan:Step```.
# Return only one result.
results = client.find_things('http://purl.org/net/p-plan#Step', max_num_results=1)
print(results)
```

### Fetching nanopublications and inspecting them
```python
# Fetch the nanopublication at the specified URI
np = client.fetch('http://purl.org/np/RApJG4fwj0szOMBMiYGmYvd5MCtRle6VbwkMJUb1SxxDM')

# Print the RDF contents of the nanopublication
print(np)

# Iterate through all triples in the assertion graph
for s, p, o in np.assertion:
    print(s, p, o)

# Iterate through the publication info
for s, p, o in np.pubinfo:
    print(s, p, o)

# Iterate through the provenance graph
for s, p, o in np.provenance:
    print(s,p,o)

# See the concept that is introduced by this nanopublication (if any)
print(np.introduces_concept)
```

### Specifying concepts relative to the nanopublication namespace
You can optionally specify that the ```Publication``` introduces a particular concept using blank nodes.
The pubinfo graph will note that this nanopub npx:introduces the concept. The concept should be a blank node
(rdflib.term.BNode), and is converted to a URI derived from the nanopub's URI with a fragment (#) made from the blank
node's name.
```python
from rdflib.term import BNode
publication = Publication.from_assertion(assertion_rdf=my_assertion,
                                         introduces_concept=BNode('timbernerslee'))
```
Upon publication, any blank nodes in the rdf graph are replaced with the nanopub's URI, with the blank node name as a
fragment. For example, if the blank node is called 'step', that would result in a URI composed of the nanopub's (base)
URI, followed by #step. In case you are basing your publication on rdf that has a lot of concepts specific to this
nanopublication that are not blank nodes you could use `replace_in_rdf` to easily replace them with blank nodes:
```python
from nanopub import replace_in_rdf
replace_in_rdf(rdf=my_assertion, oldvalue=URIRef('www.example.org/timbernerslee'), newvalue=BNode('timbernerslee'))
```

### Specifying derived_from
You can specify that the nanopub's assertion is derived from another URI (such as an existing nanopublication):
```python
publication = Publication.from_assertion(assertion_rdf=my_assertion,
                                         derived_from=rdflib.URIRef('www.example.org/another-nanopublication'))
```
Note that ```derived_from``` may also be passed a list of URIs.

## Dependencies
The ```nanopub``` library currently uses the [```nanopub-java```](https://github.com/Nanopublication/nanopub-java) tool for signing and publishing new nanopublications. This is automatically installed by the library.

repository: LourensVeen/nanopub

repo_name: LourensVeen/nanopub


text:
---
title: "Terraform"
authors: ["gio"]
---

#### "Error: Provider configuration not present"

This might happen if we tried to remove an existing resource/module that do not have `required_providers` block already in place.

To solve this, we need to:

1. Revert the removal of the existing resource/module
2. In `version.tf` ensure that we have proper mapping of required providers, for example if we use Google:
    ```
    terraform {
      required_providers {
        google = {
          source  = "hashicorp/google"
          version = "~> 3.90.1"
        }
      }
      required_version = ">= 0.13"
    }

    ```
3. Plan and then apply, even if there's no changes
4. Try removing the resource/module again and then plan & apply

Reference: https://support.hashicorp.com/hc/en-us/articles/1500000332721-Error-Provider-configuration-not-present

repository: giosakti/personal-site

repo_name: giosakti/personal-site