text:
# React Drawer

A React version of an [MDC Drawer](https://github.com/material-components/material-components-web/tree/master/packages/mdc-drawer).

## Installation

```
npm install @material/react-drawer
```

## Usage

### Styles

with Sass:
```js
import<EMAIL_ADDRESS>```

with CSS:
```js
import<EMAIL_ADDRESS>```

### Javascript Instantiation

#### Basic Usage

Below is the basic example of a drawer. `<SomeDrawerContent />` is not defined, but can be any element. Guidelines state it should be navigational content. Typically it is a [list](https://material.io/design/components/lists.html).

```js
import React, {Component} from 'react';
import Drawer from '@material/react-drawer';

class MyApp extends Component {
  render() {
    return (
      <Drawer>
        <SomeDrawerContent />
      </Drawer>
    );
  }
}
```

#### Header and Content Variant

You may want to include a header, which MDC Web has already styled for you. For convenience, we've included `<DrawerHeader />`, `<DrawerSubtitle />`, `<DrawerTitle />`, and `<DrawerContent />` components. `DrawerHeader` and `DrawerContent` default to a `<div>` tag, while the `DrawerTitle` and `DrawerSubtitle` default to an `h3` and `h6` tag respectively, but can be customized with the `tag` prop (example shown below).

```js
import React, {Component} from 'react';
import Drawer, {
  DrawerHeader,
  DrawerSubtitle,
  DrawerTitle,
  DrawerContent,
} from '@material/react-drawer';

class MyApp extends Component {
  render() {
    return (
      <Drawer>
        <DrawerHeader> {/*defaults to div*/}
          <DrawerTitle tag='h2'> {/*defaults to h3*/}
            Inbox
          </DrawerTitle>
          <DrawerSubtitle> {/*defaults to h6*/}
<EMAIL_ADDRESS>          </DrawerSubtitle>
        </DrawerHeader>

        <DrawerContent tag='main'>  {/*defaults to div*/}
          <SomeDrawerContent />
        </DrawerContent>
      </Drawer>
    );
  }
}
```

#### Dismissible Variant

The 2 previous examples are both permanent drawer examples, which are stationary. If you have a smaller screen, or want to keep focus on your main content you may want to use a [dismissible drawer](https://github.com/material-components/material-components-web/tree/master/packages/mdc-drawer#dismissible-drawer). The dismissible drawer will expand and collapse based on the `open` prop.

You will also want to use the `<DrawerAppContent />` component, which will wrap around your content, that should animate in/out with the dismissible drawer.

```js
import React, {Component} from 'react';
import Drawer, {DrawerAppContent} from '@material/react-drawer';

class MyApp extends Component {
  state = {open: false};

  render() {
    return (
      <div>
        <Drawer
          dismissible
          open={this.state.open}
        >
          <SomeDrawerContent />
        </Drawer>
        <DrawerAppContent>
          Your really cool app content here
          <button onClick={() => this.setState({open: !this.state.open})}>
            {this.state.open ? 'Open' : 'Close'} Drawer
          </button>
        </DrawerAppContent>
      </div>
    );
  }
}
```

#### Usage with Top App Bar

##### Full height drawer

If you want the dismissible drawer or permanent drawer to appear to the side of the top app bar (take the full height of the screen) as shown in the below image, please follow this markup:

![adjacent](https://user-images.githubusercontent.com/579873/47814040-e9b1fc00-dd09-11e8-9435-1b34c1f4664d.png)

```js
import React, {Component} from 'react';
import TopAppBar, {TopAppBarFixedAdjust} from '@material/react-top-app-bar';
import Drawer, {DrawerAppContent, DrawerContent, DrawerHeader, DrawerTitle} from '@material/react-drawer';
import MaterialIcon from '@material/react-material-icon';
import List, {ListItem, ListItemGraphic, ListItemText} from '@material/react-list';

// includes imports for drawer, list, material icon and top app bar styles
import './App.scss';

export default class App extends Component {
  state = {selectedIndex: 0};

  render() {
    return (
      <div className='drawer-container'>
        <Drawer>
          <DrawerHeader>
            <DrawerTitle tag='h2'>
<EMAIL_ADDRESS>            </DrawerTitle>
          </DrawerHeader>

          <DrawerContent>
            <List singleSelection selectedIndex={this.state.selectedIndex}>
              <ListItem>
                <ListItemGraphic graphic={<MaterialIcon icon='folder'/>} />
                <ListItemText primaryText='Mail' />
              </ListItem>
            </List>
          </DrawerContent>
        </Drawer>

        <DrawerAppContent className='drawer-app-content'>
          <TopAppBar
            title='Inbox'
            navigationIcon={<MaterialIcon icon='menu' />}
          />

          <TopAppBarFixedAdjust>
            Your inbox content
          </TopAppBarFixedAdjust>
        </DrawerAppContent>
      </div>
    );
  }
}

```

You will also need these styles:

```css

.drawer-container {
  display: flex;
  flex-direction: row;
  height: 100vh;
  overflow: hidden;
}

.drawer-app-content {
  flex: auto;
  overflow: auto;
}
```

##### Dismissible or Permanent drawer below top app bar

If you want the dismissible drawer or permanent drawer to appear below the top app bar as shown in the below image, please follow this markup:

![below](https://user-images.githubusercontent.com/579873/47814058-f171a080-dd09-11e8-9d66-6da4d936905c.png)

```js
import React, {Component} from 'react';
import TopAppBar, {TopAppBarFixedAdjust} from '@material/react-top-app-bar';
import Drawer, {DrawerAppContent, DrawerContent, DrawerHeader, DrawerTitle} from '@material/react-drawer';
import MaterialIcon from '@material/react-material-icon';
import List, {ListItem, ListItemGraphic, ListItemText} from '@material/react-list';

// includes imports for drawer, list, material icon and top app bar styles
import './App.scss';

export default class App extends Component {
  state = {selectedIndex: 0};

  render() {
    return (
      <div className='drawer-container'>
        <TopAppBar title='Inbox'/>

        <TopAppBarFixedAdjust className='top-app-bar-fix-adjust'>
          <Drawer>
            <DrawerHeader>
              <DrawerTitle tag='h2'>
<EMAIL_ADDRESS>              </DrawerTitle>
            </DrawerHeader>

            <DrawerContent>
              <List singleSelection selectedIndex={this.state.selectedIndex}>
                <ListItem>
                  <ListItemGraphic graphic={<MaterialIcon icon='folder'/>} />
                  <ListItemText primaryText='Mail' />
                </ListItem>
              </List>
            </DrawerContent>
          </Drawer>

          <DrawerAppContent className='drawer-app-content'>
            Your inbox content
          </DrawerAppContent>
        </TopAppBarFixedAdjust>
      </div>
    );
  }
}

```

You will also need these styles:

```css
.drawer-container {
  display: flex;
  flex-direction: row;
  height: 100vh;
  overflow: hidden;
}

.drawer-app-content {
  flex: auto;
  overflow: auto;
}

.top-app-bar-fix-adjust {
  display: flex;
  width: 100%;
}
```

There is a known issue with the dismissible drawer styles when putting the drawer below the top app bar. To get around this, you must update the `.mdc-drawer--dismissible` class in your CSS stylesheets.

```css
.mdc-drawer--dismissible {
  top: auto;
}
```

> _NOTE_: Ordering of the markup is imperative.

#### Modal Variant

If you are on a smaller screen and do not want to animation your content, you may want to use the [modal drawer](https://github.com/material-components/material-components-web/tree/master/packages/mdc-drawer#modal-drawer). The modal drawer will expand and collapse based on the `open` prop overlayed your application content.

You should also implement the `onClose` callback prop, which is triggered after the drawer closes. This is your opportunity to set the `open` state variable to false.

> NOTE: Closes with `esc` key or `scrim` click.

```js
import React, {Component} from 'react';
import Drawer, {DrawerAppContent} from '@material/react-drawer';

class MyApp extends Component {
  state = {open: false};

  render() {
    return (
      <div>
        <Drawer
          modal
          open={this.state.open}
          onClose={() => this.setState({open: false})}
        >
          <SomeDrawerContent />
        </Drawer>
        <div>
          Your really cool app content here
          <button onClick={() => this.setState({open: !this.state.open})}>
            {this.state.open ? 'Open' : 'Close'} Drawer
          </button>
        </div>
      </div>
    );
  }
}
```

### Accessibility

#### Focus Management

It is recommended to shift focus to the first focusable element in the main content when drawer is closed or one of the destination items is activated. (By default, MDC React Drawer restores focus to the menu button which opened it.)

> _NOTE_: There is also a known bug due to the use of <FocusTrap />. There must be a focusable item in your drawer when using the modal variant. For now, insert an empty `<a />` into your drawer as a workaround.

#### Dismissible Drawer

Restore focus to the first focusable element when a list item is activated or after the drawer closes. Do not close the drawer upon item activation, since it should be up to the user when to show/hide the dismissible drawer.

```js
import React, {Component} from 'react';
import Drawer from '@material/react-drawer';
import Button from '@material/react-button';

class Drawer extends Component {
  mainContentEl = React.createRef();

  focusFirstFocusableItem = () => {
    this.mainContentEl.current.querySelector('input, button').focus();
  }

  onDrawerClose = () => {
    this.setState({open: false});
    this.focusFirstFocusableItem();
  }

  render() {

    return (
      <div>
        <Drawer
          modal
          open={this.state.open}
          onClose={this.drawerOnClose}
        >
          <List>
            <ListItem onClick={this.focusFirstFocusableItem}>
              <ListItemText primaryText='list item' />
            </ListItem>
          </List>
        </Drawer>
        <div ref={this.mainContentEl}>
          <Button raised>Click me!</Button>
        </div>
      </div>
    );
  }
}
```

#### Modal Drawer

Close the drawer when an item is activated in order to dismiss the modal as soon as the user performs an action. Only restore focus to the first focusable element in the main content after the drawer is closed, since it's being closed automatically.

```js
import React, {Component} from 'react';
import Drawer from '@material/react-drawer';
import Button from '@material/react-button';

class Drawer extends Component {
  mainContentEl = React.createRef();

  onDrawerClose = () => {
    this.setState({open: false});
    this.mainContentEl.current.querySelector('input, button').focus();
  }

  onListItemClick = () => this.onDrawerClose();

  render() {

    return (
      <div>
        <Drawer
          modal
          open={this.state.open}
          onClose={this.drawerOnClose}
        >
          <List>
            <ListItem onClick={this.onListItemClick}>
              <ListItemText primaryText='list item' />
            </ListItem>
          </List>
        </Drawer>
        <div ref={this.mainContentEl}>
          <Button raised>Click me!</Button>
        </div>
      </div>
    );
  }
}
```

## Props

### Drawer

Prop Name | Type | Description
--- | --- | ---
className | String | Classes to be applied to the drawer element.
onOpen | Function() => void | Callback after the drawer has opened.
onClose | Function() => void | Callback after the drawer has closed.
modal | Boolean | Indicates that the drawer is of type modal.
dismissible | Boolean | Indicates that the drawer is of type dismissible.
tag | String | Customizes the drawer tag type (default to `<aside>`).
open | boolean | If true, opens drawer. If false, closes drawer.
innerRef | RefObject | Root drawer element ref.

## Sass Mixins

Sass mixins may be available to customize various aspects of the Components. Please refer to the
MDC Web repository for more information on what mixins are available, and how to use them.

[Advanced Sass Mixins](https://github.com/material-components/material-components-web/tree/master/packages/mdc-drawer#sass-mixins)


text:
# DFRobot_OxygenSensor
DFRobot's OxygenSensor

## DFRobot_OxygenSensor Library for Arduino
---------------------------------------------------------
Arduino library is provided for reading oxygen concentrations through I2C and gas sensors.
Used to read the ozone and oxygen concentrations of the current module

## Table of Contents

* [Installation](#installation)
* [Methods](#methods)
* [Compatibility](#compatibility)
* [History](#history)
* [Credits](#credits)

<snippet>
<content>

## Installation

To use this library download the zip file, uncompress it to a folder named DFRobot_OxygenSensor.
Download the zip file first to use this library and uncompress it to a folder named DFRobot_OxygenSensor.

## Methods

```C++
class DFRobot_OxygenSensor{
public:

 /*
  * @brief initialization parameters for i2c.
  *
  * @param addr is I2c device number.
  *     iic slave Address, The default is ADDRESS 3.
  *     ADDRESS_0               0x70           // iic slave Address
  *     ADDRESS_1               0x71
  *     ADDRESS_2               0x72
  *     ADDRESS_3               0x73
  *
  * @return true and false.
  */
   bool begin(uint8_t addr);

 /*
  * @brief Calibrate Oxygen sensor
  *
  * @param vol is oxygen concentration
  *
  * @param mv  is mv
  *  1. Directly calibrate the oxygen sensor by adding two parameters to the sensor
  *  2. Waiting for stable oxygen sensors for about 10 minutes,
  *     OXYGEN_CONECTRATION is the current concentration of oxygen in the air (20.9%mol except in special cases)
  *     Not using the first calibration method, the OXYGEN MV must be 0.
  */
   void Calibrate(float vol, float mv)

 /*
  * @brief read Oxygen data.
  *
  * @return Percent oxygen concentration.
  */
   float ReadOxygenData();
};

```
## Compatibility

MCU                | Work Well | Work Wrong | Untested  | Remarks
------------------ | :----------: | :----------: | :---------: | -----
FireBeetle-ESP32  |      √       |             |            |
FireBeetle-ESP8266|      √       |              |             |
Mega2560  |      √       |             |            |
Arduino uno |       √      |             |            |
Leonardo  |      √       |              |             |

## History

- October 10, 2019 - Version 0.2 released.

## Credits

Written by ZhixinLiu(zhixin.liu@dfrobot.com), 2019. (Welcome to our [website](https://www.dfrobot.com/))

license: MIT

branch_name: refs/heads/main

extension: md

license_type: permissive


text:
# R2RML Test-Cases support

Test the capabilities of your R2RML engine with the [R2RML test cases](https://www.w3.org/2001/sw/rdb2rdf/test-cases/). Use the resources provided in this repository to automatically generate an EARL report with your results. Go to the [R2RML implementation report](https://github.com/kg-construct/r2rml-implementation-report/) repository to see how to include the generated report.

**IMPORTANT INFORMATION ABOUT THE R2RML IMPLEMENTATION REPORT:**
- This repository does NOT include any engine report
- The support resources provided here can be: forked, downloaded or cloned but no PR with the report is needed. A recommendation to maintain up-to-date the resources of this repository is to add a submodule directly to your github repo.
- Read carefully the documentation provided, and open an issue if you have any question or doubt.

## Requirements for creating the EARL implementation report:

- Linux based OS
- Docker and docker-compose
- Python
- Java

## RDBMS coverage and properties info:

- MySQL (`port = 3306`)
- PostgreSQL (`port = 5432`)

Connection properties for any RDBMS are: `database = r2rml, user = r2rml, password = r2rml`.

For testing purposes, **mapping path is invariable, it is always `./r2rml.ttl`**

## Steps to generate the results from the R2RML test-cases:

1. Create a submodule (recommended) or fork/clone/download this repository.
2. Include a way to run your engine with the resources of this folder.
3. Install the requirements of the script `python3 -m pip install -r requirements.txt`
4. Modify the config.ini file with your information. For the correspoding configurating of your R2RML engine, remember that the path of the **mapping file is always ./r2rml.ttl**. For example:

```
[tester]
tester_name: David Chaves # tester name
tester_url: https://dchaves.oeg-upm.net/ # tester homepage
tester_contact<EMAIL_ADDRESS># tester contact

[engine]
test_date: 2021-01-07 # engine test-date (YYYY-MM-DD)
engine_version: 3.12.5 # engine version
engine_name: Morph-RDB # engine name
engine_created: 2013-12-01 # engine date created (YYYY-MM-DD)
engine_url: https://morph.oeg.fi.upm.es/tool/morph-rdb # URL of the engine (e.g., GitHub repo)

[properties]
database_system: [mysql|postgresql] # choose only one
output_results: ./output.ttl # path to the result graph of your engine
output_format: ntriples # output format of the results from your engine
engine_command: java -jar morph-rdb.jar -p properties.properties # command to run your engine
```

5. Run the script `python3 test.py config.ini`
6. Your results will appear in `results.ttl` in RDF and in `results.csv` in CSV.
7. Upload or update the obtained results the access point you have provided in the configuration step.
8. For each new version of your engine, repeat the process from step 4 to 7.

Overview of the testing steps:
![Testing setp](misc/test.png?raw=true "Testing setp")

### Notes
- The MySQL Docker container stores timestamps as UTC. Values that are retrieved from the database may therefore not correspond with the time zone of the host. If you notice that a test fails because the times are off, try appending `?useLegacyDatetimeCode=false&serverTimezone=XXX`, where `XXX` corresponds with your [IANA Time Zone Database](https://www.iana.org/time-zones) entry (e.g., `Europe/Brussels`), to the JDBC connection URL.


text:
# Fable.Elmish.Demetrix

This is a collection of helpers used in Fable.Elmish within Demetrix, open sourced in the hope they will be useful to the community. We are currently experimenting to find what fits best the needs of most users, so the API is subject to change until the first stable release.

- Install dependencies: `npm install`
- Build: `npm run build`

branch_name: refs/heads/master

gha_language: F#


text:
# My Paper Title

This repository is the official implementation of [Federated Kernel k-Means: A Privacy Preserving and Communication Efficient Approach].

## Requirements

To install requirements:

```setup
pip install -r requirements.txt
```

## Training and Evaluation

In the experiment of this paper, one Coordinator process and five Worker processes are generated to simulate the cloud server and five users' devices, respectively.

To prepare a dataset (e.g., the Mushrooms dataset) for training, the features of the dataset need to be stored as a two-dimension array whose size is n_samples * n_features. The features then needs to be partitioned into five parts  (and the label are partitioned accordingly). Each part is saved as a '.npy' file (e.g., one part of the features is saved as 'mushroom_feature1.npy' and the corresponding part of the labels is saved as 'mushroom_label1.npy'). These files are stored in a path whose name is the name of the dataset (e.g., the files of the Mushrooms dataset are stored in the path ./mushroom/). Due to the limitation of the size of the supplementary meterial, only the Mushrooms dataset that has been preprocessed is provided in the supplementary meterial.

To train the model over the Mushrooms dataset, run this command:

```train
mpiexec -n 6 python train.py --n_clusters 2 --n_components 15 --n_nodes 5 --gamma 0.011935614675340699 --dataset mushroom --index 0 --n_dim 4 --n_iterations 50
```

To train the model over the MNIST dataset, run this command:

```train
mpiexec -n 6 python train.py --n_clusters 10 --n_components 200 --n_nodes 5 --gamma 0.0028533628985793905 --dataset mnist --index 0 --n_dim 12 --n_iterations 50
```

To train the model over the Covtype dataset, run this command:

```train
mpiexec -n 6 python train.py --n_clusters 7 --n_components 30 --n_nodes 5 --gamma 0.05098145937100924 --dataset covtype --index 0 --n_dim 10 --n_iterations 50
```
The evaluation part is included in `train.py`, and it will output a normalzed mutual inforation (NMI) score of the trained model.
## Results

Our model achieves the following average NMI socres after 50 iterations:

| Dataset name       |  Mushrooms  |    MNIST    |   Covtype   |
| ------------------ |-------------|-------------|-------------|
| Average NMI score  |    0.545    |    0.473    |    0.141    |

repository: xiaochenzhou/releasing-research-code

gha_license_id: MIT

repo_name: xiaochenzhou/releasing-research-code


text:
# Deadqueue [![Latest Version](https://img.shields.io/crates/v/deadqueue.svg)](https://crates.io/crates/deadqueue) [![Build Status](https://travis-ci.org/bikeshedder/deadqueue.svg?branch=master)](https://travis-ci.org/bikeshedder/deadqueue)

Deadqueue is a dead simple async queue with back pressure support.

This crate provides three implementations:

- Unlimited (`deadqueue::unlimited::Queue`)
  - Based on `crossbeam_queue::SegQueue`
  - Has unlimitied capacity and no back pressure on push
  - Enabled via the `unlimited` feature in your `Cargo.toml`

- Resizable (`deadqueue::resizable::Queue`)
  - Based on `deadqueue::unlimited::Queue`
  - Has limited capacity with back pressure on push
  - Supports resizing
  - Enabled via the `resizable` feature in your `Cargo.toml`

- Limited (`deadqueue::limited::Queue`)
  - Based on `crossbeam_queue::ArrayQueue`
  - Has limit capacity with back pressure on push
  - Does not support resizing
  - Enabled via the `limited` feature in your `Cargo.toml`

## Features

| Feature | Description | Extra dependencies | Default |
| ------- | ----------- | ------------------ | ------- |
| `unlimited` | Enable unlimited queue implementation | – | yes |
| `resizable` | Enable resizable queue implementation | `deadqueue/unlimited` | yes |
| `limited` | Enable limited queue implementation | – | yes |

## Example

```rust
use std::sync::Arc;
use tokio::time::{sleep, Duration};

const TASK_COUNT: usize = 1000;
const WORKER_COUNT: usize = 10;

type TaskQueue = deadqueue::limited::Queue<usize>;

#[tokio::main]
async fn main() {
    let queue = Arc::new(TaskQueue::new(TASK_COUNT));
    for i in 0..TASK_COUNT {
        queue.try_push(i).unwrap();
    }
    for worker in 0..WORKER_COUNT {
        let queue = queue.clone();
        tokio::spawn(async move {
            loop {
                let task = queue.pop().await;
                println!("worker[{}] processing task[{}] ...", worker, task);
            }
        });
    }
    while queue.len() > 0 {
        println!("Waiting for workers to finish...");
        sleep(Duration::from_millis(100)).await;
    }
    println!("All tasks done. :-)");
}
```

## Reasons for yet another queue

Deadqueue is by no means the only queue implementation available. It does things a little different and provides features that other implementations are lacking:

- **Resizable queue.** Usually you have to pick between `limited` and `unlimited` queues. This crate features a `resizable` Queue which can be resized as needed. This is probably a big **unique selling point** of this crate.

- **Introspection support.** The methods `.len()`, `.capacity()` and `.available()` provide access the current state of the queue.

- **Fair scheduling.** Tasks calling `pop` will receive items in a first-come-first-serve fashion. This is mainly due to the use of `tokio::sync::Semaphore` which is fair by nature.

- **One struct, not two.** The channels of `tokio`, `async_std` and `futures-intrusive` split the queue in two structs (`Sender` and `Receiver`) which makes the usage sligthly more complicated.

- **Bring your own `Arc`.** Since there is no separation between `Sender` and `Receiver` there is also no need for an internal `Arc`. (All implementations that split the channel into a `Sender` and `Receiver` need some kind of `Arc` internally.)

- **Fully concurrent access.** No need to wrap the `Receiver` part in a `Mutex`. All methods support concurrent accesswithout the need for an additional synchronization primitive.

- **Support for `try__` methods.** The methods `try_push` and `try_pop` can be used to access the queue from non-blocking synchroneous code.

## Alternatives

| Crate | Limitations | Documentation |
| --- | --- | --- |
| [`tokio`](https://crates.io/crates/tokio) | No resizable queue. No introspection support. Synchronization of `Receiver` needed. | [`tokio::sync::mpsc::channel`](https://docs.rs/tokio/latest/tokio/sync/mpsc/fn.channel.html), [`tokio::sync::mpsc::unbounded_channel`](https://docs.rs/tokio/latest/tokio/sync/mpsc/fn.unbounded_channel.html) |
| [`async-std`](https://crates.io/crates/async-std) | No resizable or unlimited queue. No introspection support. No `try_send` or `try_recv` methods. | [`async_std::sync::channel`](https://docs.rs/async-std/latest/async_std/sync/fn.channel.html) |
| [`futures`](https://crates.io/crates/futures) | No resizable queue. No introspection support. | [`futures::channel::mpsc::channel`](https://docs.rs/futures/0.3.1/futures/channel/mpsc/fn.channel.html), [`futures::channel::mpsc::unbounded`](https://docs.rs/futures/0.3.1/futures/channel/mpsc/fn.unbounded.html) |

## License

Licensed under either of

- Apache License, Version 2.0 ([LICENSE-APACHE](LICENSE-APACHE) or <http://www.apache.org/licenses/LICENSE-2.0)>
- MIT license ([LICENSE-MIT](LICENSE-MIT) or <http://opensource.org/licenses/MIT)>

at your option.

repository: bikeshedder/deadqueue

gha_language: Rust

repo_name: bikeshedder/deadqueue


text:
## Node Modules installation

When you create project for first time and you want to have latest version of `node_modules`, delete `dependencies` and `devDependencies` block in `package.json`.

After that, launch following commands.

### Dependencies

```sh
npm install --save request rxjs
```

### Development Dependencies

```sh
npm install --save-dev del gulp gulp-jshint gulp-jsonminify gulp-load-plugins gulp-size gulp-uglify jshint jshint-stylish require-dir uglify-save-license gulp-babel coveralls babel-preset-es2015 mocha unit.js istanbul@next gulp-sourcemaps gulp-filter babelify browserify vinyl-buffer vinyl-source-stream
```

## Conclusion

These packages are the minimal required to execute the project.

You can install after that all needed packages in `dependencies` or `devDependencies` to perform your project.

repository: jayphelps/rx-http-request

repo_name: jayphelps/rx-http-request


text:
# SwiftyDSB

Hello guys :)

Today I try to implement my own [npm](https://github.com/TheNoim/DSBAPI) module with swift. It is still Work in Progress and not useable at the moment.

If you need to fetch something from the dsb use my javascript module -> [Link](https://github.com/TheNoim/DSBAPI)

### Documentation
[https://noim.me/SwiftyDSB/index.html](https://noim.me/SwiftyDSB/index.html)

### Installation
ETA soon :)

### Note
You need to override the dependencies
```swift
def swift4_overrides
  pod "GzipSwift", :git => "https://github.com/1024jp/GzipSwift.git", :branch => "swift4"
  pod "SwiftyJSON", :git => "https://github.com/SwiftyJSON/SwiftyJSON.git"
end
```

repository: TheNoim/SwiftyDSB

repo_name: TheNoim/SwiftyDSB


text:
# DevSecOps Architecture

The architecture of this project lends itself directly to fulfilling the principles found
in https://tech.gsa.gov/guides/dev_sec_ops_guide/.  The overall idea behind this project is
to create a template that people can clone, add their application to, provision some GCP
Projects, and then enable CircleCI
to automatically provision dev/staging/production environments into those GCP Projects
with good secrets management, backups, tests, and other controls that make their project
automatically use best DevSecOps practices, making it easy for people to get an ATO.

We believe that developing a project with DevSecOps best practices will result in a much
better experience for the users, developers, and owners of projects derived from this template.

## Platform

The platform that people will be deploying to is Google Cloud Platform (GCP).  This project does not
directly address how GCP is provisioned and set up, but we have had discussions with the people in
the GSA Enterprise Systems Support Division (ICE) who are developing the process.
The rough plan is:
* There is a GSA GCP Organization run by the GSA ICE people.
* The GSA ICE group will receive requests for GCP Projects from the Project Owner.
* The request will require some sort of approval.
* Once approval is granted, GSA ICE will create GCP Project(s) for the Project Owner and give them access.

GCP Projects are fully compartmentalized subdivisions within a GCP Organization that are meant to
be used for individual application environments like dev/test/prod.  Access to one GCP Project
does not give you access to any other Project.  Billing is managed on a per-Project basis as well.

![diagram of gcp org, project, apps, and services](gcp_diagram.png)

## Project

The GCP Project is where the Project Owner will build and deploy their infrastructure and application.
The Project Owner will usually request three GCP Projects: dev, staging, production, though they may request
more if they have special deployment pipeline needs.  A terraform service account will be created, and each
GCP Project will then have it's infrastructure configured and deployed with terraform using the
CircleCI CI/CD system.  Applications will be configured and deployed as well, using gcloud tools within
CircleCI.  CircleCI will watch a set of branches (usually dev/staging/master) and deploy the code in that
branch into the appropriate GCP Project whenever there are changes.

![diagram of a CircleCI workflow](workflow.png)

Currently, our project uses Google App Engine to deploy apps which use Google Cloud SQL and KMS.  It also
stores the terraform state in an encrypted Cloud Storage bucket.  All Google App Engine apps are
deployed on instances that automatically are scaled up according to load, and are automatically updated
weekly with patched images by GCP, and are only exposed to the world by GCP-supplied
load balancers which ensure that services are accessed by https.

## App

The applications in this project are extremely simple, meant to be examples for people to look at how they
are deployed and perhaps how they have been configured to do basic/OIDC authentication.
They are not in any way useful except as an example.  When others use this template, they will
delete the example apps and create their own.

These apps are deployed whenever changes to particular branches
in github change by the CircleCI CI/CD system.  Whenever such a workflow is triggered, CircleCI will
configure and deploy the app using the gcloud tool, run tests to verify that the app is functional,
run a OWASP ZAP scan against the app to ensure that there are not obvious security vulnerabilities,
and then bring load up on the app.

One example app has been configured to run with an oauth2_proxy in front of it that is configured to authenticate
users from gsa.gov using login.gov.  The workflow here adds a deploy/test of the oauth2_proxy after the app
is up, but is otherwise the same.  This seems like it could be useful for people who do not want to implement
OIDC in their app, but it does require you to be smarter about restricting access on the backend too.  In
this example, we check whether there is an authorized header present from the proxy, and if not we reject
the connection.

General features that apps deployed into this environment should have are:
  * Apps should be relatively simple [Twelve-Factor Apps](https://12factor.net/).  An app
    with a database backend and maybe redis or some other GCP-managed services, for example.
    More complex apps with microservices or complex backend services (Elasticsearch, for example)
    are probably more suited to [GRACE](https://sites.google.com/a/gsa.gov/grace/?pli=1) for now.
  * Secrets should be generated by terraform, so that they are assured to be of a good strength/quality,
    as well as easily rotated.
  * Apps should be configured entirely through environment variables.  This means that secrets and other
    config data should be ephemeral and not hit the disk.
  * Authentication should be in front of most applications.  This is a requirement pre-ATO, and probably
    will be important to almost every other application that stores data.
  * Apps should be able to allow the OWASP ZAP scanner in so that it can do a full scan.
  * Apps should either use GCP logging-enabled libraries, or log to stdout/stderr.
  * Apps should implement health checks that are comprehensive.
  * Apps should have comprehensive tests written for them that can be executed during the
    CircleCI deployment pipeline.
  * All data that the apps store should be stored in a database or other storage service.  Local
    files are ephemeral at best, and may not be allowed to happen for some deployment types.

## Supporting Systems

There are a number of supporting systems which are used to manage the project which are not part of the
Google Cloud Platform.

### GitHub
[GitHub](https://github.com/) is the primary interface for interacting with the project once it has been deployed.
It is a service that hosts [git](https://git-scm.com/) repos that are used to manage the code for projects.
We are using a gitops-style workflow which uses GitHub as the single source of truth of what is deployed to what
environment.  Developers do not manipulate anything in GCP directly, but instead develop code and do
Pull Requests (which must be approved) to integrate code into specific protected branches, which trigger deploys into
the appropriate environment.

### CircleCI
[CircleCI](https://circleci.com/) is a [CI/CD](https://circleci.com/product/#how-it-works) service that
is used as the automation engine for our project.  When changes to particular branches in GitHub happen,
CircleCI will kick off jobs that will build, deploy, test, scan, and promote the code to the appropriate
environment (dev/staging/production, for example).

# DevSecOps Requirements

Summarizing the [DevSecOps guide](https://tech.gsa.gov/guides/dev_sec_ops_guide/) somewhat, we came up with
a list of requirements, and under each requirement, we listed how this project can fulfill the requirements on GCP.

## Application developers have a pipeline that they can use to deploy software which is considerate of security and visible to operations.
* CircleCI automates all deployment/testing/scanning/promotion tasks in a pipeline that
  automatically deploys app and infrastructure changes into the dev/staging/production environments.
* All changes to the environment and apps are done through a defined gitops-style process with
  code and automation, so the management of the infrastructure should not require most people to
  have more than readonly access to anything once the infrastructure is bootstrapped.
* Terraform generates all secrets used in the system, so there is generally no opportunity for people to
  store this data insecurely, and this also makes it easy to rotate secrets.
* All applications are configured through environment variables, so secrets and other config are generally
  ephemeral.  The only place where secrets hit the disk is in the encrypted Cloud Storage bucket where terraform
  stores it's state.
* All apps/services deployed in Google App Engine are given an SSL cert in the appspot.com domain by default.
  There are provisions for getting a cert for a custom domain as well, which most people will want to
  do for production.
* CircleCI can provide logs of what the app/infrastructure deployment automation is doing.
* GCP Log Viewer provides logs from the other side of what CircleCI is doing with deploys and
  infrastructure changes, though perhaps without the context that CircleCI access might give you.

## Application developers have a clear, self-service intake onto the platform.
* This project does not directly address how GCP is provisioned and set up,
  but from discussions with the people within GSA ICE who are developing the
  process, the rough plan is to have a GSA GCP Organization account run by
  the ICE folks who will, upon receiving an approved request from a Project
  Owner, set up GCP Project(s) for the Project Owner with a minimal set of
  permissions and services provisioned in it.

## The platform services are centralized in its infrastructure and pipeline implementation.
* The creation of GCP Projects will be controlled by GSA ICE.
* Users and service accounts in the GCP Project and their permissions are currently managed by GSA ICE.
* Billing is configured by GSA ICE.
* Users are required to use 2fa to get into the GCP Console and use GCP resources.  The current
  second factor that must be used is a U2F/FIDO key.
* The infrastructures created in the GCP Projects are fully automated by CircleCI and the code
  in this project.

## Application developers are provided base OS images and images that provide component-level functionality that has also been hardened (e.g., standard images pre-packaged with hardened components i.e. databases or web/application servers).
* App Engine instances and containers are provided and updated by google and are not configurable
  by the developers.
* App Engine instances are automatically updated/patched/restarted with zero downtime on a weekly basis.
* Services used by the application (such as Cloud SQL databases) are also updated and managed
  by Google to ensure their security.

## Application owners have full access to their application event information with monitoring and alerting flexibility for their own use. An enterprise-wide application logging and monitoring system is available.
* All logs generated by the apps/services will be pulled into the read-only Google Stackdriver Logs Viewer.
* App events can be alerted on with Google Stackdriver.
* Performance data for app instances can be viewed in the GCP Console.
* CircleCI can provide logs of what the app/infrastructure deployment automation is doing.
* GCP Log Viewer provides logs from the other side of what CircleCI is doing with deploys and
  infrastructure changes, though perhaps without the context that CircleCI access might give you.
* Google Stackdriver provides customizable alerts so that IAM changes or changes to infrastructure
  by something other than the terraform system account can raise alarms.
* GCP has a security console that does anomaly and vulnerability detection, scanning, alerting,
  and other interesting services which should provide good visibility into the security posture of
  the project.
* We believe that GSA ICE will be implementing some level of audit logging and alerting for
  users and permissions changes across the organization, but do not know specifics.
* This project attempts to turn on our own audit logs within the project so that we can listen and alert on
  unusual activity.
* GCP allows billing alerts to be configured, but we do not know if GSA ICE will
  be taking advantage of that.
* There is a billing dashboard that can be accessed
  by Project Owners as well as GSA ICE.
* Read-only log viewing access can be granted to anybody in the project, so temporary access could be
  granted to a developer or security engineer and then taken away.  We would presume that log access
  would probably be granted at the organization level already, but don't know for sure.

## Images and components undergo automatic testing and are pre-approved by security and operations groups.
* Google is continuously updating their App Engine instances and the containers they build
  the applications in to ensure the latest security patches are applied.  Instances are updated
  and relaunched weekly with zero downtime.
* Apps are not fully rolled out unless they pass a suite of tests that are defined by the developer.
* Google runs security scans on deployed applictions, and this project also is set up to
  run authenticated OWASP ZAP scans.

## The platform automatically tests new patches on applications which run on it, informing the appropriate parties if decision points are reached (e.g., if a CVE is raised on an existing piece of software, the platform can automatically update that software, test it, and inform the application developers of the change if the tests pass or indicate that the patch needs to be applied in a particular timeframe). No downtime for patching.
* Google is continuously updating their App Engine instances and the containers they build
  the applications in to ensure the latest security patches are applied.  Instances are updated
  and relaunched weekly with zero downtime.
* Apps are not fully rolled out unless they pass a suite of tests that are defined by the developer.
* Google runs security scans on deployed applictions, and this project also is set up to
  run authenticated OWASP ZAP scans.

## Platform change is conducted through strictly defined processes with clear criteria defined that allow for rapid change; the platform automates changes and endeavors to impact the minimum number of application developers through that automation.
* Changes to the apps and infrastructure are made through a defined gitops-style process, where particular
  branches are deployed automatically once an approved change lands.
* Health checks are standard for every deployment.  If healthchecks fail, traffic will be routed to other
  healthy instances, and eventually will relaunch the instance.
* Deploys are zero-downtime for production.

## Version control is a key method of managing application lifecycle, has well-defined standards for use such that any user of the platform has a baseline that is shared across all applications.
* All code for the projects deployed using this template resides in GitHub.
* Changes to the apps and infrastructure are made through a defined gitops-style process, where particular
  branches are deployed automatically once an approved change lands.
* All changes to the code will be required to have approvals on them with GitHub Protected Branches, so no
  unilateral unauthorized changes can happen, and all changes that are approved can be reviewed later on
  in case there is a problem.
* GitHub Verified checkins could be made required too for additional levels of assurance.  We would expect most
  projects to allow anybody on the project to push into the dev branch, but require approvals on pull requests
  into the staging and master branches.

## Development and operational environments are identical and immutable. Environments can be stood up and torn down via automation. All changes to the running system are logged and broadly conducted through scripting rather than actual access to the running system. All necessary tests, including security tests, are run as part of the deployment process. Development environments may be instantiated and torn down as needed.
* Separate dev/staging/production GCP Projects are requested by default.
* Separate GCP Projects can allow for fine-grained access controls so that dev/staging/prod can have
  appropriate sets of users and full to readonly access granted to them.
* Separate GCP Projects provide logical/physical resource separation so that opportunities to lateral
  from a dev environment into prod are not available.
* The dev/staging/production environments are generally identical, since they are deployed from
  the same code.  The only real differences are the data in their
  databases, and perhaps some additional access granted for debugging in the dev environment.
* App Engine instances and images are immutable, but once launched, can be logged into for
  debugging purposes by authorized users, when the running instance may be changed.  This is
  not a normal workflow, and changes are ephemeral, since the instances are relaunched every
  time there is a deploy or the google-managed weekly update.

## The only manual steps to deployment are those explicitly designed to meet application expectations (e.g., not every push to the master branch necessarily indicates a release, but a product that could be released, if there is a business reason to not automatically update).
* The only manual steps in this project are done while bootstrapping the environment, change approvals, and
  infrastructure deployment approvals.
* We depart from this directive a bit because we will automatically deploy whenever a branch changes.  Our
  take on this is that if we don't want to deploy to production, those changes should queue up in
  the staging environment rather than being merged into production.

## User management is self-service with appropriate security limitations. Secrets are created/shared between parts of the platform, without people needing to set/interact with them.
* Users of the platform are currently managed by ICE.  We hope to have Project Owner IAM roles given to
  the project owners, so that they can grant access to the different environments in a self-service way.
* Users of the platform are required to use 2fa to get into the GCP Console and use GCP resources.  The current
  second factor that must be used is a U2F/FIDO key.
* Users of the applications will be managed by the application.  We have an example of how to use login.gov
  to ensure that users are from gsa.gov, but application developers are free to use whatever system they need
  to fulfill their mission.
* Terraform generates all secrets used in the system, so there is generally no opportunity for people to
  store this data insecurely, and this also makes it easy to rotate secrets.
* All applications are configured through environment variables, so secrets and other config are generally
  ephemeral.  The only place where secrets hit the disk is in the encrypted Cloud Storage bucket where terraform
  stores it's state.

## The platform manages availability for the application owners through automation based on application need. The platform provides direct insight into application health and performance. Applications can be seamlessly moved between hosting regions/zones in reaction to DR or threat activity.
* App Engine automatically scales up and down the number of instances according to load.
* Health checks are standard for every deployment.  If healthchecks fail, traffic will be routed to other
  healthy instances, and eventually will relaunch the instance, so all apps are automatically HA.
* The production databases have daily backups automatically scheduled for them, and also are
  configured for HA and failover.
* Because the infrastructure is all code, Disaster Recovery into another region should be simple,
  only requiring a change to the terraform code to change the region and a restore of a database
  backup from the old region.

## The platform governs the overarching infrastructure supporting the applications, with defined and assess separation of network concerns. Application owners can make limited changes to their network environment sufficient to self-manage the deployment of their applications and creation of new components of their application, on their own, with appropriate compliance checks.
* This is currently a bit of a weak spot.  Google App Engine does not provide very good networking controls.
* We are hoping that we will be able to leverage GSA IT Security's relationship with the GCP folks to know
  what they recommend and/or have coming down the pipe.
* What we hope to do is be able to show how we have been able to apply fine-grained networking controls on inbound and
  outbound connections.
* We expect that the networking controls will be applied through terraform, and thus easily auditable for compliance.

## ATO processes are highly automated. Compliant code and process is reused by multiple teams. All ATOs take the same amount of time for the same system and frequent deployment is only interrupted when specific risk triggers are raised through automation. Controls can be continuously monitored and measured with automation.
* We are using [OpenControl](https://open-control.org/) and [Compliance Masonry](https://github.com/opencontrol/compliance-masonry/)
  to automate the collection of most of the information required to get a GSA LATO.
* The compliance documentation is meant to be created along with the code, which means
  that the compliance information ought to be easier to keep up to date because there
  are tools that you can use to collect and audit it.
* It should be easy to tag an ATO'ed revision in github and then review diffs between
  the tag and what is in staging to see if there is anything that requires an SCR on an ongoing basis.
* More documentation on this can be found in the [Compliance documentation](Compliance.md) for
  the template.

## Backup and data lifecycle management allows application developers to ensure that their data is maintained over time and, in the case of failure of any subsystems, that it can be recovered with potentially some gap in transactional data. Lifecycle management of the data includes capabilities to archive and manage data over a long lifetime.
* The production databases have daily backups automatically scheduled for them, and also are
  configured for HA and failover.
* All changes to the code are retained in github.

## Onboarding is largely self-service (within appropriate legal limits), and application owners have full access to their expenditures at any time. Application owners can set triggers on expenditures to manage their costs appropriately.
* User/Role management is done by the Project Owners, who will request role changes related to offboarding from the GSA ICE group.
* Billing is configured by GSA ICE.
* GCP allows billing alerts to be configured, but we do not know if GSA ICE will
  be taking advantage of this feature.
* There is a billing dashboard that can be accessed
  by Project Owners as well as GSA ICE.

# Known Issues

There are a few known issues with the project:
  * The GSA ICE team issues GCP Projects such that the Project Owner only is allowed
    specific roles like `roles/appengine.appAdmin` and so on.  This means that they will be unable
    to do things like activate stackdriver alerting, create
    service accounts, access the Security Command Center, etc.  This means that most projects will
    be unable to deploy without having to get them to run commands on the Project Owner's behalf.

    Seems like it would be better to set up good auditing/logging of access control events and let
    the Project Owner set up the environment and manage their users.  Or at least to let them bootstrap
    the environment and get everything set up, and then lower their access once things are going.

    We hope that these requirements will be relaxed down the road as everybody gets more experience
    with the platform.  In the meantime, we have written some scripts for the ICE people to run to
    enable access in the `gcp-appengine-template/gcp_setup` directory.
  * Networking is not very customizable in App Engine:
    * Limiting outbound access seems pretty close to impossible with App Engine.  The firewall that
      App Engine does only operates on inbound traffic.  I have hopes that we can set up some sort of
      anomaly detection thing that kills apps if they query outside of the project, but the best
      thing to do would be to ask the GCP people what they expect people to do.
    * Limiting access from the outside world to services protected by the oauth2_proxy seems to be
      hard.  Inbound filtering seems to not be selective enough to apply to a service.
      So app implementers need to check for a properly signed GAP-Authentication header.  This seems
      like an easy thing to forget to do, or do improperly, so it would be good to talk with GCP
      to try to understand if they have better networking controls coming.
  * Logs are retained with this schedule:
    * Admin Activity audit logs 400 days
    * Data Access audit logs  30 days
    * System Event audit logs 400 days
    * Access Transparency logs  400 days
    * Logs other than audit logs or Access Transparency logs  30 days
    We may need to set up a storage bucket for log archival and automate that process,
    if this retention is not enough.

gha_language: Ruby


text:
# HAPI Starter:  Simple HapiJS Starter Seed

HAPI Version: 17.x

![dependencies](https://david-dm.org/n2geoff/hapi-starter.svg)

A simple HapiJS project quick-starter with API centric focused features

## Features

- Automated Swagger/OpenAPI Documentation via `hapi-swagger`
- Tests using `lab` & `code`
- Plugins to provide debugging functionality, such as
    - `blipp`: display the routes table at startup
    - `good/good-console`: process monitoring
- Additional plugins
    - `inert`: static file and directory handler
    - `joi`: object schema validation
    - `vision`: template rendering (used by `hapi-swagger`)

# Getting Started

## Installation

clone the repository with

	`git clone https://gogs.randomremains.com/geoff/hapi-starter.git`

navigate to installation directory via terminal (cmd)

	cd ~/hapi-starter

install dependencies via

	`npm update`

start the app via

	`npm start`

visit your API running at `http://<IP_ADDRESS>:8000/` in [POSTMAN](https://www.getpostman.com/) or tool of choice

> NOTE: hosted self-signed certs may require `git config http.sslVerify=false`

## Usage

For **illustration purposes only**, this code base comes with a `routes/tasks.js` file designed to test an in-memory RESTful `/tasks` resource.  This is the quickest way to identify benefits this simple setup provides, such as

- Generated Open API documentation: http://<IP_ADDRESS>:8000/documention
- See how validations work (try not including a task or adding additional keys)
- See how testing works `npm test` see `test/tasks.test.js`

### Endpoints

|Method |Endpoint| Description|
|---|---|---|
| GET | /tasks | returns all tasks |
| GET | /tasks/{id} | return task by index |
| GET | /tasks/count | returns the number of tasks |
| GET | /tasks/completed | returns the completed tasks |
| GET | tasks/active | returns the active tasks |
| POST | /tasks | creates a new task |
| PUT | /tasks/{id} | replaces a task by index |
| DELETE | /tasks/{id} | removes a task by index |

### Example

Request
```
POST /tasks
{
	task: "This is my Task",
	completed: false
}
```

Response
```
[
  {
    "task": "This is my Task",
	"completed": false
  }
]
```

# License

[MIT](LICENSE)

# Todo
- add more tests
- replace config/plugins.js with `glue`
- move core folders into `src` directory
- look at `wurst` for loading routes from a directory
- add a security foundation

# Resources

- [HAPI Homepage](http://hapijs.com/)
- [HAPI Plugins](http://hapijs.com/plugins)


text:
# API Automation Using Apache HTTP Client

[![MIT License](https://img.shields.io/apm/l/atomic-design-ui.svg?)](https://github.com/tterb/atomic-design-ui/blob/master/LICENSEs)

This Maven Project contains example code for learning API Automation Testing using TestNG + Java with Apache HTTP Client Library.

**The code for GET & POST Call is as follows :-**

- ***HTTP GET Call*** ---------->> *[Link](https://github.com/akshat-raj09/API_Automation_Using_Apache_HTTP_Client/blob/master/ApiAutomationUsingHttpClient/src/test/java/com/qa/testcases/GetApiTest.java)*
- ***HTTP POST Call*** ---------->> *[Link](https://github.com/akshat-raj09/API_Automation_Using_Apache_HTTP_Client/blob/master/ApiAutomationUsingHttpClient/src/test/java/com/qa/testcases/PostApiTest.java)*

## Run Locally

- Clone the project

```bash
  git clone https://github.com/akshat-raj09/API_Automation_Using_Apache_HTTP_Client
```

- Go to the project directory

```bash
  cd API_Automation_Using_Apache_HTTP_Client
```

- Open Eclipse/IntelliJ IDE. Import the project into Eclipse/IntelliJ IDE & search for [testng.xml](https://github.com/akshat-raj09/API_Automation_Using_Apache_HTTP_Client/blob/master/ApiAutomationUsingHttpClient/src/main/resources/testng.xml).

- Right Click on [testng.xml](https://github.com/akshat-raj09/API_Automation_Using_Apache_HTTP_Client/blob/master/ApiAutomationUsingHttpClient/src/main/resources/testng.xml) ------> Run As ------> TestNG

## Contributing

Contributions are always welcome!

Please adhere to this project's `code of conduct`.

## Authors

- [@Akshat](https://www.github.com/akshat-raj09)

# Hi, I'm Akshat! 👋

## 🚀 About Me
I'm a QA Engineer & interested in building automation frameworks & learning new tools related to automation............

## 🔗 Links
[![linkedin](https://img.shields.io/badge/linkedin-0A66C2?style=for-the-badge&logo=linkedin&logoColor=white)](https://www.linkedin.com/in/akshat009)

## 🛠 Skills
Java, Selenium, TestNG, SQL, Git, Maven, Apache POI, TDD, Jenkins, JIRA, Docker, Jmeter, Postman, RestAssured, SonarQube, Linux, SiKuli, TagUI, Robot Framework...........

## Feedback
If you have any feedback, please reach out to me at<EMAIL_ADDRESS>


text:
Slow, but steady: Demographic change and Catalan independence
================

Alternative title: 60% in 2039

# Introduction

Do you know any Catalans who do not have an opinion on the matter of
independence? Me neither. Virtually everyone has made up their mind on
it. There are two groups: those for, and those against. As is the case
with other divisive issues (gay marriage in the 1990s, for example), the
third “undecided” group is a tiny minority.

When it comes to divisive issues, people rarely change their mind. The
convinced are no longer convincible. Opinions become fossilized, and the
advocates of an opinion interpret new information in a way that supports
their already held convictions (ie, confirmation bias). [Research
shows](https://www.newyorker.com/magazine/2017/02/27/why-facts-dont-change-our-minds)
that *people irrationally cling to their beliefs, once they decide
something*. In fact, there is [some
evidence](https://pediatrics.aappublications.org/content/133/4/e835?sso=1&sso_redirect_count=1&nfstatus=401&nftoken=00000000-0000-0000-0000-000000000000&nfstatusdescription=ERROR%3a+No+local+token)
to suggest that presenting people with information which contradicts
their opinions actually causes them to believe *even more firmly* in
those opinions.

Let’s assume then, for the foreseeable future, that Catalans will not
change their minds on the question of independance. The half in favor
will remain in favor; the half opposed will remain opposed. What do you
think will happen?

If you guessed “infinite gridlock”, you’re likely wrong. Even if no
attitudes change, social majorities *will* change. How? 3 reasons:

1.  People die.
2.  People move.
3.  People are born.

In other words, as politicians yell at each other trying
(unsuccessfully) to convince the opposing side to adopt their viewpoint,
a process much more powerful than politics is taking place in the
background: demography. *Minds* changing is not the driver of many
radical social changes; rather it is *populations* changing. To return
to our previous example of gay marriage, the reason it has been
legalized in so many western countries in recent years is *not* because
those who staunchly opposed it changed their minds; rather, it is
because those who staunchly opposed it got old and died. The same
phenomenon largely explains other social changes, such as the rise in
feminism and environmentalism, or the declines in racism and
anti-semitism. At the individual-level, very few people change their
mind on these issues. But at the collective level, societies change when
the young come to age and the old pass on.

Those interested in the future of Catalonia should take into account
demography. Birth rates and migration have changed radically in recent
decades, and the effects of these changes will linger for generations.
There is no way to be certain about the future - unknown future economic
and social forces will impact mortality, migration, and fertility - but
we can use the information available now to predict the future.

This article aims to do just that: quantify the effect that demographic
changes in Catalonia will have on support for Catalan independence.

# Background: which demographic factors affect support for independence

The reason that demographic change will bring about social change in
Catalonia is because demographic characteristics are closely associated
with support for independence. Two factors are especially relevant: age,
and place of birth.

The below chart shows the association between place of birth and support
for independence. Catalans in born in Catalonia are largely in favor of
independence. Catalans born elsewhere are largely opposed to it.

![](figures/unnamed-chunk-2-1.png)<!-- -->

And the below shows the association between age and support for
independence. Young Catalans are largely in favor of independence,
whereas older Catalans are largely opposed.

![](figures/unnamed-chunk-3-1.png)<!-- -->

Let’s dive into the details.

# Describing the present

There is an important demographic trend taking place right now in
Catalonia: the percentage of Catalans who were born in Spain is
decreasing. One can only speculate whether this trend played a role in
the rapid increase in support for independence in recent years, but the
data are clear - over the last 20 years, the percentage of Catalans born
in Spain decreased from 27.2% to 16.6%.

![](figures/unnamed-chunk-5-1.png)<!-- -->

Why has the percentage of Catalans born in Spain decreased? It’s not
because they are leaving Catalonia to return to Spain. Rather it’s
because the Spanish-born population of Catalonia is far older than the
average population of Catalonia. The below chart shows the distribution
of the age of Catalans by place of birth:

![](figures/unnamed-chunk-6-1.png)<!-- -->

Note in the chart above how in the right-most planel, data are clumped
higher, whereas in the left-most and central panel, data are distributed
lower. Most Catalans who were born in Spain are old: whereas the median
age of Catalans born in Catalonia is 38 and the median age of Catalans
born in the rest of the world (not counting Spain) is 37, the median age
of Catalans born in Spain is 64. Three-quarters of Catalans born in
Spain are 55 or older.

In other words, the decrease in the percentage of Catalans who were born
in Spain is due largely to mortality, not emigration.

Why does this all matter? Because the old, here and everywhere, will
continue to die before the young. And unless the migration patterns of
the future are identical to the migration patterns of the past (which
they almost certainly willl not be), these deaths will leave a mark on
collective political preferences.

# Predicting the future

With its current demographic make-up, Catalonia is split approximately
50-50 on the question of independence. Let’s see what is likely to
happen in a few years.

The below shows what will happen to Catalonia’s *current* population
over time. Since most Catalans who were born in Spain are older, their
share (as a percentage of the total Catalan population) will decrease
over time.

![](figures/unnamed-chunk-8-1.gif)<!-- -->

If we examine only mortality (ignoring, for the moment, migration and
fertility), Catalonia’s population by place of birth would look like
this over the next few decades.

![](figures/unnamed-chunk-9-1.png)<!-- -->

Note the difference in the grey (abroad) and green (Spain) lines. Though
the percentage of Catalans who are born in Spain vs. born in the rest of
the world are similar now (approximately 17-18%), they will diverge
sharply in the near future. The reason why is because foreign-born
Catalans are relatively young compared to Spanish-born Catalans.

The result of these differences in ages is this: even if nobody changes
their mind, the percentage of Catalans in favor of independence will
increase steadily over the next few decades. Because so many
anti-independence Catalans are elderly, support for continued union with
Spain will decrease steadily as the elderly pass away. The below shows
the estimated percentage of Catalans in favor and opposed to
independence, assuming (a) opinions don’t change and (b) only mortality
(not migration and fertility) affect the population structure.

![](figures/unnamed-chunk-10-1.png)<!-- -->

Is it reasonable to assume that there will be no new births and no new
migration to or from Catalonia in the future? Of course not. Just as
people (sadly) cease to exist, so too can they be created. Birth is one
way. The other way (at least for our purposes) is migration.

Even though it is impossible to predict the future of migration and
births, it is wrong to ignore them. So, for this exercise, we’ll simply
make some assumptions: that the number of annual births in Catalonia
will remain the same as now (or rather, 2017, the most recent year for
which data is available), and that the number of migrations (both to and
from Spain and the rest of the world) will remain constant as well
(using the average from the period of 2005 to 2017)

With these assumptions made, Catalonia’s population looks like this over
the next few years:

![](figures/unnamed-chunk-11-1.gif)<!-- -->

What effect will this have on support for independence? The below shows
estimated support for independence, assuming no changes in opinions,
future migration rates identical to those of the last 10 years, and
future birth rates identical to that of 2017. The effects of demographic
change will be seen, even in the short-term:

![](figures/unnamed-chunk-12-1.png)<!-- -->

In other words, even if ZERO people change their minds, the 50-50 split
will not continue.

Still, there’s one more adjustment we need to make. The above plot shows
the likely outcome of a yes/no independence referendum, assuming that
*all* Catalan adults were permitted to vote. As ideal as this might be
from a democratic perspective, it’s unlikely to be the case.
Specifically, most Catalans who were born abroad are *not* citizens of
Spain (there are many exceptions, of course), and assuming that a future
referendum were held in accordance with Spanish legislation, they would
not be permitted to cast a vote.

So, for our final chart, let’s see what would happen in a hypothetical
referendum taking into account only those who are likely to be able to
vote (those born in Spain/Catalonia). The result is below.

![](figures/unnamed-chunk-13-1.png)<!-- -->

What does the above show? That the forces of demography alone will
result in support for independence reaching 60% in 2039, even if nobody
changes their opinion on the matter.

# Conclusion

Time is working against those who oppose Catalan independence. Catalans
who were born in Spain - a bastion of support for the Spanish unionist
movement - are largely elderly and are being replaced by younger
Catalans born in Catalonia (largely in favor of independence) and
younger Catalans born abroad (who, for the most part, cannot vote).
Regardless of your opinion on independence, these are the facts.

I argue in this article that minds rarely change, and I believe firmly
that this is the case for most political issues. It is for this reason
that demographic change is important to understanding Catalonia’s
future. With fossilized opinions on both sides, it is unlikely that
there will be any major “conversions” in near-term.

That said, unlikely does not mean impossible. Minds *do* ocasionally
change on some issues. Perhaps a Spanish Government will propose a
political settlement which is acceptable to a majority of Catalans (so
far this hasn’t happened). Perhaps Catalans will grow tired of seeking
independence, and will settle for some modified version of their current
autonomy. Or perhaps some freak event will change the entire
conversation.

But barring the above, the most likely course of events is this: the
Catalan independence movement will continue to grow in numbers, and a
Spanish Government (perhaps not the current one, since its official
position on Catalan self-determination is “no is no, never is never”)
will be forced to recognize the political reality and work for a
political solution. A solution almost certainly involves a referendum on
independence and - unless minds radically change in the coming years -
this referendum will be won by the pro-independence camp.

## Technical note

This article contains many projections, which - like all projections -
are almost certainly inaccurate. Though actuarial science is fairly
accurate (life expectancies, etc.), forecasting migration and fertility
is largely a guess. For the purposes of transparency, all code and data
used for this article is publicly available online at
<https://github.com/joebrew/vilaweb/tree/master/analyses/demography>.

# Catalan-language plots

![](figures/unnamed-chunk-14-1.png)<!-- -->

![](figures/unnamed-chunk-15-1.png)<!-- -->

![](figures/unnamed-chunk-17-1.png)<!-- -->

![](figures/unnamed-chunk-18-1.png)<!-- -->

![](figures/unnamed-chunk-19-1.gif)<!-- -->

![](figures/unnamed-chunk-20-1.png)<!-- -->

![](figures/unnamed-chunk-21-1.png)<!-- -->

![](figures/unnamed-chunk-22-1.gif)<!-- -->

![](figures/unnamed-chunk-23-1.png)<!-- -->

![](figures/unnamed-chunk-24-1.png)<!-- -->

repository: joebrew/vilaweb

gha_language: HTML

gha_license_id: NOASSERTION

repo_name: joebrew/vilaweb


text:
---
layout: post
category : tech
title: "Yes, the doc-type is still important"
tags : [html,css,how I got burned today,programming]
---
{% include JB/setup %}

or... "why don't my before/after pseudo elements work in IE8?". It may be 2014, but doc types still matter.

<!--more-->

If you have been a web developer longer than 3 minutes, you may remember the HTML doc type tag at the top of all your HTML markup. You probably just set it to <!DOCTYPE html> - and moved on with your life. That's usually fine, but not always.

## How I got burned today
For the last couple fo weeks, I've been rectifying some HTML written under Dot Net **1.0** (Yes, you did read that correctly). This code gets used by thousands of people every day. It is mostly reliable, but it is not accessible, and due to a change in government policy - my team needs to make it accessible (WCAG2 AA compliant).

Have you seen the movie Inception? This app is like thats that, but with never ending levels of nested tables. One of my co-workers replaced most of the tables with DIVs, but jury is out on whether that made things better or worse.

While bringing the CSS to modern standards, I used the CSS "before" attribute, as follows:

The style was quite simple:

```
.spiffy-form input.required-field:before {
    content: "*";
    font-weight: bold;
}
```

In Firefox, I had a nice star displayed.

Strangely, IE8 had no star.

IE8 *does* support the **:before** and **:after** pseudo-elements, what was going on?

It turns out that IE8 doesn't support **:before** and **:after** if it's rendering engine is in quirks mode.

## Feeling Quirky

In the dark days of the web IE and Netscape Navigator rendered things a little differently to each other. Each browser had a partial implementation of the HTML (and later, CSS) specification - as well as custom extensions to it. This continued well into the time Netscape died and FireFox emerged.

The IE team had to move closer to standards compliance, but couldn't risk breaking thousands (millions?) of sites to do so. The solution from the IE team (and later, other browsers) - was to implement "Quirks mode". For IE, this means loading an earlier version of the rendering engine - one that has a bad/old/loose HTML compliance. You essentially get IE 5.5 with support for a few later features jammed in.

## Moving Forward

If it is a new(ish) site/app, go for the HTML5 doctype:

```
<!DOCTYPE html>
```

If you are updating some godawful mess from 2003, you are going to want the HTML4 doctype with loose standards compliance:

```
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
```

If you want to stick with HTML4, but you care about accessibility, this doctype will let you use ARIA attributes:

```
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML+ARIA 1.0//EN" "http://www.w3.org/WAI/ARIA/schemata/html4-aria-1.dtd">
```

Apply any of those doc types, and your before/after pseudo elements will start working. You will also have a more maintainable site and more consistent rendering.

Happy coding!

## Further Reading

[This great site](https://hsivonen.fi/doctype/) goes into various DocTypes and their effects in a good level of detail.


text:
---
date: "2020-04-30"
title: "Chicken Mushroom Pirozhki"
tags: ["chicken mushroom pirozhki", "pirozhki", "chicken", "mushroom", "chicken pirozhki", "heirloom", "appetizers", "russian food", "russian", "buns"]
featuredImage: ./chicken_mushroom_pirozhki_1x1.jpg
recipeImage: ./chicken_mushroom_pirozhki_3x4.jpg
description: "Meat-filled puff pastry buns, a take on the popular street food of Eastern Europe."
servingSize: "32 buns"
totalTime: "1 hour"
ingredients:
  - 1 whole rotisserie chicken
  - 1 large brown onion, diced
  - 8 oz. mushrooms, sliced
  - 8 squares (5”x5”) puff pastry dough (or about 18 oz.)
  - 1 egg
  - Sea salt, to taste
  - Ground black pepper, to taste
instructions:
  - Separate the meat from the bones of the rotisserie chicken. It is important to use both the white and dark meat, especially because the dark meat adds moisture so that the filling doesn’t turn out too dry. Place the chicken in a large bowl and set aside.
  - Sauté the mushroom and onion in a skillet until browned and starts to give off excess moisture. Add the mushroom and onion mixture to the bowl with the chicken.
  - To make the filling, grind the meat and mushroom mixture together using a meat grinder. Add salt and pepper to taste.
  - Preheat the oven to 350 degrees. Cut each individual puff pastry sheet into 4 squares. Do not use a roller on the dough as it could flatten the layers and the dough could turn out less flaky.
  - Place about a teaspoon of filling into each square of dough. Use flour if necessary to prevent stickiness.
  - Pinch together opposite corners of the dough and continue along the edges to close the pastry.
  - Place on a baking tray and beat an egg. With a pastry brush, spread some egg wash over the pastries so that they get a nice color and shine when they bake.
  - Bake the pastries for about 30 minutes or until they develop a crunch and a rich golden color.
  - Let cool slightly and serve! They can be stored in the fridge for about a week and half, but you might eat them all before then!
---
These are perhaps my favorite food of all time -- I loved making and eating them as a child and I still do! Pirozhki (or пирожки) are quite stereotypical of Russian culture and are traditionally boat-shaped buns with different fillings. Another popular filling is with cabbage or beef, but I have always loved the chicken filling the most.

This recipe is my grandma’s and we’ve been making these pirozhki for years. Traditionally, pirozhki are made with a more chewy yeast-based dough, but I especially love the flaky puff pastry dough we use. They’re crunchy and are packed with flavors of home.

We also make them relatively small -- snack size! I think they’re super cute. I can eat like 10 of them at once and still want more. Pirozhki are normally made a bit larger.

But if you want to make these larger, you could probably use an entire puff pastry square for one pirozhok (singular for pirozhki!) instead of cutting it into four squares like we do. We’ve never made them this way and you would probably have to cook them for longer, but give it a try!

Another essential thing for this recipe is owning a meat grinder. It’s pretty hard to make Russian dishes without one anyway. In this case, we grind cooked chicken and mushrooms together to make the filling. It’s maybe possible to accomplish this without a meat grinder, but you’d have to get creative (chop really small? mash everything together?).

If you have a meat grinder attachment to your stand mixer, that is perfect. Whichever way you do it, make sure that you’re filling your pirozhki with COOKED meat. They will not do well if you fill them with raw meat and expect it to cook through in the oven and taste the same. Plus they might come out wet from the raw meat emitting moisture.

As a side note, I love eating these cold the second day but I’m kind of weird, so your best bet is probably to warm them up in the toaster to reheat, since the microwave will make them soft and soggy. I don’t need to tell you that the best time to eat them is fresh, right out of the oven though.

We hope you enjoy making and eating these as much as we do! :)

gha_language: JavaScript


text:
import React from 'react'
import {ReactMarkdown} from '../../../components/Markdown.js'

export default ({url, Page, Endpoint, Resource}) =>
   <Endpoint
      hidden={true}
      url={url}
      group="user"
      method="post"
      path="/user/register">

      <Endpoint.Return code="201">A <Resource.Link resource="user">User object</Resource.Link></Endpoint.Return>
      <Endpoint.Return code="400">A generic <Resource.Link resource="error/generic">error object</Resource.Link> when invalid data was given</Endpoint.Return>
      <Endpoint.Return code="401">A <Resource.Link resource="error/no-auth">Error object</Resource.Link></Endpoint.Return>
      <Endpoint.Return code="403">
         Fails with a <Resource.Link resource="error/auth">Error object</Resource.Link> due to failed authentication, or user already exists.
      </Endpoint.Return>

         This endpoint was never part of the official specification for either version 1 or 2 of the
         Tinymesh API. It's due for removal at any time. DO NOT USE.

         Creates a new user from data given. Excpects request data to contain a object with atleast two fields:
         email and password. If the user already exists 403
         Forbidden will be returned. Otherwise a 201 Created.

   </Endpoint>

repository: tinymesh/tm-docs

repo_name: tinymesh/tm-docs


text:
# aeilos -- an online multi player minesweeper!
Try it here: https://changgeng.me/aeilos

## Tasks

- Feature
  - Punishment of minus-zero
  - DIY flag
  - Own an area
  - MiniMap
- Frontend
  - Frontend redesign
    - LeaderBoard css style
    - hide chatbox by animation
  - area size
  - Adjust onWheel
  - Cache areas
- Backend
  - Refine updateZeros() // because it might be slow
  - Record user current area and Stop global broadcasting
- Done
  - Left+right click
  - Persist & load data
  - User register/login
  - Score board
  - Chatbox: send and receive, get history messages
  - Ranking: get my ranking, leaderboard
  - Save Login status & Logout

## How to Build

### Build protobuf

First install protobuf compiler from google. Then generate the grpc source code.

```sh
cd pb; ./generate.sh;
```

### Build frontend

```sh
cd frontend; ./deploy.sh;
```

### Build backend

```sh
# under root directory of this project
go build
# start the service
./aeilos
```

repository: zcgeng/aeilos

repo_name: zcgeng/aeilos


text:
[![License](https://img.shields.io/badge/license-Apache--2.0-brightgreen.svg)](LICENSE)
[![Master Build Status](https://travis-ci.org/hhandoko/cassandra-migration.svg?branch=master)](https://travis-ci.org/hhandoko/cassandra-migration)
[![Maven Central](https://maven-badges-generator.herokuapp.com/maven-central/com.hhandoko/cassandra-migration/badge.svg?style=flat)](https://maven-badges-generator.herokuapp.com/maven-central/com.hhandoko/cassandra-migration)
[![Downloads](https://img.shields.io/badge/downloads-jar-brightgreen.svg)](https://github.com/hhandoko/cassandra-migration/releases/download/cassandra-migration-0.17/cassandra-migration-0.17.jar)
[![Downloads](https://img.shields.io/badge/downloads-jar--with--dependencies-brightgreen.svg)](https://github.com/hhandoko/cassandra-migration/releases/download/cassandra-migration-0.17/cassandra-migration-0.17-jar-with-dependencies.jar)

# Cassandra Migration

`cassandra-migration` is a simple and lightweight Apache Cassandra database schema migration tool.

It is a Kotlin fork of [Contrast Security's Cassandra Migration] project, which has been manually re-based to closely follow [Axel Fontaine / BoxFuse Flyway] project.

It is designed to work similar to Flyway, supporting plain CQL and Java-based migrations. Both CQL execution and Java migration interface uses [DataStax's Cassandra Java driver].

### Limitations

**The tool does not roll back the database upon migration failure.** You're expected to manually restore from backup.

## Resources

* [Project Overview](https://github.com/hhandoko/cassandra-migration/wiki)
* [Releases](https://github.com/hhandoko/cassandra-migration/releases)
* [Getting Started](https://github.com/hhandoko/cassandra-migration/wiki/Getting-Started)
* [Migrations](https://github.com/hhandoko/cassandra-migration/wiki/Migrations)
  * [Configuration / Options](https://github.com/hhandoko/cassandra-migration/wiki/Configuration-Options)
  * [CQL and Java migrations](https://github.com/hhandoko/cassandra-migration/wiki/Script-Types)
  * [Standalone migration](https://github.com/hhandoko/cassandra-migration/wiki/Standalone-Migration)
  * [Library API migration](https://github.com/hhandoko/cassandra-migration/wiki/API-Migration)

Refer to the [Project Wiki] for the full documentation.

## Contributing

We follow the "[fork-and-pull]" Git workflow.

1. Fork the repo on GitHub
1. Commit changes to a branch in your fork (use `snake_case` convention):
   * For technical chores, use `chore/` prefix followed by the short description, e.g. `chore/do_this_chore`
   * For new features, use `feature/` prefix followed by the feature name, e.g. `feature/feature_name`
   * For bug fixes, use `bug/` prefix followed by the short description, e.g. `bug/fix_this_bug`
1. Ensure relevant test(s) are added: for bugs, or if existing behaviour are changed or updated
1. Rebase or merge from "upstream"
1. Submit a PR "upstream" with your changes

Please read [CONTRIBUTING] for more details.

## License

```
  Copyright (c) 2016 - 2018 cassandra-migration Contributors

  Licensed under the Apache License, Version 2.0 (the "License");
  you may not use this file except in compliance with the License.
  You may obtain a copy of the License at

             http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
```

`cassandra-migration` project is released under the Apache 2 license. See the [LICENSE] file for further details.

[Contrast Security's Cassandra Migration] project is released under the Apache 2 license. See [Contrast Security Cassandra Migration project license page] for further details.

[Flyway] project is released under the Apache 2 license. See [Flyway's project license page] for further details.

[Axel Fontaine / BoxFuse Flyway]: https://github.com/flyway/flyway
[Contrast Security's Cassandra Migration]: https://github.com/Contrast-Security-OSS/cassandra-migration
[Contrast Security Cassandra Migration project license page]: https://github.com/Contrast-Security-OSS/cassandra-migration/blob/master/LICENSE
[CONTRIBUTING]: CONTRIBUTING.md
[DataStax's Cassandra Java driver]: http://datastax.github.io/java-driver/
[Flyway]: https://flywaydb.org/
[Flyway's project license page]: https://github.com/flyway/flyway/blob/master/LICENSE
[fork-and-pull]: https://help.github.com/articles/using-pull-requests
[LICENSE]: LICENSE
[Project Wiki]: https://github.com/hhandoko/cassandra-migration/wiki

repository: pollend/cassandra-migration

repo_name: pollend/cassandra-migration


text:
# Module 7: Data Visualization

## Advanced Task

### How to start the project

These four files (two .js, a .css and a .html file) must been placed in the same directory. To visualize the resulting chart, open the index2.html file with any web browser.

### Purpose of this task

This task consists in designing any chart with some kind of interaction through the mouse (for example by clicking over the graph).

### Description of the project

The idea of this project is to elaborate a dot chart which displays the population of the city of Malaga along the years.
Passing the mouse arrow over each dot the users can see the pair of values (Year, Population), and the size of the dots will increase by four, and their color will change from black to green.
As well, by clicking on a specific dot an alert will appear showing the year and population of that dot).
The source of data is the [web of the Málaga's provincial goverment] (http://www.malaga.es/gobiernoabierto/datosabiertos/catalogodatos/com1_md1_cd-198081/cnl-594/padron-habitantes) in JSON format. This file contains information about every towns in the province, such as location, code, region where the town belongs and the evolution of the demography.

#### Step 1: collecting and modifying data

Once downloaded the JSON described before, I take only the data corresponding to Malaga city, removing the rest of information (I just select the pair Year, Population, discarding any other type of data).

In this way, the file data2 of my project will be composed of 16 dictionaries, where the keys are *Year* and *Population*.

#### Step 2: Elaborating the chart

##### Step 2.1: Files we need
The project is composed of 4 files related each other:
- index2, in html format: it will be visualized in a web browser.
- data2, in js: containing data in dictionaries as commented before, saved in a variable *malaga*.
- main2, in js: containing the code in javascript of the column chart.
- styles2, in css: containing the necessary formats for the chart (letter font, width of the xis lines,colors...)

Now we are going to focus on the last file, main2.js and its code.

##### Step 2.2: Designing the context of the chart (Canvas and axis)

- First we declare the necessary variables for the code,for example the margins or the dimensions (width and height of the window) and configurate them.

- Then we design the scale for both axes, keeping in mind that that the axis x will represent the years and the axis y will represent the value of population.

    - Axis X: domain from 1997 to the max year according to the data we have and with respect to the range, the maximum allowed by the window, discounting the margins.
    - Axis Y: domain from 528000 to the max value of population and the highest possible range discounting margins, similarly to axis x.

- After designing the scale I translate and orient the axis to their corresponding place, without giving to the axis labels any special format.

- To finish with the axes, I append them as a group into the window and at the same time
I insert the label for each axis (Year and Population), translating and rotating them.

##### Step 2.3: Creating the dots and interaction

To insert the dots, I first create the features of the circles which are going to compose the dots. The coordinates of the center of each circle will coincide with the values (Year, Population) and the radius (8).

Then, the data will be represented by appended circles with the previous defined attributes, and they will have two additional attributes: MouseOver and MouseOut, for the interaction with the mouse arrow.
To add the other type of interactivity (click on the dots to show the values of them in an alert) I include the command .on("click").

Therefore, the MouseOver function is composed of a function that selects the dot which the arrow is aiming and filling it green and increasing it four times its original size.

Besides the selected dots must show the text with the pair (Year, Population), so first I create an id to the text (this will allow me to remove it after easily) and the I append it.

The MouseOut function returns the selected dot to its original configuration (black and radius 8, without text).

#### Step 3: Results

Image showing the resulting dot chart:
![Dot char 1](https://github.com/JavierFJ/Module_7/blob/master/Advanced_task/image1.png?raw=true)

Image showing the interaction by passing the mouse arrow over a dot and by clicking on it:
![Dot char 2](https://github.com/JavierFJ/Module_7/blob/master/Advanced_task/image2.png?raw=true)


text:
![Logo of the project](https://github.com/gopher-lang/gopher/blob/master/doc/gopher/gophercolor.png)

# Code Challenge: HTTP key/value store (take-home exercise)
## Requirements
HTTP endpoints:

PUT /<key>  — Set the value of a key

GET /<key>  — Fetch the value of a key

DELETE /<key> — Delete a key

The server's database state is persisted to the file system (without relying in an external process, or using an existing key-value store library).

Restarting the server should not lose writes that have already been acknowledged with a 2XX response status code.

## Features

The server is listening on Port 5000.

to test the server, you can try out some of the example curl commands

Example:
1. Write a value to the key ```foo```:
```bash
$ curl -i -X PUT 'http://localhost:5000/foo' -H 'Content-Type: application/octet-stream' --data-binary 'hello world!'
HTTP/1.1 204 No Content
```

2. Fetch the value of ```foo```:
```bash
$ curl -i 'http://localhost:5000/foo'
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Length: 12

hello world!
```

3. Fetch the value of ```qux```(which does not exist):
```bash
$ curl -i -X PUT 'http://localhost:5000/foo' -H 'Content-Type: application/octet-stream' --data-binary 'hello world!'
HTTP/1.1 204 No Content
```

4. Delete the key ```foo```:
```bash
curl -i -X DELETE 'http://localhost:3000/foo'
HTTP/1.1 204 No Content
```
## Licensing

"The code in this project is licensed under MIT license."

repository: threedee/nv-key-value-store

repo_name: threedee/nv-key-value-store


text:
## Data resources

### Building images

The images.js file builds all image constant data.
```bash
node images.js
```

### Building assets

The template.js file builds all assets.
```bash
node template.js
```

### Packing the web version

The pack.js file builds and packs the web version.
This file needs the terser and uglifycss npm packages to run.

```bash
node pack.js
```

repository: ArnoVanDerVegt/wheel

repo_name: ArnoVanDerVegt/wheel


text:
# swift-log-papertrail

![Swift](https://img.shields.io/badge/Swift-5.2-orange.svg)

This package implements a handler for [swift-log](https://github.com/apple/swift-log) which will send log messages to the [Papertrail's](https://www.papertrail.com) Log Management service.

## Usage

###  Add Package
Integrate the `PapertrailLogHandler` package as a dependency with Swift Package Manager. Add the following to `Package.swift`:

```swift
.package(url: "https://github.com/e-sites/swift-log-papertrail.git", from: "1.0.0")
```

Add `PapertrailLogHandler` to your target dependencies:

```swift
.product(name: "PapertrailLogHandler", package: "swift-log-papertrail")
```

### Configure

Configure the logger by bootstrapping a `PapertrailLogHandler` instance.

```swift
import PapertrailLogHandler
import Logging

LoggingSystem.bootstrap { label in
	return PapertrailLogHandler(label: label,
	                            host: "logs9.papertrailapp.com",
	                            port: 1234,
	                            programName: UUID().uuidString)

	// Or use `MultiplexLogHandler` to use multiple LogHandlers
}
```

### Logging

To send logs to Papertrail, initialize a `Logger` instance and send a message with optional additional metadata:

```swift
import Loggingx

let logger = Logger(label: "com.swift-log.awesome-app")
logger.error("unfortunate error", metadata: ["request-id": "abc-123"])
```

repository: e-sites/swift-log-papertrail

repo_name: e-sites/swift-log-papertrail


text:
# Accessing optional JSON elements

If there is no prior knowledge of the availability of a particular field, optional field access (`?.`) can be used on the `json` value. If the particular field is not available, it will return `nil`.

::: code access_optional_json_elements.bal :::

Run the example as follows.

::: out access_optional_json_elements.out :::

## Related links
- [JSON type](/learn/by-example/json-type/)
- [Check expression](/learn/by-example/check-expression/)
- [Optional fields](/learn/by-example/optional-fields/)

gha_language: Java


text:
# gnomAD Browser Deployment

## Build image

To build a Docker image containing the app server and its dependencies:

```shell
cd gnomadjs/projects/gnomad
./deploy/build-image.sh
```

This will create an image named "gnomad-browser-beta" tagged with the hash of the current git revision.

## Deploy image to Kubernetes

After an image has been built, deploy it to Kubernetes with:

```shell
cd gnomadjs/projects/gnomad
./deploy/deploy-image.sh tag environment
```

where `tag` is the tag on the "gnomad-browser-beta" image to be deployed and `environment` is the
environment to deploy to ("p" for production or "d" for development).

## Run image locally

To run the browser locally from the Docker image:

```shell
docker run --rm -ti --init -p 8000:80 gcr.io/exac-gnomad/gnomad-browser-beta
```

repository: zhouhufeng/gnomadjs

repo_name: zhouhufeng/gnomadjs


text:
---
title: First SandCastle CTP released
categories: .Net, IT Related
date: 2006-07-31 11:00:45 +10:00
---

I [posted][0] recently about SandCastle. The [first CTP][1] of SandCastle has been released and it also has a [blog][2].

On a sadder note, NDoc has [officially died][3] under very unfortunate circumstances.

[0]: /2006/07/14/assembly-loading-failure-logging/
[1]: http://blogs.msdn.com/sandcastle/archive/2006/07/29/682830.aspx
[2]: http://blogs.msdn.com/sandcastle/
[3]: http://www.charliedigital.com/PermaLink,guid,95b2ab68-ba92-413a-b758-2783cde5df9c.aspx

license: MIT,Unlicense

detected_licenses: MIT Unlicense

gha_language: SCSS


text:
# Splunk 8.2 Docker Image

## 1) Image description
The image is based on the official _splunk:8.2_ image.
In this image the disk usage by the Splunk Indexer is limited to 200 MB.

* Figure 1: Splunk web console - hosts
![Splunk web console - hosts](screenshots/splunk-screenshot-01.png)

* Figure 2: Splunk web console - incoming log entries
  ![Splunk web console - hosts](screenshots/splunk-screenshot-02.png)

## 2) Build
Build it using:
~~~
$ cd splunk-8.2
$ ./build.sh
~~~

## 3) Usage
* Start the Splunk server: `docker-compose up`
* Splunk web console URL: [http://localhost:8000](http://localhost:8000)
* WebLogic credentials: `admin`/`password`

## 4) License
Before the build, you must download the `Oracle JDK` install kit from the Oracle website and accept the license indicated on that page.

Copyright (c) 2021 Remal Software, Arnold Somogyi. All rights reserved.

BSD (2-clause) licensed


text:
---
layout: post
title:  "COVID-19 Food Drive"
date:   2020-04-09
excerpt: "Donate food and support the community!"
tag: [Food Drive]
comments: False
---
Hi everyone. In case you haven’t heard, we’re hosting a food drive from April 15th (Wednesday) to May 2nd (Saturday)!

Getting healthy food is one of the many worries of our Central Texas neighbors in normal times, and that’s without a pandemic! [This CNN article](https://www.cnn.com/2020/03/31/politics/food-banks-supplies-groceries-coronavirus/index.html) has some more specifics about why it is important to help out food drives during this global crisis.

You can help by donating food to our food drive, in which the food will be donated to the Central Texas Food Bank. If you don’t have food to donate, you can also [volunteer at the Central Texas Food Bank in a safe manner](https://www.centraltexasfoodbank.org/get-involved/volunteer), or [donate money directly to them](https://secure3.convio.net/cafbtx/site/Donation2;jsessionid=00000000.app30101a?18029.donation=form1&df_id=18029&mfc_pref=T&NONCE_TOKEN=0CBD2EB4FD8D0346990F0D14BCE8C1DF) (they’re a really great nonprofit).

# What items to drop off
We can only accept non-perishable food.
The most needed items, according to the Central Texas Food Bank, are:
* peanut butter
* canned chicken breast or tuna
* canned low sodium vegetables canned fruit in its own juice (no sugar added)
* dry pinto beans
* brown rice
* non-fat dry milk powder
* 100% whole grain cereal

All non-perishable items will be accepted though.

# Where to drop off items
You can drop off items at any of the locations below:
* 8108 Tierra Linda Ln
* 10502 floral park dr
* 12224 Tanglewild Drive
* 2108 Wright St.

See this map to find which location is closest to your house (the locations are the pins on the map):

On the porch of each house, there will be a box that you can drop off items in. You can drop off items anytime, during the dates of the food drive (**April 15th (Wednesday) to May 2nd (Saturday)**)

# Email updates/Feedback
If would like to recieve email updates on the food drive as it progresses, or have any commments you would like to share, please fill out this form.
Loading…

# Safety Instructions
As you should be doing at all times, avoid contact with other people when dropping off food (staying six feet away at least).

If you have any questions or comments, feel free to email us: us \[at\] bowlsofhope \[dot\]org. We'll respond as quick as possible. If you are in the process of handing off a donation and have trouble finding the donation box, or have any other emergency situation related to this food drive, please call<PHONE_NUMBER> for more immediate assistance.

Thanks for reading this important information document and we look forward to seeing your donation!

– Bowls of Hope (Sam Christian, Jasmine Gokingco, Pranav Bingi, Ishan Ladhani)


text:
# docschina-slugger

Generate a slug just like GitHub does for markdown headings. It also ensures slugs are unique in the same way GitHub does it. The overall goal of this package is to emulate the way GitHub handles generating markdown heading anchors as close as possible.

This project is not a Markdown or HTML parser: passing `alpha *bravo* charlie`
or `alpha <em>bravo</em> charlie` doesn’t work.
Instead pass the plain text value of the heading: `alpha bravo charlie`.

## Install

```bash
npm install docschina-slugger
```

## Usage

```js
const slugger = require('docschina-slugger')()

slugger.slug('foo')
// returns 'foo'

slugger.slug('foo')
// returns 'foo-1'

slugger.slug('bar')
// returns 'bar'

slugger.slug('foo')
// returns 'foo-2'

slugger.reset()

slugger.slug('foo')
// returns 'foo'
```

## License

[ISC](LICENSE)

license: ISC

repository: QC-L/docschina-slugger

repo_name: QC-L/docschina-slugger