text:
# wp-install (PowerShell)

## Description
A PowerShell script for quick [WordPress](https://wordpress.org/) installation on local web servers.

Using this script you can define a specific WordPress configuration and create multiple websites with the same settings, skipping boring and time consuming manual tasks (WordPress download, setup process, theme and plugins installation...).

The script takes advantage of the [WP-CLI](https://wp-cli.org/) power, creating and running a list of commands witch actually install and configure a full WordPress instance.

## Requirements
- **Windows OS** (tested on Windows 10)
- **PowerShell** configured to allow scripts execution (check [Execution Policy](http://go.microsoft.com/fwlink/?LinkID=135170))
- **local Apache+MySQL/MariaDB+PHP environment** (tested on [Laragon](https://laragon.org))
- **the `mysql` command working in PowerShell** (ensure the `bin` folder of MySQL/MariaDB is in the `PATH` environment variable)
- **WordPress** (tested up to version 6.3)
- **WP-CLI** (tested up to version 2.8.1)
- **ensure that your system can run WordPress ([requirements](https://wordpress.org/download/)) and WP-CLI ([requirements](https://wp-cli.org/#installing))**

## Installation
- clone or download this repository in a folder.
- download latest WP-CLI version from https://wp-cli.org/#installing and put the `wp-cli.phar` file into the script folder.
- ensure the folder contains the following files:
  - `wp-cli.phar`
  - `wp-cli.yml`
  - `wp-install.ps1`
- open the `wp-install.ps1` file with a text editor (Visual Studio Code, Notepad++, PowerShell ISE...).
- carefully read all comments and change the script configuration values to fit your local environment (please check the following [Configuration](#configuration) section).

## Configuration
Before running the script for the first time, please check the values between these two lines:

```PowerShell
# ====== SCRIPT CONFIGURATION START =============
...
# ====== SCRIPT CONFIGURATION END ===============
```

Most variable names should be self-explanatory, however some of them have a comment on the right.

Check the environment settings first and change them to fit your system. The `$php` variable allows you to select a specific PHP version in case you have multiple versions installed.

Then go ahead with the WordPress settings, where you can define the basic setup options.

----------

For further WordPress customization, please have a look to the code between these lines:

```PowerShell
# ====== OPTIONAL WORDPRESS SETTINGS START ======
...
# ====== OPTIONAL WORDPRESS SETTINGS END ========
```

```PowerShell
# ====== OPTIONAL ADMIN SETTINGS START ======
...
# ====== OPTIONAL ADMIN SETTINGS END ========
```

This part is different from the previous one as it contains full WP-CLI commands, not just values.

The script currently contains a few commands which can be deleted or modified to meet your needs (or kept as they are!).

If you need to set other options, you have to write the correct command and add it to the commands list. Each new line should be similar to this:

```PowerShell
$commands += "$php $wpCli [command] --path=$wpFolderPath [command_parameters]"
```

Just replace `[command]` and `[command_parameters]`.

----------

Additional WP-CLI settings are available inside the `wp-cli.yml`.

You can add or change existing settings below this line:

```YML
# ====== COMMANDS CONFIGURATION ======
```

Currently this file allows to configure:
-  custom PHP code that will be added to the `wp-config.php` file, using the `extra-php` parameter of the `config create` command.
-  a list of plugins to be installed.
-  a list of plugins to be deleted.
-  the theme to be installed.
-  a list of themes to be deleted.

Please check the comments in the file to know more about the existing configuration.

For more details about the WP-CLI configuration file, please take a look at [this page](https://make.wordpress.org/cli/handbook/config/).

## Usage

To run `wp-install` open a PowerShell window, move to the script folder and run the script using the following parameters:

| Parameter    | Mandatory | Description |
|--------------|:---------:|-------------|
|`wpFolderName`| Yes       |The name of the folder in which the site will be installed. The name can contain subfolders. The site folder will be created inside the web server root.|
|`wpTitle`     | Yes       |The site title.|
|`wpUrl`       | No        |The site url. Extra configuration on the webserver is required for a custom url. If missing, the `$baseUrl` variable will be used (`http://localhost/...` by default).|
|`verboseMode` | No        |Print out the commands during the script execution.|
|`testMode`    | No        |Prevent commands to be run. May be useful together with `verboseMode` to preview the full script execution.|

**Examples:**

Create a new WordPress instance with default url:

```PowerShell
.\wp-install.ps1 -wpFolderName "wp_test_site" -wpTitle "Testing WordPress"
```

Create a new WordPress instance in a subfolder and set a custom url:

```PowerShell
.\wp-install.ps1 -wpFolderName "tests\wp_test_site" -wpTitle "Testing WordPress" -wpUrl "http://test-site.local"
```

Create a new WordPress instance and print the commands while being executed:

```PowerShell
.\wp-install.ps1 -wpFolderName "wp_test_site" -wpTitle "Testing WordPress" -verboseMode
```

Run script preventing command execution:

```PowerShell
.\wp-install.ps1 -wpFolderName "wp_test_site" -wpTitle "Testing WordPress" -verboseMode -testMode
```

## Changelog
### [1.6.2] - 2023-04-05
Tested with WordPress 6.2.

**Added**
- Uninstall the "Twenty Twenty Two" theme.
- Define the "development" environment in `wp-config.php`.
- Disable pings from and to blogs in the Discussion settings.

### [1.6.1] - 2022-11-17
This version brings a few changes to improve support with WordPress 6.1.x and WP-CLI 2.7.x.

**Changed**
- Removed the command to clear the blog description (useless since it's already empty in WordPress 6.1).
- Removed the theme "Twenty Twenty" from delete list since it is not bundled with WordPress 6.1.
- Moved `WP_DEBUG` definition back to the `wp-cli.yml` file since WP-CLI 2.7 fixed the duplication issue.

### [1.6.0] - 2022-05-09
**Added**
- Added optional parameter to pass a custom site URL. If not specified, "localhost" will be used. **Please note:** extra configuration on the webserver is required for a custom url.
- Generate a random password for the admin user. The password will be saved to a file in the site folder and also displaed to the terminal. **Please note:** currently the password is not really safe, so change it if you deploy the site.
- Added command to open the site backend at the end of the setup.

**Changed**
- Changed the PHP version used by the script. This is a default value, please modify it according to your environment.
- Modified the default admin username to prevent having an "admin" user, which is not good if the site is going to be deployed.
- Updated the script documentation.

**Fixed**
- Fixed default site url (localhost) when WordPress is installed in a subfolder.
- Removed dots from the folder name, which may cause rewrite rules issues.

### [1.5.0] - 2022-01-30
This version fixes issues with WordPress 5.9 and WP-CLI 2.6.0.

**Added**
- Added command to disable comments.
- Added command to enable comments moderation.
- Added command to disable avatars.
- Added command to use posts excerpt in the feed.
- Added command to disable the welcome screen on the admin dashboard.

**Changed**
- Modified the list of themes to be deleted according to the WP 5.9 default themes.
- Modified the way the WP_DEBUG is enabled, since WP-CLI 2.6.0 does not override the default WP_DEBUG definition.

### [1.4.0] - 2021-06-02
**Added**
- Added commands to update core, plugins and themes language files.
- Added PHP code to enable WordPress debug in the `wp-cli.yml` file.
- Added comments to the PHP code in the `wp-cli.yml` file.

**Changed**
- Moved the lists of plugins and themes to be installed/deleted from the script configuration variables to the `wp-cli.yml` file. Please check the comments in the file for more details.

### [1.3.0] - 2020-04-09
**Changed**
- Moved the extra-php setting from the script to the YML configuration file. The code can now be added in a easier way and the output will be multiline.

### [1.2.2] - 2020-01-14
**Changed**
- Modified random string generation function to have only lower case letters in table prefix.

### [1.2.1] - 2019-11-17
**Changed**
- Removed from the script configuration the names of plugins and themes to install/remove to have a more cleaner base script.

### [1.2.0] - 2019-09-22
**Added**

- Added the `$wpExtraPhp` variable for the `--extra-php` parameter value.
- Added the `$wpDisableAutoUpdates` variable to disable the WordPress auto updates.
- Added the `$wpDisableFileEdit` variable to disable the WordPress internal file editor.

### [1.1.0] - 2019-09-21
**Added**

- Delete WordPress `readme.html` file.

### [1.0.1] - 2019-08-25
**Fixed**

- Changed the `$serverRootFolderPath` variable default value which should not have a trailing slash.

### [1.0.0] - 2019-08-16
**Added**

- Initial script version released.

## License
[MIT](https://choosealicense.com/licenses/mit/)

repository: andreaporotti/wp-install-powershell

repo_name: andreaporotti/wp-install-powershell


text:
Runtime
==================================

The runtime module implements the actual simulation in Python.
It provides a similar interface as the [OpenAI Gym](https://gym.openai.com/) environments.

```python
class Runtime(PyRuntime):
  def __init__(self,
               step_time,
               viewer,
               scenario_generator=None,
               render=False):
    self._step_time = step_time
    self._viewer = viewer
    self._scenario_generator = scenario_generator
    self._scenario_idx = None
    self._scenario = None
    self._render = render
    ...

  def reset(self, scenario=None):
    ...

  def step(self):
    ...

  def render(self):
    ...
```

The runtime has a scenario generator that fills in the `self._scenario` and ID of the current scenario `self._scenario_idx`.

## Scenario

The scenario fully defines the initial state of the simulation, such as the agent's positions and models.

The outline of the `Scenario` class is given by:

```python
class Scenario:
  def __init__(self,
               agent_list=None,
               eval_agent_ids=None,
               map_file_name=None,
               json_params=None,
               map_interface=None):
    self._agent_list = agent_list or []
    self._eval_agent_ids = eval_agent_ids or []
    self._map_file_name = map_file_name
    self._json_params = json_params
    self._map_interface = map_interface
  ...
```

It also specifies which agents should be evaluated using `self._eval_agent_ids`.

## Scenario Generation

A scenario generation in BARK returns a list of scenarios of the type  `Scenario`.
These can be run by the BARK runtime or by the `BenchmarkRunner`.

Currently available scenario generators:

* `ConfigurableScenarioGeneration`: Sophisticated scenario generation providing conflict resolution.
* `UniformVehicleDistribution`: Samples the agents uniformly and their parameters.
* `ConfigWithEase`: Configure any scenario fast and with ease.
* `DeterministicScenarioGeneration`: Deterministic, reproducible scenario generation.

## Benchmarking

BARK provides a `BenchmarkRunner` and `BenchmarkAnalyzer` to automatically run and verify the performance of novel behavior models.

## Viewer

A common viewer interface allows easy extension of visualization capabilities of Bark.

Several viewer modules are currently available:

* `MPViewer`: Matplotlib viewer for scientific documentation.
* `PygameViewer`: Gym-like visualization of the BARK environment.

license: MIT

repository: xmyqsh/bark

branch_name: refs/heads/master

extension: md

gha_license_id: MIT

license_type: permissive

repo_name: xmyqsh/bark


text:
---
layout: page
title: Pixel Evolution
description: Real time neuroevolution without explicit fitness functions or generations
img: /assets/img/pixel-evolution/evolved2.gif
importance: 1
category: fun
---

Most of the evolutionary projects that I have been working on have consisted of two very important features of evolutionary algoritms:
* Fitness Function
  * This allows creatures' performance to be assigned a single number or rank that shows how good the behavior of this creature is.
  * For example, \\[ F = \text{Distance from Origin}\\]
  * This function would promote creatures to move away from the origin, as the ones that do move away from the origin have a higher chance to reproduce and spread their genetic makeup.
* Generations
  * This gives the evolutionary algorithm a chance to evaluate creatures, sort them by fitness, and then breed the higher fitness creatures together to create the next generation.

Although these are very important features of evolutionary algorithms, we don't see any explicit fitness functions in real life. We also do not see any explicit generations where all creatures are stopped, evaluated, and bred. This intruiged me, because I wanted to figure out how the evolution happened over the course of our history.

* Simplicity was key for this project, as the more rules I put in, the more chance my human nature biases the outcome of the project.

### Plan:
As with most of my other projects, here's a quick doodle plan for this project:

I wanted to include a way for creature's behavior to be better than others, while not explicitly measuring their fitnesses. To do this, we have **food** particles floating around the world, and if the creature eats this food, they immediately reproduce and spread their genetic information throughout the population by replacing a random individual.

So, due to the individual nature of the reproduction scheme, we do not need generations as now each creature will have its own children and grandchildren, much like humans and other animals on Earth.

Creatures have the capacity to live forever, although to be able to do this, they must be eating food very consistently or their genetic makeup will go extinct. This is because everytime one of the other creatures eats food, you have a small chance to be replaced by their children.

### Here is what they looked like right when they are initialized:
 ![random pixels](/assets/img/pixel-evolution/random1.gif)

 All of their brains are randomly instantiated Neural Networks, and through this evolutionary process, the neural networks that perform better have more children, and thus spread their good genes across the population.

I let evolution run for a few thousand **timesteps** (or 5 mins of training time). Here is the result:
 ![evolved pixels](/assets/img/pixel-evolution/evolved2.gif)

 As we can see, the creature's have "learned" to move downwards constantly, eating as much food as they can see in their eyesight. I claim that all the creatures moving downwards have evolved from one ancestral pixel than had the "move down" genes (or some varient of it). We could think of this like a **species** of pixels. We can also see a few pixels moving to the left. These would be part of a different species.

To test this claim, I re-evolved the creatures from the beginning with different random conditions:

 ![evolved pixels 2](/assets/img/pixel-evolution/evolved1.gif)
This is a really interesting result, because we can now see that the majority of pixels are moving left, eating any food that they can see. There are a few creatures who move upward aswell, representing two new species.

From these results, we can see that the creatures very quickly speciate due to a common ancestor that knocked out all the competition.

### Issues / Further comments
Something I noticed when I dropped the creature population from 100 to 15 is that sometimes they get "stuck". This is because none of the 15 creatures ever actually eat a food, so they continute going in circles, no food is eaten, so no reproduction happens, and evolution halts.
In the future, I plan to create a new project where each pixel has a set of energy, and has to eat a certain amount of food to replenish that energy. If it goes in circles for too long without eating, it will be killed off and replaced with a random pixel.

Something like this:

extension: markdown

gha_language: JavaScript


text:
---
title: Projects
linktitle: Projects
toc: true
type: docs
date: "2019-05-05T00:00:00+01:00"
draft: false
menu:
  cosc3337fall:
    weight: 4

# Prev/next pager order (if `docs_section_pager` enabled in `params.toml`)
weight: 3
---

- **Four Projects**
  The idea of the projects is to select one or more datasets from Machine Learning Repository
http://archive.ics.uci.edu/ml/datasets.php
Then select which project / topic and apply all the steps on the data set selected
Add a description cell before each cell and a result interpretation cell after main results.
Email the TA ahead of time the project selected as well as the dataset name.
Name your project as COSC3337_Project#_LastnameFirstname and submit as .ipynb (and .pdf is optional)

-  **Extra point(+4): Building a data storytelling of your project**
-  **A student can do up to 4 projects Specified in Blackboard**
-  **Each Project is worth +10 points on Exam1 (p1 && p2) and Exam2 (p3 && p4)**
-  **Deadline November 30th for all projects**

repository: njrizk/njrizk-academic

repo_name: njrizk/njrizk-academic


text:
# # EzsignfoldersignerassociationRequestCompound

## Properties

Name | Type | Description | Notes
------------ | ------------- | ------------- | -------------
**pkiEzsignfoldersignerassociationID** | **int** | The unique ID of the Ezsignfoldersignerassociation | [optional]
**fkiUserID** | **int** | The unique ID of the User | [optional]
**fkiUsergroupID** | **int** | The unique ID of the Usergroup | [optional]
**fkiEzsignsignergroupID** | **int** | The unique ID of the Ezsignsignergroup | [optional]
**fkiEzsignfolderID** | **int** | The unique ID of the Ezsignfolder |
**bEzsignfoldersignerassociationReceivecopy** | **bool** | If this flag is true. The signatory will receive a copy of every signed Ezsigndocument even if it ain't required to sign the document. | [optional]
**tEzsignfoldersignerassociationMessage** | **string** | A custom text message that will be added to the email sent. | [optional]
**objEzsignsigner** | [**\eZmaxAPI\Model\EzsignsignerRequestCompound**](EzsignsignerRequestCompound.md) |  | [optional]

[[Back to Model list]](../../README.md#models) [[Back to API list]](../../README.md#endpoints) [[Back to README]](../../README.md)

repository: eZmaxinc/eZmax-SDK-php

repo_name: eZmaxinc/eZmax-SDK-php


text:
# caddy-plugins-docker

A custom build of [Caddy](https://caddyserver.com/) with plugins.

## Using the image

`docker pull ghcr.io/mr-karan/caddy:2.6.4`

See the rest of instructions [here](https://registry.hub.docker.com/_/caddy).

### List of plugins included

- [caddy-dns/cloudflare/](https://github.com/caddy-dns/cloudflare/)

repository: mr-karan/caddy-plugins-docker

repo_name: mr-karan/caddy-plugins-docker


text:
# Change Log

## [Unreleased]

## [v0.2.0] - 2018-06-30

 - Added `SendCompletion` to facilitate more ergonomic sending of non-clonable
   types.

## v0.1.0 - 2018-05-13

 - Initial release

[Unreleased]: https://github.com/kcuzner/nb-sync/compare/v0.2.0...HEAD
[v0.2.0]: https://github.com/kcuzner/nb-sync/compare/v0.1.0...v0.2.0

repository: kcuzner/nb-sync

repo_name: kcuzner/nb-sync


text:
---
layout: page
title: "About"
date: 2013-09-07 15:18
comments: false
sharing: true
footer: true
---

{% pullside right %}
![Adam Fortuna](/images/adam-fortuna.png)
{% endpullside %}

Hey there. I'm Adam Fortuna, a developer living in Orlando, Florida who lives mostly in the Ruby/Rails world. This blog is a collection of whatever I'm interested in. I also write about programming at [evaleverything.com](http://evaleverything.com). Here's a few areas of interest that inspire what I write about.

* Loves trying new restaurants and food trucks
* Disney pass holder
* Have a cute [girlfriend and dog](/images/about/marilyn_and_lily.jpg)
* Mac obsessed geek
* Casual console and arcade gamer
* Beginning gardener
* Home beer brewer
* Sci-fi, fantasy and anime and general movie fan
* Big Sci-fi book reader
* CrossFit member

If you want to get in contact with me, feel free to send a [tweet](http://twitter.com/adamfortuna) my way!


text:
# CouplerMachine
Repo for Coupler Specific Shared Development

General approach in coupler is to aim for something minimal to start that can grow over time.

First pass is for a simple slab ocean treated as a separate component beneath an atmosphere with
fields exchanged via the coupler abstratction.

For this there are two big parts

## adding a bondary-fields abstraction

     The bondary-fields abstraction for each component would be used to expose and share
     state that is needed by another component.
     The approach we are thinking about for this would be an DG object on the same mesh as the
     component it is attached to, but possibly only 2-d (xy) or 2.5-d(xy + a thin layer in z).
     A starting point for ideas on this can be the code in

 https://github.com/CliMA/ClimateMachine.jl/blob/83cb930177d27ad411611c1aaaad68aec38ce4ec/src/Ocean/SplitExplicit01/Communication.jl#L191

     which shows some mapping between differnet dimension collections of DG fields. Wrapping this type of code in an
     API with some meta-data tuple would make a reaonable starting point for a boundary-fields abstraction.

## creating a driver and stepping recipe for advancing coupled components

     In a coupled system we want to step components separately and periodically exchange fields between them. Some preliminary sketching
     of ideas in the context of coupled Balance Law entities is in progress here

 https://github.com/christophernhill/CouplerMachine/tree/main/experimentation/driver-experimenting

repository: christophernhill/CouplerMachine

branch_name: refs/heads/main

repo_name: christophernhill/CouplerMachine


text:
`deepest` is [`deeper`'s](https://github.com/othiym23/node-deeper) devious
little brother. It doesn't care about encapsulation or data-hiding -- it finds
all the properties on your objects and makes sure that any two objects are
exactly the same by examining their property descriptors directly. Arguably
useful for comparing objects that have been created using `defineProperty`
magic, and can correctly test some objects that would lead to stack explosions
when used with `deeper` or other more straightforward deep equality testers.
I'd love to know about any situations where this module turns out to be
necessary.

`deepest`, like `deeper`, also comes with shims for use with my three favorite
assertion libraries:

* [Chai](http://chaijs.com/)
* [node-tap](https://github.com/isaacs/node-tap)
* Node's own [assert](http://nodejs.org/api/assert.html)

See the usage instructions for details on how to enable the shims.

## installation

```
npm install deepest
```

## usage

```javascript
// vanilla
var deepEqual = require('deepest')

if (!deepEqual(obj1, obj2)) console.log("yay! diversity!");

// to install the shim against require('assert').deepEqual
require('deepest').patchAssert();

// to patch Chai's eql / deep.equal / et al
require('deepest').patchChai();

// to patch node-tap's ridiculous array of synonyms for deepEqual
require('deepest').patchTap();
```

## caveats

All of `deeper`'s caveats apply here as well. Also, I'm not sure this module is
a good idea.

## license

BSD.


text:
# Teamscale Pre-Commit Command Line Client [![Build Status](https://travis-ci.org/cqse/teamscale-cli.svg?branch=master)](https://travis-ci.org/cqse/teamscale-cli) [![PyPI version](https://badge.fury.io/py/teamscale-cli.svg)](https://badge.fury.io/py/teamscale-cli) [![Teamscale Project](https://img.shields.io/badge/teamscale-teamscale--cli-brightgreen.svg)](https://demo.teamscale.com/activity.html#/teamscale-cli)

The [Teamscale](https://teamscale.com) pre-commit command line interface (CLI) allows you to integrate pre-commit analysis in editors or IDEs such as VS Code, Emacs, QtCreator or Sublime by providing findings in a standard error format that is interpreted and displayed like compile errors by these editors.

**NOTE:**
This version of Teamscale pre-commit CLI is being superseded by a more feature-rich [command-line client for Teamscale](https://docs.teamscale.com/reference/teamscale-cli/) that also supports [integrating with various IDEs and editors](https://docs.teamscale.com/getting-started/other-ides/).
We recommend switching to the new client.

## Installation

**This guide uses `pip` and `python`. If you prefer Python 3, you'll probably have to replace all occurrences with `pip3` and `python3`.**

1. Install [the latest release](https://pypi.org/project/teamscale-cli).
2. Copy the example configuration file [.teamscale-precommit.config](./config/.teamscale-precommit.config) to the root directory of the repository you want to analyze. Edit it and insert all the necessary data. You can find your personal access token by opening Teamscale and clicking on your Avatar in the top right corner.
3. Use `teamscale-cli` as a compile or build command in your editor. See below for instructions for
    [sample configurations for some editors and IDEs below](#instructions-for-popular-editors).
    Provide a file or folder within your repository as input. The general invocation looks like this:

    ```bash
    $ teamscale-cli [OPTIONS] CURRENTLY_OPENED_EDITOR_FILE
    ```

If you already have a Python installation, you may alternatively install `teamscale-cli` via `pip install teamscale-cli`.

## How it works

`teamscale-cli` will use the path you specify on the command line to locate your .git directory. It then uploads all [local uncommitted changes known to Git](#how-does-change-detection-work) to the Teamscale server and project you configured in the config file. The client then waits until Teamscale has analyzed these changes, and outputs findings on `stdout` in the following format:

```
Path to file:line number:Column: (warning|error): Message
```

This allows you to use the highlighting capabilities of your editors to highlight lines with findings in the editor and to jump to the finding location from the pre-commit console output. For your convenience, we've provided [sample configurations for some editors and IDEs below](#instructions-for-popular-editors).

Which findings are output is controlled by several command line options:

```
teamscale-cli CURRENTLY_OPENED_EDITOR_FILE
```

will output only pre-commit findings, i.e. findings that were added or removed due to your local changes. This includes all changes known to Git, not just the `CURRENTLY_OPENED_EDITOR_FILE`. Existing findings will not be output.
Use this if you are only interested in the impact your local code changes will have on the findings.

```
teamscale-cli --fetch-existing-findings CURRENTLY_OPENED_EDITOR_FILE
```

will output pre-commit findings for all locally changed files plus all existing, unchanged findings in `CURRENTLY_OPENED_EDITOR_FILE`.
Use this if you also want to have a look at existing findings in the currently opened file, e.g. to clean up old findings while you code.
**We recommend you use this mode as you can use it to see both the existing findings in the currently opened file (regardless of whether it is changed locally or not) and the impact of your local changes before you commit them. This gives you the opportunity to look at existing findings in the files you open and clean some of them up while you work on your code.**

```
teamscale-cli --fetch-existing-findings-in-changes CURRENTLY_OPENED_EDITOR_FILE
```

will output pre-commit findings for all locally changed files plus all existing, unchanged findings in all locally changed files.
Use this if you always want to clean up in all files where you have made changes.

Run the client with the `-h` argument to see additional available options.

## Instructions for Popular Editors

### Sublime

Add a new *Build System* under `Tools > Build System`. Copy and paste [our example snippet](./config/teamscale-precommit.sublime-build) and modify the arguments to fit your needs.

### Xcode

Add a new *Build Phase* (`New Run Script Phase`) to your project. Enter the following command as shell script in that phase (see screenshot):

```bash
python -c 'from teamscale_precommit_client.precommit_client import run;run()' ${SRCROOT}
```

This script uses `python` to execute the Teamscale precommit command line interface on the source of the project's Git repository (`SCROOT`). Make sure to use the correct Python version in that snippet, which might be `python3`.
Also, keep in mind that `python` by default might point to Xcode's own copy of python. Hence, you might want to explicitly specify the python executable's path instead (e.g. `/usr/bin/python`).

**In Xcode you cannot use `--fetch-existing-findings` since there is unfortunately no environment variable for the currently opened editor file.
Using this flag would give you all findings in the entire project, which is usually not helpful.**

![Configuring the Build Phase in Xcode](config/xcode_1.png)

Screenshot of findings shown in Xcode:

![Teamscale Findings in Xcode](config/xcode_2.png)

As shown on the previous screenshot, Xcode also provides links to the corresponding finding in Teamscale.

### VS Code

Add a new task (`Terminal > Configure Tasks > Create tasks.json file from template > Others`) and name it `Teamscale Pre-Commit Analysis`. VS Code will open a sample `tasks.json` for you to edit. Copy and paste [the example snippet from this repo](./config/teamscale-precommit-vscode-task.json).

### Vim

Copy [the teamscale-cli vim file](./config/teamscale.vim) to `~/.vim/compiler` and restart Vim.
This should allow you to run `:compiler teamscale` and `:make %`. Then, you should be able to use your usual workflow (e.g. `:cn`) to go through the findings.

### Qt Creator

In order to use the pre-commit Analysis in Qt Creator you need to add a new Kit (Teamscale does _not_ have to be the default Kit).
Go to `Tools > Options > Kits > Add`

![New Teamscale Kit](config/qtcreator_1.png)

The compiler must be set to gcc as this will be used to parse the console output of the tool.

Next you need to add the actual build config to each of your QtCreator projects.
Go to `Projects > Teamscale > Build` and remove all default `Build` and `Clean Steps` (there should be a small `x` when hovering over them).
Add a new build configuration:

![Pre-Commit](config/qtcreator_2.png)

Then configure it as follows:

* Executable: `python`
* Command line arguments: `-c "from teamscale_precommit_client.precommit_client import run;run()" --fetch-existing-findings --log-to-stderr %{CurrentDocument:FilePath}`

The flag `--log-to-stderr` is required as otherwise QtCreator will not recognize the findings.

You can add more than one build configuration, e.g. if you sometimes want to run the teamscale-cli with different arguments.

## How does change detection work?

The client detects changes by querying your Git repository for its current status. The following change types will be considered:

- Modified files
- Renamed files
- Files added to the index
- Deleted files that were in the index

New files that are not in the index will be ignored.

## Troubleshooting

- If python does not find the name `ConverterMapping` try uninstalling the `python-configparser` system package and install `configparser` via pip.
- If your files are not uploaded for pre-commit analysis make sure that you specified the correct encoding with the `--file-encoding` option. By default, the system encoding will be used for decoding.

## Limits

The precommit analysis has some builtin limits whose goal is to prevent denial of service of the Teamscale server:

- Files uploaded for precommit analysis must be less than 1 MB in size.
- At most 20 files can be uploaded for precommit analysis (can be changed on the server).
- Precommit analysis uploads might only be done once every 5 seconds per user (can be changed on the server).

These are automatically applied and cannot be disabled.

# Developing

## Preparation

1. Install [pip](https://pypi.org/project/pip/), e.g. via your system's package manager.
2. Install all dependencies:
   ```sh
   pip install .
   ```

## Building

```sh
python setup.py build
```

## Running Tests

```sh
python setup.py test
```

## Releasing

1. Create a GitHub release with the current Teamscale version number.
2. A GitHub action will automatically be triggered that builds the released branch and attaches the binaries to the release.
3. Contact Thomas Kinnen to perform the release to PyPI.

repository: cqse/teamscale-cli

gha_language: Python

repo_name: cqse/teamscale-cli


text:
Shuffle
=======

An application that produces a shuffled set of values.

Status
------

Travis CI Build Status: [![Build Status](https://travis-ci.org/oneam/Shuffle.svg?branch=master)](https://travis-ci.org/oneam/Shuffle)

Codecov.io Code Coverage Status: [![codecov.io](https://codecov.io/github/oneam/Shuffle/coverage.svg?branch=master)](https://codecov.io/github/oneam/Shuffle?branch=master)

Introduction
------------

Shuffle takes a single positive integer as input (N) and produces a list of integers in the range 1..N shuffled in a random order.

It uses the [Fisher-Yates Shuffle](https://en.wikipedia.org/wiki/Fisher-Yates_shuffle) to produce the list as fast a reasonably possible regardless of size.

For speed and memory reasons, it has a limitation of only producing lists with up to 10 million items.

Building Shuffle
----------------

In order to build Shuffle, you need to have [Java 8 SE Developer Kit](http://www.oracle.com/technetwork/java/javase/overview/index.html) installed on your system.

After pulling the Git repo, you can build the application by calling:

```
./gradlew installDist
```

Shuffle is built with Gradle wrapper, which will:

* download an embedded version of the Gradle build tools
* download all required dependencies
* build the application jar
* download wrapper scripts that make executing Shuffle easier

Running Shuffle
---------------

The Shuffle application binaries are installed in the `build/install/Shuffle` directory. In order to run the application, navigate to the directory and run:

```
bin/Shuffle -n <numValues>
```

where numValues is the number of values that will be shuffled.

If you run into problems, you can run:

```
bin/Shuffle -h
```

To get a full list of options.

Testing Shuffle
---------------

Shuffle has a full suite of unit tests. The tests are designed to ensure that the application will perform as expected given valid input and also ensures that the lists produced are a sufficiently randomized set of values.

In order to run the unit tests included in Shuffle, use Gradle's check target:

```
./gradlew check
```

The test results can be viewed by opening `build/reports/tests/index.html`

Under the shuffle package, there are 2 groups of tests:

* ShuffleApplicationTest tests ensure that Shuffle accepts and processes valid input.
* ShufflerTest ensures that the output produced by Shuffle is correct and suitably shuffled.

Code coverage results can be viewed by opening `build/reports/jacoco/test/html/index.html`. This data is a reflection of the data reported by [Codecov.io](https://codecov.io/github/oneam/Shuffle?branch=master).

repository: oneam/Shuffle

repo_name: oneam/Shuffle


text:
# Developer guide

## Running tests

```bash
git clone https://github.com/kdheepak/taskwarrior-tui
cd taskwarrior-tui

git clone github.com/kdheepak/taskwarrior-testdata tests/data
source .env

cargo test
```

## Running debug build

```bash
cargo run
```

## Running release build

```bash
cargo run --release
```

## Testing individual function

If you want to test the `test_taskwarrior_timing` function in `src/app.rs`:

```bash
cargo test -- app::tests::test_taskwarrior_timing --nocapture
```

## Getting logs

```bash
export TASKWARRIOR_TUI_LOG_LEVEL=debug
taskwarrior-tui

# OR

export TASKWARRIOR_TUI_LOG_LEVEL=trace
cargo run
```

## Contributing to documentation

See `docs/` folder in the repository: <https://github.com/kdheepak/taskwarrior-tui>

When you make a PR to the repository, a preview of the documentation is rendered and a link is posted to the PR.

## Internals of `taskwarrior-tui`

`taskwarrior-tui` is a state driven terminal user interface.
Keyboard events are read asynchronously and is communicated using channels.
Most of the logic is implemented in `src/app.rs`.
The difference between the previous state and the current state of the TUI is rendered every `Tick` by `tui-rs`.
`app.draw_...` functions are responsible for rendering the UI.
Actions for key presses are taken in [`app.handle_input(&mut self, input: Key)`](https://github.com/kdheepak/taskwarrior-tui/blob/f7f89cbff180f81a3b27112d676d6101b0b552d8/src/app.rs#L1893).

repository: kdheepak/taskwarrior-tui

gha_language: Rust

repo_name: kdheepak/taskwarrior-tui


text:
# Google Cloud FedRAMP aligned "Marketing Data Warehouse"

![FedRAMP Aligned Marketing Data Warehouse on Google Cloud](https://user-images.githubusercontent.com/56096409/121441449-b2cf0880-c93e-11eb-91f6-5574cb61e28b.png)

You can use the architecture to deploy a marketing data warehouse on Google Cloud. The entire architecture is deployed as two projects using [Cloud Data Protection Toolkit](https://github.com/GoogleCloudPlatform/healthcare-data-protection-suite).

## Documentation
* [Quickstart](https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart/blob/master/README.md)
* [Prerequisites](https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart/blob/master/README.md)
  * [Access Control](https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart/blob/master/README.md)
* [Deployment Phases](https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart/blob/master/README.md)
  * [Clone the repository](https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart/blob/master/README.md)
  * [Update the variables in HCL files](https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart/blob/master/README.md)
  * [Generate terraform files](https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart/blob/master/README.md)
  * [Architecure deployment using terraform](https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart/blob/master/README.md)
* [Architecture diagram]()
* [Use case description and user considerations]()
* [HCL files](https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart/blob/master/README.md)
* [Useful FedRAMP links](https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart/blob/master/README.md)

## Quickstart

1. Prerequisites
   - Access Control
2. Deployment Phases
   - Clone the repository
   - Update the variables in HashiCorp configuration language (HCL) files
   - Generate terraform files
   - Architecture deployment using terraform

## Prerequisites

Run the [Data Protection Toolkit](https://github.com/GoogleCloudPlatform/healthcare-data-protection-suite) locally on a computer or by using Google Cloud Shell.

Before you run the toolkit locally, install the following tools:

* [Go (1.14+)](https://golang.org/doc/go1.14) - an open source programming language to build software.
* [Cloud SDK](https://cloud.google.com/sdk/install) - a set of tools for managing resources and applications hosted on Google Cloud.
* [Git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) - a distributed version control system.
* [Terraform (0.14.4+)](https://www.terraform.io/downloads.html) - a cloud provisioning tool.
* [Google Workspaces](https://workspace.google.com/) or [Cloud Identity](https://cloud.google.com/identity/docs/overview) - Privileges to modify users and groups in Google Workspaces or Cloud Identity.
* [Google Cloud Organization](https://cloud.google.com/resource-manager/docs/creating-managing-organization) - A Google Cloud organization with [Billing Account](https://cloud.google.com/billing/docs)
* A domain purchased from a Domain registrar (example: Google Domains).
* Set up server-side tagging using Google Tag Manager.
  * [Create a Tag Manager server-side container.](https://developers.google.com/tag-manager/serverside#create_a_new_tag_manager_server-side_container)
  * Manually provision a [tagging server on Google Cloud App Engine.](https://developers.google.com/tag-manager/serverside/script-user-guide)

If Google Cloud Shell is used to run the toolkit, Go (1.16), Git, and Cloud SDK are preinstalled. However, newer version of Terraform must be installed in Google Cloud Shell before deploying the template using the below steps:

1. Go to [Terraform Downloads](https://www.terraform.io/downloads.html) and copy the link of 'Linux 64-bit' binary by right clicking on it.
2. Download the Linux 64-bit binary into Google Cloud Shell.
```
$ wget <link copied from Terraform Downloads>
```
3. Unzip the downloaded file.
```
$ unzip <downloaded file name>
```
4. Move the unzipped terraform binary to /usr/local/bin
```
$ sudo cp terraform /usr/local/bin
```

### Access Control
Before deploying a template, create three groups:
* Owner: project-owners@{DOMAIN} - This group is granted the owner's role for the project, which allows members to do anything permitted by organization policies within the project. Additions to the owner’s group should be for a short term and controlled tightly.  Members of this group get owners access to the devops project to make changes to the CICD project or to make changes to the Terraform state. Make sure to include yourself as an owner of this group. Otherwise, you might lose access to the devops project after the ownership is transferred to this group.
* Admin: org-admins@{DOMAIN} - Members of this group get administrative access to the org or folder. This group can be used in break-glass situations to give humans access to the org or folder to make changes. Include yourself as a member of this group to deploy the code templates.
* Cloud-users: project-cloud-users@{DOMAIN} - Members of this group will get access to the resources deployed by the toolkit post deployment.

The user groups running the template (org-admins group) should have the following IAM roles.
* roles/resourcemanager.organizationAdmin on the org for org deployment.
* roles/resourcemanager.folderAdmin on the folder for folder deployment (This role is required if workloads are deployed under a folder instead of organization).
* roles/resourcemanager.projectCreator on the org or folder.
* roles/billing.admin on the billing account.
* roles/owner on assured-workload projects for FedRAMP aligned workload deployment (This role is also assigned to the project-owners group).

## Deployment Phases

Data Protection Toolkit emplate deploys resources on the “Assured Workloads”, however the toolkit does not create these two Assured Workloads. Before you deploy the toolkit, create two FedRAMP Moderate Assured Workloads (one for the data warehouse project and one for the logging project) using the console or gcloud. Refer to this [Create a new workload environment.](https://cloud.google.com/assured-workloads/docs/how-to-create-workload)

### Clone the repository

1. Clone the Data Protection Toolkit git repository to a folder (locally or on cloud shell).

```
$ git clone https://github.com/GoogleCloudPlatform/healthcare-data-protection-suite
$ cd healthcare-data-protection-suite
```
2. Install tfengine.

```
$ go install ./cmd/tfengine
```

3. Clone the FedRAMP aligned data warehouse workload HCL files in a folder before running the tfengine

```
#clone modularised .hcl files from github to a folder in local machine or cloud shell
$ git clone https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart.git
```

4. After the HCL files are cloned, configure the variable values in commonVariables.hcl and variable.hcl files based on requirements. Refer the ‘Update the variables in HCL files’ section below for details.

## Update the variables in HCL files

This repository contains Hashicorp Configuration Language (HCL) files for deployment of FedRAMP aligned "Marketing Data Warehouse" using [Data Protection Toolkit.](https://github.com/GoogleCloudPlatform/healthcare-data-protection-suite) Data Protection Toolkit contains a suite of tools that can be used to manage key areas of your Google Cloud organization.

#### HCL files
This repository contains nine HCL files to deploy the infrastructure:
* variables.hcl: Contains variables that will be supplied to all other HCL files.
* commonVaraibles.hcl: Used to centralize common variables, which are used repetitively in variables.hcl.
* devops.hcl: Deploys devops project and terraform state storage bucket..
* network.hcl: Used to deploy two networks across two assured workload projects.
* logging.hcl: Used to deploy Logging project resources.
* datawarehouse.hcl: Used to deploy dataflow pipeline in the Data Warehouse project.
* AI-pipeline.hcl: Used to deploy AI related services in Data Warehouse project.
* datalab.hcl: Used to deploy datalab instance in Data warehouse project
* appengine.hcl: Used to map a domain to app engine application (server side container) in Data Warehouse project.

The repository contains below sample files for testing purposes:
* dept_data.txt - Sample analytics file.
* dept_data2.txt - Sample analytics file.
* schema.json - Sample schema for Cloud Storage to BigQuery transformation using Dataflow.
* transform.js - Sample UDF file Cloud Storage to BigQuery transformation using Dataflow.

#### Execution of HCL files

The toolkit (tfengine) execution starts with the commonVariables.hcl file. The commonVariables.hcl file calls the variable.hcl file, which in turn calls the other seven HCL files: devops.hcl, network.hcl, logging.hcl, datawarehouse.hcl, AI-pipeline.hcl, datalab.hcl, appengine.hcl.

(commonVariables.hcl →  variable.hcl file → devops.hcl, network.hcl, logging.hcl, datawarehouse.hcl, AI-pipeline.hcl, datalab.hcl, appengine.hcl)

Note: Variable values used in both commonVariables.hcl and variable.hcl files are for reference only. Update the variable values in commonVariables.hcl and variable.hcl files based on requirements.

#### Key Considerations
In order to edit and customize the deployment to align to your requirements, please consider the following.
**Note: All the variables stated in the below sections reside in [commonVariables.hcl](https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart/blob/master/Infrastructure/commonVariables.hcl) and [variables.hcl](https://github.com/GoogleCloudPlatform/gcp-fedramp-dw-quickstart/blob/master/Infrastructure/variables.hcl), and must be updated in these two files only.**

##### devops.hcl variables

The devops.hcl file will:
* Deploy a devops project, and
* Create a terraform state storage bucket

Ensure that values for devops project ID "devops_project_id" (in variables.hcl) and bucket name "terraform_state_storage_bucket" (in commonVariables.hcl) are globally unique.

Additionally, as needed customize the remaining variables based on the requirements.

##### network.hcl variables

The network.hcl will:
* Create two networks i.e., one for the Data Warehouse project and the other for the Logging project. Define Subnets’ primary CIDR ranges as per requirement.
* Enable Google private service access.

Additionally, as needed customize the remaining variables based on the requirements.

##### logging.hcl variables

The logging.hcl file creates:
* Dataflow job with private worker(s)
* Bigquery dataset and table
* Pub/Sub Topic and Subscription
* IAM bindings for access

Define BigQuery table schema (in the logging.hcl file) based on the log sink filter and Pub/Sub messages format. Update the following variables with appropriate values as described.
* logging_project_id (in commonVariables.hcl): Project ID of the assured workload created for Logging resources deployment.
* logging_project_region (in commonVariables.hcl): Region selected while creating assured workload logging project.
* dataflow_temp_storage_bucket_name (in variables.hcl): A globally unique bucket name.

Additionally, as needed customize the remaining variables based on the requirements.

**Note: Assured workloads for “Logging” and “Data Warehouse” must be created before executing the Data Protection Toolkit. For details, refer to section 3.5 in the Solution Guide.**

##### datawarehouse.hcl variables

The datawarehouse.hcl file creates:
* ‘Cloud Storage to BigQuery’ Dataflow jobs
* Cloud Storage bucket for analytics data import
* BigQuery Dataset and Tables to store enriched data (transformed)
* Service Accounts for Dataflow jobs
* Cloud Storage staging and artifacts bucket for Dataflow jobs.
* IAM for access

As mentioned below, update the following variables with appropriate values.
* datawarehouse_project_id (in commonVariables.hcl):  Project ID of the assured workload created for “Data Warehouse” resources deployment.
* datawarehouse_region (in commonVariables.hcl): Region in which Data Warehouse project resources will be deployed.
* datawarehouse_dataflow_temp_storage_bucket_name (in commonVariables.hcl): A globally unique bucket name.
* datawarehouse_custom_data_import_bucket1_name (in variables.hcl): A globally unique bucket name. For the purpose of this architecture, bucket1 is where google analytics, YouTube analytics, Adwords data will be imported
* datawarehouse_custom_data_import_bucket2_name (in variables.hcl): A globally unique bucket name. . For the purpose of this architecture, bucket2 is where google third party analytics data will be imported
* datawarehouse_cutom_data_import_bucket1_path_for_dataflow (in variables.hcl): Cloud Storage bucket path of imported analytics data files in import_bucket1
* datawarehouse_cutom_data_import_bucket2_path_for_dataflow (in variables.hcl): Cloud Storage bucket path of imported analytics data files in import_bucket2
* datawarehouse_dataflow_pipeline_template_artifacts_storage_bucket_name (in variables.hcl): A globally unique bucket name.
gcs_to_bq_dataflow_job1_schema_file_local_location (in variables.hcl): Local file path to schema file used in ‘Cloud Storage to BigQuery’ dataflow job1.
* gcs_to_bq_dataflow_job1_user_defined_function_local_location (in variables.hcl): Local file path to user defined function javascript file used in ‘Cloud Storage to BigQuery’ dataflow job1.
* gcs_to_bq_dataflow_job2_schema_file_local_location (in variables.hcl): Local file path to schema file used in ‘Cloud Storage to BigQuery’ dataflow job2.
* gcs_to_bq_dataflow_job2_user_defined_function_local_location (in variables.hcl): Local file path to user defined function javascript file used in ‘Cloud Storage to BigQuery’ dataflow job2.

Additionally, as needed customize the remaining variables based on the requirements.

##### AI-pipeline.hcl variables

The AI-pipeline.hcl file creates:
* ‘BigQuery to Cloud Storage tensorflow records’ dataflow jobs.
* AI Notebook Deep Learning VM
* ML model to host versions
* Service Accounts for Dataflow jobs
* IAM for access

As mentioned below, update the following variables with appropriate values.
* datawarehouse_bq_to_gcs_dataflow_job1_readquery (in variables.hcl): Query to read data from BigQuery table 1. BigQuery table 1 contains the transformed data from import_bucket1. BigQuery table 1 data is transformed to tensorflow records by ‘BigQuery to Cloud Storage tensorflow records’ dataflow job2.
* datawarehouse_bq_to_gcs_dataflow_job2_readquery (in variables.hcl): Query to read data from BigQuery table 2. BigQeury table 2 contains the transformed data from import_bucket2. BigQuery table 2 data is transformed to tensorflow records by ‘BigQuery to Cloud Storage tensorflow records’ dataflow job2.
* datawarehouse_tensorflow_records_storage_bucket_name (in variables.hcl): A globally unique bucket name.

Additionally, as needed customize the remaining variables based on the requirements.

##### datalab.hcl variables

The datalab.hcl file creates:
* Datalab instance
* Service Account for Datalab instance
* IAM for access

As mentioned below, update the following variables with appropriate values.
* datawarehouseAI_datalab_user_email (in variables.hcl): User email ID to which datalab access is granted.

Additionally, as needed customize the remaining variables based on the requirements.

##### appengine.hcl variables

The appengine.hcl file creates:
* Appengine Domain mapping.
* BigQuery Dataset to store Google Tag Manager (GTM) data from Appengine.
As mentioned below, update the following variables with appropriate values.
* appengine_mapping_domain_name (in variables.hcl): Domain name that will be mapped to Appengine application.

Additionally, as needed customize the remaining variables based on the requirements.

### Generate terraform files

To generate terraform configuration files using tfengine run the following command. This will generate 6 folders/subfolders with terraform configuration files in --output_path location.

Generated folders:
* devops
* logging/network
* logging/workload
* datawarehouse/network
* datawarehouse/dataflow-pipeline
* datawarehouse/AI-pipeline
* datawarehouse/datalab
* datawarehouse/appengine

```
# -config path is the path to downloaded .hcl files

$ tfengine --config_path=/{path-to-variablefile}/commonVariables.hcl --output_path=/{output-path}

# {path-to-variablefile}: path to commonVariable.hcl file.
# {output-path}: Folder path, where terraform configuration files are generated by tfengine.

```

### Architecture deployment using terraform

After generating terraform configurations using tfengine, run the generated main.tf files in the following order.

* Open the DevOps folder and run the Terraform configuration. This will deploy a project and a Terraform state storage bucket in the project with the name of choosing.

```
$ cd /{output-path}/devops
$ terraform init
$ terraform apply
```

* After the project and state bucket are deployed, go to devops.hcl file, uncomment or set the **enable_gcs_backend** to **true.** in the devops template recipe.

```
template "devops" {
  recipe_path = "recipes/devops.hcl"
  output_path = "./devops"
  data = {
    # TODO(user): Uncomment and re-run the engine after the generated devops module has been deployed.
    # Run `terraform init` in the devops module to backup its state to Cloud Storage.
    # enable_gcs_backend = true

    admins_group = {
      id = “{{.admin_group}}”
      exists = true
    }
```

* Run the tfengine command again and force-copy the state to the Terraform state storage bucket. Further Terraform configuration deployments will use this bucket to store the Terraform state.

```
$ tfengine --config_path=/{path}/commonVariables.hcl --output_path=/{path}
$ cd /{output-path}/devops
$ terraform init -force-copy

```

* After the states are transferred to the state bucket, deploy network resources in the Logging project (Assured Workload).

```
$ cd /{output-path}/logging/network
$ terraform init
$ terraform apply
```

* After the  logging network is deployed, run the following commands to deploy the remaining resources in the Logging project (Assured Workload) such as Dataflow, Pub/Sub, BigQuery, and so on:

```
$ cd /{output-path}/logging/workload
$ terraform init
$ terraform apply
```
* Deploy the resources in the datawarehouse/network folder to create two networks and enable the APIs in the data warehouse project.

```
$ cd /{output-path}/datawarehouse/network
$ terraform init
$ terraform apply
```

* Deploy the resources in datawarehouse/dataflow-pipeline folder to create Dataflow jobs, BigQuery dataset and tables, GCS buckets and so on:
```
$ cd /{output-path}/datawarehouse/dataflow-pipeline
$ terraform init
$ terraform apply
```
* Deploy the resources in datawarehouse/AI-pipeline folder to create Dataflow jobs, Notebook deep learning VM, AI Model and so on:
```
$ cd /{output-path}/datawarehouse/AI-pipeline
$ terraform init
$ terraform apply
```
* Deploy the resource in datawarehouse/datalab folder to create a Datalab instance.
```
$ cd /{output-path}/datawarehouse/datalab
$ terraform init
$ terraform apply
```
* Deploy the resources in datawarehouse/appengine folder to create App Engine domain mapping and BigQuery dataset.
```
$ cd /{output-path}/datawarehouse/appengine
$ terraform init
$ terraform apply
```
## Useful FedRAMP links

* [Google Cloud Platform supports FedRAMP compliance](https://cloud.google.com/security/compliance/fedramp/), and provides specific details on the approach to security and data protection in the [Google security whitepaper](https://cloud.google.com/security/overview/whitepaper/) and in the [Google Infrastructure Security Design Overview.](https://cloud.google.com/security/infrastructure/design/)
* To learn more about Google Cloud's Shared Responsibility Model, refer to the [Google Infrastructure Security Design Overview.](https://cloud.google.com/security/infrastructure/design/)
* Refer to the [FedRAMP Shared Security Model](https://cloud.google.com/assured-workloads/docs/concept-fedramp-moderate) and [Google Cloud FedRAMP Implementation Guide.](https://cloud.google.com/security/compliance/fedramp-guide) for additional guidance on FedRAMP shared responsibilities for Google Cloud Platform.
* For details on Google Cloud services covered by FedRAMP, refer to the [FedRAMP Marketplace](https://cloud.google.com/security/compliance/fedramp) by Google.


text:
---
layout: post
title: Rust Option and Result
subtitle: dealing with the Option and Result enum
image: /img/rusty_logo_small.jpeg
cover-img: /img/rusty_logo.jpeg
thumbnail-img: /img/rusty_logo_small.jpeg
share-img: /img/rusty_logo.jpeg
tags: [rust, rust basics]
---

A thorough understanding of the Option enum and the Result enum are essential to understanding optional values and error handling in Rust. In this ariticle, I will work my way through both of them.

## Introduction

To understand the `Option` and the `Result`, it is important to understand the following:
- the enum in Rust
- matching enum variants
- the Rust prelude

### The enum in Rust

There are good reasons for using enums. Among others, they are good for safe input handling and adding context to types by giving a collection of variants a name. In Rust, the `Option` as well as the `Result` are _enumerations_, also referred to as _enums_. The enum in Rust is quite flexible. It can contain many data types like tuples, structs and more. Additionally, you can also implement methods on enums.

The Option and the Result are pretty straightforward though. Let's first look at an example enum:

```rust
enum Example {
    This,
    That,
}

let this = Example::This;
let that = Example::That;
```

In the above, we define an enum called `Example`. This enum has 2 variants called `This` and `That`. Next, we create 2 instances of the enum, variables `this` and `that`. Both are created with their own variant. It is important to note that an instance of an enum is always 1 of the variants. When you use a field struct, you can define struct with all it's possible fields. An enum is different because you assign only one of the variants.

### Displaying the enum variants

By default, the enum variants is not something you can print to screen. Let's bring `strum_macros` into scope. This makes it easy to derive 'Display' on the enum we defined, which we do using `#[derive(Display)]` above the enum definition:

```rust
use strum_macros::Display;

#[derive(Display)]
enum Example {
    This,
    That,
}

let this = Example::This;
let that = Example::That;

println!("Example::This contains: {}", this);
println!("Example::That contains: {}", that);
```

Now, we can use print to display the enum variant values to screen:

Example::This contains: This
Example::That contains: That

### Matching enum variants

Using the `match` keyword, we can do pattern matching on enums. The following function takes the Example enum as an argument:

```rust
fn matcher(x: Example) {
    match x {
        Example::This => println!("We got This."),
        Example::That => println!("We got That."),
    }
}
```

We can pass the matcher function a value of the Example enum. The `match` inside the function will determine what is printed to screen:

```rust
matcher(Example::This);
matcher(Example::That);
```

Running the above will print the following:

We got This.
We got That

### The Rust prelude

The Rust prelude, described [here](https://doc.rust-lang.org/std/prelude/index.html#), is something that is a part of every program. It is a list of things that are automatically imported into every Rust program. Most of the items in the prelude are traits that are used very often. But in addition to this, we also find the following 2 items:
- std::option::Option::{self, Some, None}
- std::result::Result::{self, Ok, Err}

The first one is the `Option` enum, described as 'a type which expresses the presence or absence of a value'. The later is the `Result` enum, described as 'a type for functions that may succeed or fail.'

Because these types are so commonly used, their variants are also exported. Let's go over both types in more detail.

## The Option

Brought into scope by the prelude, the [Option](https://doc.rust-lang.org/std/option/index.html) is available to us without having to lift a finger. The option is defined as follows:

```rust
pub enum Option<T> {
    None,
    Some(T),
}
```

The above tells us `Option<T>` is an enum with 2 variants: `None` and `Some(T)`. In terms of how it is used, the `None` can be thought of as 'nothing' and the `Some(T)` can be thought of as 'something'. A key thing that is not immediately obvious to those starting out with Rust is the `<T>`_-thing_. The `<T>` tells us the Option Enum is a `generic` Enum.

### The Option is generic over type T.

The enum is 'generic over type T'. The 'T' could have been any letter, just that 'T' is used as a convention where 1 generic is involved.

So what does it mean when we say 'the enum is generic over type T'? It means that we can use it for any type. As soon as we start working with the Enum, we can (and must actually) replace 'T' with a concrete type. This can be any type, as illustrated by the following:

```rust
let a_str: Option<&str> = Some("a str");
let a_string: Option<String> = Some(String::from("a String"));
let a_float: Option<f64> = Some(1.1);
let a_vec: Option<Vec<i32>> = Some(vec![0, 1, 2, 3]);

#[derive(Debug)]
struct Person {
    name: String,
    age: i32,
}

let marie = Person {
    name: String::from("Marie"),
    age: 2,
};

let a_person: Option<Person> = Some(marie);
let maybe_someone: Option<Person> = None;

println!(
    "{:?}\n{:?}\n{:?}\n{:?}\n{:?}\n{:?}",
    a_str, a_string, a_float, a_vec, a_person, maybe_someone
);
```

The above code outputs the following:

Some("a str")
Some("a String")
Some(1.1)
Some([0, 1, 2, 3])
Some(Person { name: "Marie", age: 2 })
None

The code shows us the enum can be generic over standard as well as over custom types. Additionally, when we define an enum as being of type x, it can still contain the variant 'None'. So the Option is a way of saying the following:

This can be of a type T value, which can be anything really, or it can be nothing.

### Matching on the Option

Since Rust does not use exceptions or null values, you will see the Option (and as we will learn later on the Result) used all over the place.

Since the Option is an enum, we can use pattern matching to handle each variant in it's own way:

```rust
let something: Option<&str> = Some("a String"); // Some("a String")
let nothing: Option<&str> = None;   // None

match something {
    Some(text) => println!("We go something: {}", text),
    None => println!("We got nothing."),
}

match nothing {
    Some(something_else) => println!("We go something: {}", something_else),
    None => println!("We got nothing"),
}
```

The above will output the following:

We go something: a String
We got nothing

### Unwrapping the Option

Oftentimes, you'll see unwrap being used. This looked a bit mysterious at first. Hoovering over it in the IDE offers some clues:

{:refdef: style="text-align: center;"}
![ID unwrap](/img/ide_unwrap.png "ID unwrap"){:height="80%" width="80%"}
{: refdef}

In case you are using VScode, something that is nice to know is that simultaneously pressing Ctrl + left mouse button can take you to the source code. In this case, it takes us to the place in `option.rs` where unwrap is defined:
```rust
pub const fn unwrap(self) -> T {
    match self {
        Some(val) => val,
        None => panic!("called `Option::unwrap()` on a `None` value"),
    }
}
```

In `option.rs`, we can see `unwrap` is defined in the `impl<T> Option<T>` block. When we call it on a value, it will try to 'unwrap' the value that is tucked into the `Some` variant. It matches on 'self' and if the `Some` variant is present, 'val' is 'unwrapped' and returned. If the 'None' variant is present, the panic macro is called:

```rust
let something: Option<&str> = Some("Something");
let unwrapped = something.unwrap();
println!("{:?}\n{:?}", something, unwrapped);
let nothing: Option<&str> = None;
nothing.unwrap();
```
The code above will result in the following:

Some("Something")
"Something"
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src\main.rs:86:17

Calling unwrap on an Option is quick and easy but letting your program `panic` and crash is not a very elegant or safe approach.

## Option examples

Let's look at some examples where you could use an Option.

### Passing an optional value to a function

```rust
fn might_print(option: Option<&str>) {
    match option {
        Some(text) => println!("The argument contains the following value: '{}'", text),
        None => println!("The argument contains None."),
    }
}
let something: Option<&str> = Some("some str");
let nothing: Option<&str> = None;
might_print(something);
might_print(nothing);
```

This outputs the following:

The argument contains the following value: 'some str'
The argument contains None.

### Having a function return an optional value

```rust
// Returns the text if it contains target character, None otherwise:
fn contains_char(text: &str, target_c: char) -> Option<&str> {
    if text.chars().any(|ch| ch == target_c) {
        return Some(text);
    } else {
        return None;
    }
}
let a = contains_char("Rust in action", 'a');
let q = contains_char("Rust in action", 'q');
println!("{:?}", a);
println!("{:?}", q);
```
We can safely assign the return of this function to a variable and, later on, use match to determine how to handle a 'None' return. The previous code prints the following:

Some("Rust in action")
None

Let's examine three different ways to work with the Optional return.

The first one, which is the least safe, would be simply calling unwrap:

```rust
let a = contains_char("Rust in action", 'a');
let a_unwrapped = a.unwrap();
println!("{:?}", a_unwrapped);
```

The second, safer option, is to use a `match` statement:

```rust
let a = contains_char("Rust in action", 'a');
match a {
    Some(a) => println!("contains_char returned something: {:?}!", a),
    None => println!("contains_char did not return something, so branch off here"),
}
```

The third option is to capture the return of the function in a variable and use `if let`:
```rust
let a = contains_char("Rust in action", 'a');
if let Some(a) = contains_char("Rust in action", 'a') {
    println!("contains_char returned something: {:?}!", a);
} else {
    println!("contains_char did not return something, so branch off here")
}
```

### Optional values inside a struct

We can also use the `Option` inside a struct. This might be useful in case a field may or may not have any value:

```rust
#[derive(Debug)]
struct Person {
    name: String,
    age: Option<i32>,
}

let marie = Person {
    name: String::from("Marie"),
    age: Some(2),
};

let jan = Person {
    name: String::from("Jan"),
    age: None,
};
println!("{:?}\n{:?}", marie, jan);
```

The above code outputs the following:

Person { name: "Marie", age: Some(2) }
Person { name: "Jan", age: None }

### Real world example

An example where the Option is used inside Rust is the pop method for vectors. This method returns an `Option<T>`. The `pop`-method returns the last element. But it can be that a vector is empty. In that case, it should return None. An additional problem is that a vector can contain any type. In that case, it is convenient for it to return `Some(T)`. So for that reason, `pop()` returns `Option<T>`.

The `pop` method for the vec from Rust 1.53:

```rust
impl<T, A: Allocator> Vec<T, A> {
    // .. lots of other code
    pub fn pop(&mut self) -> Option<T> {
        if self.len == 0 {
            None
        } else {
            unsafe {
                self.len -= 1;
                Some(ptr::read(self.as_ptr().add(self.len())))
            }
        }
    }
    // lots of other code
}
```

A trivial example where we output the result of popping a vector beyond the point where it is still containing items:

```rust
let mut vec = vec![0, 1];
let a = vec.pop();
let b = vec.pop();
let c = vec.pop();
println!("{:?}\n{:?}\n{:?}\n", a, b, c);
```

The above outputs the following:

Some(1)
Some(0)
None

## The result

Another important construct in Rust is the `Result` enum. Same as with the Option, the Result is an enum. The definition of the Result can be found in `result.rs`:

```rust
pub enum Result<T, E> {
    /// Contains the success value
    Ok(T),
    /// Contains the error value
    Err(E),
}
```

The Result enum is generic over 2 types, given the name T and E. The T is used for the OK variant, which is used to express a successful result. The E is used for the Err variant, used to express an error value. The fact that Result is generic over E makes it possible to communicate different errors. If Result would not have been generic over E, there would just be 1 type of error. Same as there is 1 type of 'None' in Option. This would not leave a lot of room when using the error value in our flow control or reporting.

As indicated before, the Prelude brings the `Result` enum as well as the `Ok` and `Err` variants into scope in the Prelude like so:

```
std::result::Result::{self, Ok, Err}
```

This means we can access Result, Ok and Err directly at any place in our code.

### Matching on the Result

Let's start off creating an example function that returns a Result. In the example function, we check whether a string contains a minimum number of characters. The function is the following:

```rust
fn check_length(s: &str, min: usize) -> Result<&str, String> {
    if s.chars().count() >= min {
        return Ok(s)
    } else {
        return Err(format!("'{}' is not long enough!", s))
    }
}
```

It is not a very useful function, but simple enough to illustrate returning a Result. The function takes in a string literal and checks the number of characters it contains. If the number of characters is equal to, or more then 'min', the string is returned. If this is not the case, an error is returned. The return is annotated with the Result enum. We specify the types that the Result will contain when the function returns. If the string is long enough, we return a string literal. If there is an error, we will return a message that is a String. This explains the `Result<&str, String>`.

The `if s.chars().count() >= min` does the check for us. In case it evaluates to `true`, it will return the string wrapped in the `Ok` variant of the `Result` enum. The reason we can simply write `Ok(s)` is because the variants that make up Result are brought into scope as well. We can see that the `else` statement will return an `Err` variant. In this case, it is a String that contains a message.

Let's run the function and output the Result using dbg!:

```rust
let a = check_length("some str", 5);
let b = check_length("another str", 300);
dbg!(a); // Ok("some str",)
dbg!(b); // Err("'another str' is not long enough!",)
```

We can use a match expression to deal with the Result that our function returns:

```rust
let func_return = check_length("some string literal", 100);
let a_str = match func_return {
    Ok(a_str) => a_str,
    Err(error) => panic!("Problem running 'check_length':\n {:?}", error),
};
// thread 'main' panicked at 'Problem running 'check_length':
// "'some string literal' is not long enough!"'
```

### Unwrapping the Result

Instead of using a match expression, there is also a shortcut that you'll come across very often. This shortcut is the `unwrap` method that is defined for the `Result` enum. The method is defined as follows:

```rust
impl<T, E: fmt::Debug> Result<T, E> {
    ...
    pub fn unwrap(self) -> T {
        match self {
            Ok(t) => t,
            Err(e) => unwrap_failed("called `Result::unwrap()` on an `Err` value", &e),
        }
    }
    ...
}
```

Calling `unwrap` returned the contained 'Ok' value. If there is no 'Ok' value, `unwrap` will panic. In the following example, the `from_str` method returns an 'Ok' value:

```rust
use serde_json::json;
let json_string = r#"
{
    "key": "value",
    "another key": "another value",
    "key to a list" : [1 ,2]
}"#;
let json_serialized: serde_json::Value = serde_json::from_str(&json_string).unwrap();
println!("{:?}", &json_serialized);
// Object({"another key": String("another value"), "key": String("value"), "key to a list": Array([Number(1), Number(2)])})
```

We can see that 'json_serialized' contains the value that was wrapped in the 'Ok' variant.

The following demonstrates what happened when we call unwrap on a function that does not return an 'Ok' variant. Here, we call 'serde_json::from_str' on invalide JSON:

```rust
use serde_json::json;
let invalid_json = r#"
{
    "key": "v
}"#;

let json_serialized: serde_json::Value = serde_json::from_str(&invalid_json).unwrap();
/*
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error("control character (\\u0000-\\u001F) found while parsing a string", line: 4, column: 0)',
*/
```

There is a panic and the program comes to a halt. Instead of `unwrap`, we could also choose to use `expect`.

```rust
use serde_json::json;

let invalid_json = r#"
{
    "key": "v
}"#;
let b: serde_json::Value =
    serde_json::from_str(&invalid_json).expect("unable to deserialize JSON");
```
This time, when we run the code, we can also see the message that we added to it:

thread 'main' panicked at 'unable to deserialize JSON: Error("control character (\\u0000-\\u001F) found while parsing a string", line: 4, column: 0)'

Since unwrap and expect result in a panic, it ends the program, period. Most oftentimes, you'll see unwrap being used in the example section, where the focus is on the example and lack of context really prohibits proper error handling for a specific scenario. The example section, code comments and documentation examples is where you will most oftentimes encounter unwrap. See for instance the example to have serde serialize fields as camelCase:

```rust
use serde::Serialize;

#[derive(Serialize)]
#[serde(rename_all = "camelCase")]
struct Person {
    first_name: String,
    last_name: String,
}

fn main() {
    let person = Person {
        first_name: "Graydon".to_string(),
        last_name: "Hoare".to_string(),
    };

    let json = serde_json::to_string_pretty(&person).unwrap();  // <- unwrap

    // Prints:
    //
    //    {
    //      "firstName": "Graydon",
    //      "lastName": "Hoare"
    //    }
    println!("{}", json);
}
```

Example taken from the serde documentation, right here.

### Using ? and handling different errors

Different projects oftentimes define their own errors. Searching a repo for something like `pub struct Error` or `pub enum Error` can sometimes reveal the errors defined for a project. But the thing is, different crates and projects might return their own error `type`. If you have a function that uses methods from a variety of projects, and you want to propagate that error, things can get a bit trickier. There are several ways to deal with this. Let's look at an example where we deal with this by 'Boxing' the error.

In the next example, we define a function that reads the entire contents of target file into a string and then serializes it into JSON, while mapping it to a struct. The function returns a Result. The Ok variant is the 'Person' struct and the Error that will be propagated can be an error coming `serde` or `std::fs`. To be able to return errors from both these packages, we return `Result<Person, Box<dyn Error>>`. The 'Person' is the Ok variant of the Result. The Err variant is defined as `Box<dyn Error>`, which represents 'any type of error'.

Another thing worth mentioning about the following example is the use of `?`. We will use `fs::read_to_string(s)` to read a file as a string and we will use `erde_json::from_str(&text)` to serialize the text to a struct. In order to avoid having to write match arms for the Results returned by those methods, we place the `?` behind the call to those methods. This syntactic sugar will perform an `unwrap` in case the preceding Result contains an Ok. If the preceding Result contains an Err variant, it ensures that this Err is returned just as if the `return` keyword would have been used to propagate the error. And when the error is returned, our 'Box' will catch them.

The example code:

```rust
use serde::{Deserialize, Serialize};
use std::error::Error;
use std::fs;

// Debug allows us to print the struct.
// Deserialize and Serialize adds decoder and encoder capabilities to the struct.
#[derive(Debug, Deserialize, Serialize)]
struct Person {
    name: String,
    age: usize,
}

fn file_to_json(s: &str) -> Result<Person, Box<dyn Error>> {
    let text = fs::read_to_string(s)?;
    let marie: Person = serde_json::from_str(&text)?;
    Ok(marie)
}

let x = file_to_json("json.txt");
let y = file_to_json("invalid_json.txt");
let z = file_to_json("non_existing_file.txt");

dbg!(x);
dbg!(y);
dbg!(z);
```
The first time we call the function, it succeeds and `dbg!(x);` outputs the following:

[src\main.rs:20] x = Ok(
    Person {
        name: "Marie",
        age: 2,
    },
)

The second calls encounters an error. The file contains the following:

{
	"name": "Marie",
	"a
}

This file can be opened and read to a String, but Serde cannot parse it as JSON. This function call outputs the following:

[src\main.rs:21] y = Err(
    Error("control character (\\u0000-\\u001F) found while parsing a string", line: 3, column: 4),
)

We can see the Serde error was properly propagated.

The last function call tried to open a file that does not exist:

[src\main.rs:22] z = Err(
    Os {
        code: 2,
        kind: NotFound,
        message: "The system cannot find the file specified.",
    },
)

That error, coming from `std::fs`, was also properly propagated.

### using other crates: anyhow

There are many crates available to help us deal with errors. Some help us manage boilerplate code, others add features such as extra reporting. One example of a crate that is easy to use when starting out with Rust is [anyhow](https://crates.io/crates/anyhow):

{:refdef: style="text-align: center;"}
![Rust anyhow](/img/anyhow.png "Rust anyhow"){:height="80%" width="80%"}
{: refdef}

This crate will give us a simplified Result type and we can easily annotate our errors by adding context. The following code snippet illustrates the three basic things that anyhow equips us with:

```rust
use anyhow::{anyhow, Context, Result};
use serde::{Deserialize, Serialize};
use std::fs;

#[derive(Debug, Deserialize, Serialize)]
struct Secrets {
    username: String,
    password: String,
}

fn get_secrets(s: &str) -> Result<Secrets> {
    let text = fs::read_to_string(s).context("Secrets file is missing.")?;
    let secrets: Secrets =
        serde_json::from_str(&text).context("Problem serializing secrets.")?;
    if secrets.password.chars().count() < 2 {
        return Err(anyhow!("Password in secrets file is too short"));
    }
    Ok(secrets)
}
```

In the above example, `anyhow = "1.0.43"` was added to the `Cargo.toml` file. At the top, three things are brought into scope. These are `anyhow`, `Context` and `Result`. Let's discuss them one by one.
#### anyhow::Result

A (more) convenient type to work with and deal with errors. You can also use this on `main()`. The get_secrets function is where we see this Result in use. It is this enum for which traits have been implemented that make things easier. One of those traits, that we will discuss next, is called 'Context'.

If we run get_secrets and all is well, we get the following return:

```rust
let a = get_secrets("secrets.json");
dbg!(a);
```

The above will output the following:

/*
[src\main.rs:] a = Ok(
    Secrets {
        username: "username",
        password: "password",
    },
)
*/

We got a 'normal' Ok value.

#### anyhow::Context

As errors are propagated, the Context trait allows you to wrap the original error and include a message for more contextual awareness. Previously, we would open a file like so:

```rust
let text = fs::read_to_string(s)?;
```

This will open the file and unwrap the Ok variant. Alternatively, if read_to_string returns an Err, the `?` will propagate that error. Now, we have the following:

```rust
let text = fs::read_to_string(s).context("Secrets file is missing.")?;
```

We did something similar with for the serde_json::from_str method. We can use the following to trigger 2 errors:

```rust
let b = get_secrets("secrets.jsonnn");
dbg!(b);

let c = get_secrets("invalid_json.txt");
dbg!(c);
```

In the first case, there will be an error because the file does not exist. In the second case, Serde will give us an error because it cannot parse the JSON. The above functions output the following:

[src\main.rs:358] b = Err(
    Error {
        context: "Secrets file is missing.",
        source: Os {
            code: 2,
            kind: NotFound,
            message: "The system cannot find the file specified.",
        },
    },
)
[src\main.rs:361] c = Err(
    Error {
        context: "Problem serializing secrets.",
        source: Error("control character (\\u0000-\\u001F) found while parsing a string", line: 3, column: 4),
    },
)

#### anyhow::anyhow

This is a macro that you can use to have a function return an `anyhow::Error`. The following loads some JSON that contains a password that is too short (silly example I know):

```rust
let d = get_secrets("wrong_secrets.json");
dbg!(d);
```

The result would be the following:

[src\main.rs:364] d = Err(
    "Password in secrets file is too short",
)

The `anyhow` crate was forked by Jane Lusby. She created [eyre](https://crates.io/crates/eyre/0.3.7). That is also something worth checking out. Especially combined with the excellent [Rustconf 2020](https://2020.rustconf.com/talks) talk, dubbed [Error handling Isn't All About Errors](https://www.youtube.com/watch?v=rAF8mLI0naQ).

### Wrapping up

Understanding how the Option as well as the Result is used in Rust is very important. The above explanation of the Option, Result and error handling in Rust is my written account of how I learned about them. I hope this article will benefit others.

The code used in this article can be found [here](https://github.com/saidvandeklundert/LearningRust/blob/master/blog/option-and-result/src/main.rs). In addition to that, here are some additional links that are worth checking out to better understand the Option, the Result and error handling in Rust:
- The Rust Programming Language [Chapter 6](https://doc.rust-lang.org/book/ch06-00-enums.html) and [Chapter 9](https://doc.rust-lang.org/book/ch09-00-error-handling.html)
- From [Rustconf 2020](https://2020.rustconf.com/talks) talks, the [Error handling Isn't All About Errors](https://www.youtube.com/watch?v=rAF8mLI0naQ) talk by by Jane Lusby
- Error handling and dealing with multiple error types in [Rust by example](https://doc.rust-lang.org/rust-by-example/error/multiple_error_types.html)
- [Next level thoughts and ideas on errors](https://www.lpalmieri.com/posts/error-handling-rust/)
- [Wrapping errors](https://doc.rust-lang.org/rust-by-example/error/multiple_error_types/wrap_error.html)


text:
#### React Native:

It is a collection of special React components which gets compiled to Native Widgets.
In React native your define your View using React Native components instead of HTML components and define the business logic with JavaScript.
The View written in code gets compiled to Native code.
The JavaScript code with the help of JS core engine communicates with the native modules and API via a bridge.

#### To get started:

There are two CLIs available to develop and maintain React Native code;

#### Expo CLI:

Third party CLI free to use. Provides easy management because React Native can become complex when integrating native features.
Downside is you are limited to expo ecosystem.

#### React native CLI:

Maintained by React Native team. Provides bare-bone development and integrating native features can be complex. Full flexibility.
We can always switch to other CLI.

Using Expo CLI:

Install Node.js
Run “npm install expo-cli -g” in command line

Creating project:

Go to your project folder
Run “expo init <project-name>” in command line and follow the instructions
cd to your created folder and run “npm start”
Once your project starts the webpage that opens provides you with easy code development and deployment environment.

Now you are all set to go, open your code in a code editor and start coding.

To run app on a device or emulator:
You can either use the CLI webpage tool or Install the Expo Client app on your device to scan the QR code and run the app on your phone.

path: /React Native/README.md

gha_language: TypeScript


text:
---
title: Overview
page_title: Verifications Overview
description: "Verifications in Test Studio. Measure and record if an occurrence happened or did not happen as expected during a test run in Test Studio. Verifications in Test Studio can measure against multiple criteria at one time, can build measurements in an interactive manner without code, can detect if elements are in a particular state (e.g. is visible, exists), can detect if attributes and properties compare with specific values, can verify content, attributes, styles, visibility, drop-down list selections, checkboxes, radio buttons, tables and Silverlight property values"
previous_url: /user-guide/verifications.aspx, /user-guide/verifications, /features/verifications/overview
position: 0
---
# Verifications

Automation is only the starting point of testing where the browser is manipulated automatically without tester intervention. Once you've automated the interaction, you still have to test something, such as measuring and recording that an occurrence happened or did not happen as expected. There are several ways to verify elements in Test Studio:

- Quick Verification - create an easy verification from the Quick Tasks menu.

- Advanced Verification - craft a custom verification from the Sentence Verification Builder.

- Wait - does not continue until the comparison is true.

- Extraction - extract an element's value and reuse it later in your test.

- Image Verification - this feature is based on an element’s visual rendering rather than the properties or attributes of that element.

Verifications in Test Studio allow you to:

- Measure against multiple criteria at one time.
- Build these measurements in an interactive manner without code.
- Detect if elements are in a particular state (e.g. is visible, exists).
- Detect if attributes and properties compare with specific values.
- Verify content, attributes, styles, visibility, drop-down list selections, checkboxes, radio buttons, tables and Silverlight property values.

Test Studio implements verification through "sentences" that compare a portion of an element to a value, such as:

- textbox content is equal to 'order 2011'
- image path contains 'http://www.telerik.com'
- wait for element to exist

> Test Studio cannot read and verify against the contents of a PDF file loaded in the browser, as it does not have a DOM structure like a traditional web page. If you can store that information in a file type such as XLS, XML, CSV, or a SQL database, then you can use the Data Driving feature.

repository: Nickjgniklu/teststudio

repo_name: Nickjgniklu/teststudio


text:
# RBAC yaml examples

The RBAC associated with the RStudio Job Launcher is maintained in the
[rstudio-library](../../charts/rstudio-library) and
[rstudio-launcher-rbac](../../charts/rstudio-launcher-rbac) helm charts.

However, it is also maintained here in this directory [by CI](../../.github/workflows/chart-doc.yaml) for ease of use.
In order to generate these files from the chart, you can use:
```
helm repo add rstudio https://helm.rstudio.com
helm template -n rstudio rstudio-launcher-rbac rstudio/rstudio-launcher-rbac
```

> NOTE: the `rstudio-workbench` and `rstudio-connect` helm charts also use the
> `rstudio-library` chart to deploy their own RBAC

## Important Note

The rbac currently contains a `ClusterRoleBinding`, which requires a namespace
reference.

As a result, even though we use `--removeNamespaceReferences=true`, the
namespace persists on the `ClusterRoleBiding`. We use the `rstudio` namespace
by default.

Please modify the namespace as needed for your installation.

# Usage

If you are using the `rstudio` namespace (our default), then you can use either the "latest" RBAC directly:

```
kubectl apply -f https://raw.githubusercontent.com/rstudio/helm/main/examples/rbac/rstudio-launcher-rbac.yaml
```

Or you can use a particular version (versioned with the [`rstudio-launcher-rbac`](../../charts/rstudio-launcher-rbac)
helm chart):

```
kubectl apply -f https://raw.githubusercontent.com/rstudio/helm/main/examples/rbac/rstudio-launcher-rbac-0.2.2.yaml
```

repository: Aarhan/helm

repo_name: Aarhan/helm


text:
title: TestScheduler.Start<T>(Func<IObservable<T>>)
---
# TestScheduler.Start\<T\> Method (Func\<IObservable\<T\>\>)

Starts the test scheduler.

**Namespace:**  [Microsoft.Reactive.Testing](Microsoft.Reactive.Testing/Microsoft.Reactive.Testing)
**Assembly:**  Microsoft.Reactive.Testing (in Microsoft.Reactive.Testing.dll)

## Syntax

```vb
'Declaration
Public Function Start(Of T) ( _
    create As Func(Of IObservable(Of T)) _
) As ITestableObserver(Of T)
```

```vb
'Usage
Dim instance As TestScheduler
Dim create As Func(Of IObservable(Of T))
Dim returnValue As ITestableObserver(Of T)

returnValue = instance.Start(create)
```

```csharp
public ITestableObserver<T> Start<T>(
    Func<IObservable<T>> create
)
```

```c++
public:
generic<typename T>
ITestableObserver<T>^ Start(
    Func<IObservable<T>^>^ create
)
```

```fsharp
member Start :
        create:Func<IObservable<'T>> -> ITestableObserver<'T>
```

```javascript
JScript does not support generic types and methods.
```

#### Type Parameters

- T

#### Parameters

- create
  Type: [System.Func](https://msdn.microsoft.com/en-us/library/Bb534960)\<[IObservable](https://msdn.microsoft.com/en-us/library/Dd990377)\<T\>\>
  The factory method to create an observable sequence.

#### Return Value

Type: [Microsoft.Reactive.Testing.ITestableObserver](ITestableObserver/ITestableObserver(T))\<T\>
The testable observer with recordings of notifications that occurred.

## See Also

#### Reference

[TestScheduler Class](TestScheduler/TestScheduler)

[Start Overload](Start/TestScheduler.Start)

[Microsoft.Reactive.Testing Namespace](Microsoft.Reactive.Testing/Microsoft.Reactive.Testing)

# TestScheduler.Start\<T\> Method (Func\<IObservable\<T\>\>, Int64)

Starts the test scheduler.

**Namespace:**  [Microsoft.Reactive.Testing](Microsoft.Reactive.Testing/Microsoft.Reactive.Testing)
**Assembly:**  Microsoft.Reactive.Testing (in Microsoft.Reactive.Testing.dll)

## Syntax

```vb
'Declaration
Public Function Start(Of T) ( _
    create As Func(Of IObservable(Of T)), _
    disposed As Long _
) As ITestableObserver(Of T)
```

```vb
'Usage
Dim instance As TestScheduler
Dim create As Func(Of IObservable(Of T))
Dim disposed As Long
Dim returnValue As ITestableObserver(Of T)

returnValue = instance.Start(create, disposed)
```

```csharp
public ITestableObserver<T> Start<T>(
    Func<IObservable<T>> create,
    long disposed
)
```

```c++
public:
generic<typename T>
ITestableObserver<T>^ Start(
    Func<IObservable<T>^>^ create,
    long long disposed
)
```

```fsharp
member Start :
        create:Func<IObservable<'T>> *
        disposed:int64 -> ITestableObserver<'T>
```

```javascript
JScript does not support generic types and methods.
```

#### Type Parameters

- T

#### Parameters

- create
  Type: [System.Func](https://msdn.microsoft.com/en-us/library/Bb534960)\<[IObservable](https://msdn.microsoft.com/en-us/library/Dd990377)\<T\>\>
  The factory method to create an observable sequence.

- disposed
  Type: [System.Int64](https://msdn.microsoft.com/en-us/library/6yy583ek)
  The virtual time at which to dispose the subscription.

#### Return Value

Type: [Microsoft.Reactive.Testing.ITestableObserver](ITestableObserver/ITestableObserver(T))\<T\>
The testable observer with recordings of notifications that occurred.

## See Also

#### Reference

[TestScheduler Class](TestScheduler/TestScheduler)

[Start Overload](Start/TestScheduler.Start)

[Microsoft.Reactive.Testing Namespace](Microsoft.Reactive.Testing/Microsoft.Reactive.Testing)

# TestScheduler.Start\<T\> Method (Func\<IObservable\<T\>\>, Int64, Int64, Int64)

Starts the test scheduler.

**Namespace:**  [Microsoft.Reactive.Testing](Microsoft.Reactive.Testing/Microsoft.Reactive.Testing)
**Assembly:**  Microsoft.Reactive.Testing (in Microsoft.Reactive.Testing.dll)

## Syntax

```vb
'Declaration
Public Function Start(Of T) ( _
    create As Func(Of IObservable(Of T)), _
    created As Long, _
    subscribed As Long, _
    disposed As Long _
) As ITestableObserver(Of T)
```

```vb
'Usage
Dim instance As TestScheduler
Dim create As Func(Of IObservable(Of T))
Dim created As Long
Dim subscribed As Long
Dim disposed As Long
Dim returnValue As ITestableObserver(Of T)

returnValue = instance.Start(create, created, _
    subscribed, disposed)
```

```csharp
public ITestableObserver<T> Start<T>(
    Func<IObservable<T>> create,
    long created,
    long subscribed,
    long disposed
)
```

```c++
public:
generic<typename T>
ITestableObserver<T>^ Start(
    Func<IObservable<T>^>^ create,
    long long created,
    long long subscribed,
    long long disposed
)
```

```fsharp
member Start :
        create:Func<IObservable<'T>> *
        created:int64 *
        subscribed:int64 *
        disposed:int64 -> ITestableObserver<'T>
```

```javascript
JScript does not support generic types and methods.
```

#### Type Parameters

- T

#### Parameters

- create
  Type: [System.Func](https://msdn.microsoft.com/en-us/library/Bb534960)\<[IObservable](https://msdn.microsoft.com/en-us/library/Dd990377)\<T\>\>
  Factory method to create an observable sequence.

- created
  Type: [System.Int64](https://msdn.microsoft.com/en-us/library/6yy583ek)
  Virtual time at which to invoke the factory to create an observable sequence.

- subscribed
  Type: [System.Int64](https://msdn.microsoft.com/en-us/library/6yy583ek)
  The virtual time at which to subscribe to the created observable sequence.

- disposed
  Type: [System.Int64](https://msdn.microsoft.com/en-us/library/6yy583ek)
  The virtual time at which to dispose the subscription.

#### Return Value

Type: [Microsoft.Reactive.Testing.ITestableObserver](ITestableObserver/ITestableObserver(T))\<T\>
The testable observer with recordings of notifications that occurred.

## See Also

#### Reference

[TestScheduler Class](TestScheduler/TestScheduler)

[Start Overload](Start/TestScheduler.Start)

[Microsoft.Reactive.Testing Namespace](Microsoft.Reactive.Testing/Microsoft.Reactive.Testing)

repository: reactiveui/website

gha_language: HTML

repo_name: reactiveui/website


text:
# KARA
## Kara, another request analyzer
an HTTP bin in Java

Test it out at [https://kara.rest](https://kara.rest)

I made this for me an my colleagues, tailored to our needs.

## Features
 * Websocket interface
 * Custom response bodies
 * REST api for retrieving bins, results or parts thereof (See the openApi definition)
 * MQTT support
 * docker container available at https://hub.docker.com/r/yunzlez/kara/

## Stuff I wanna do at some point
 * Replace thymeleaf interface with React, or something
 * Support custom headers & cookies in the response
 * Support simple template responses (Some work already done, such as an ANTLR4 grammar)
 * Statistics (With fancy graphs)
 * Scriptable responses
 * Externalize configuration
 * Support for something else than MySQL

## How to run
You need:
 * Java 11
 * MySQL 8

You do:
 * mvn package
 * just `java -jar kara-bin-1.3.0.jar`, although setting an XMX is a good idea. I found 128M to be a good value. I use:`java -Xmx128M -XX:+UseG1GC -XX:+UseStringDeduplication -XX:-TieredCompilation -jar kara-bin-1.3.0.jar -Dspring.profiles.active=remote`

You can pass the following options using -D :
* spring.datasource.url -> JDBC connections string. Use 'kara' as the schema, other names are not yet supported
* spring.datasource.username -> DB username
* spring.datasource.password -> DB Pass
* server.use-forward-headers -> true if running behind proxy (default). Kara needs this to detect the base URL.
* mqtt.broker.url -> broker to use if MQTT is enabled
* mqtt.enabled -> enable MQTT
* mqtt.clientid -> ClientId to use for publishing
* logging.level.be.zlz.kara -> The logging level

You can also run using  `-Dspring.profiles.active=docker`, which allows you to use environment variables for some of these settings:
* DATABASE_URI -> The database URI (not a jdbc string, just the host)
* DATABASE_USR -> DB user
* DATABASE_PWD -> DB password
* MQTT_ENDPOINT -> The MQTT broker uri
* MQTT_ENABLED -> Whether to enable MQTT (default true)

Obviously, you can mix these up with the previous set of settings.

repository: Yunzlez/kara

gha_language: Java

repo_name: Yunzlez/kara