text:
![sanky example](assets/image/finisch.gif)

This diagram shows the relationship between the music genre that people listen to and the movie genre they watch.
The lines of the sankey diagram show genre relationship with each other. The thickness indicates the amount.
At the bar chart are the names of the movie genre on the y axis. The x-axis indicates the amount (in percentage).

## Data src
The data was taken from here
Link to src: https://www.kaggle.com/miroslavsabo/young-people-survey
Download link: https://www.kaggle.com/miroslavsabo/young-people-survey/data

An example of the data

Music | Slow songs or fast songs | Dance | Folk | Country | Classical music
-- | -- | -- | -- | -- | --
5 | 3 | 2 | 1 | 2 | 2
4 | 4 | 2 | 1 | 1 | 1
5 | 5 | 2 | 2 | 3 | 4
5 | 3 | 2 | 1 | 1 | 1
5 | 3 | 4 | 3 | 2 | 4
5 | 3 | 2 | 3 | 2 | 3
5 | 5 | 5 | 3 | 1 | 2
5 | 3 | 3 | 2 | 1 | 2
5 | 3 | 3 | 1 | 1 | 2
5 | 3 | 2 | 5 | 2 | 2
5 | 3 | 3 | 2 | 1 | 2
5 | 3 | 1 | 1 | 1 | 4
5 | 3 | 1 | 2 | 1 | 4
5 | 3 | 5 | 3 | 2 | 1

1 = disagree disgaree 5 = totally agree

## Proces

The first thing I did was download the source file of the sanky plugin(https://github.com/d3/d3-sankey). From this source it will create this sanky.
![sanky example](assets/image/sanky-example.PNG)

To get the the graph working we need to format our dataset to a dataset that looks a little bit like this:
```
{
"nodes":[
{"node":0,"name":"node0"},
{"node":1,"name":"node1"},
{"node":2,"name":"node2"},
{"node":3,"name":"node3"},
{"node":4,"name":"node4"}
],
"links":[
{"source":0,"target":2,"value":2},
{"source":1,"target":2,"value":2},
{"source":1,"target":3,"value":2},
{"source":0,"target":4,"value":2},
{"source":2,"target":3,"value":2},
{"source":2,"target":4,"value":2},
{"source":3,"target":4,"value":4}
]}
```
The 'nodes' are the blocks.
And the links cooordinate which nodes needs to connect with each other.

### The sankey Graph
First of all I created an array that saved all the music genre that there is in the dataset;
From there I created a function that search for all the people that like specific genre.
The function looks like this:
```javascript
//All the music genre that are in the dataset
var allMusicGenre = ['Dance', 'Folk', 'Country', 'Classical music', 'Musical', 'Pop', 'Rock', 'Metal or Hardrock', 'Punk', 'Hiphop, Rap', 'Reggae, Ska', 'Swing,  Jazz', "Rock 'n Roll", 'Alternative', 'Latino', 'Techno, Trance', 'Opera'];

var nestData = [];

allMusicGenre.forEach(function(musicGenre) {
  let music = {};
  let total = 0;
  let like = 3;
  let allPosition = [];
  var value =[];

  data.forEach(function(d, position) {
    if (d[musicGenre] > like) {
      allPosition.push(position);
      total++;
    };
  });

  music.value = value;
  music.musicGenre = musicGenre;
  music.total = total;
  nestData.push(music)
});
```
This function will give this result:
```
0: {value: Array(11), musicGenre: "Dance", total: 376}
1: {value: Array(11), musicGenre: "Folk", total: 144}
2:{value: Array(11), musicGenre: "Country", total: 118}
3 etc
```

From there we want to know how many of these people like a specific genre.
This function will do just that:
```javascript
allMovieGenre.forEach(function(movieGenre){
  let movieValue = {};
  let movieTotal = 0;
  allPosition.forEach(function(position){
      if(data[position][movieGenre] > like){
        movieTotal++;
      }
  });
  movieValue.movieGenre = movieGenre;
  movieValue.total = movieTotal;
  value.push(movieValue);
});
```
And from that we got this as result;
```
musicGenre:"Dance"
total:376
value: Array(11)
0:{movieGenre: "Horror", total: 139}
1:{movieGenre: "Thriller", total: 203}
2:{movieGenre: "Comedy", total: 343}
3:{movieGenre: "Romantic", total: 214}
4:{movieGenre: "Sci-fi", total: 149}
5 etc
```
Ok now that we have that, lets look at sankey function again and look how it want its data presented. src: https://stackoverflow.com/questions/14629853/json-representation-for-d3-force-directed-networks.
```javascript
sankey
  .nodes(sankeyData.nodes)
  .links(sankeyData.links)
  .layout(32);
```
If we look at that function, we can see it wants a 'source', a 'target' and a 'value'.
In our nestData we all have this information. We will create a function that get all the 'source' and value;
The function looks like this:
```javascript
//Format data to sankey
var nodes = [];
var links = [];
var sankyData = {nodes, links};

nestData.forEach(function(d){
  var total = d.movieTotal;
  d.value.forEach(function(data){
    let linkObject = {};
    linkObject.source = d.musicGenre;
    linkObject.target = data.movieGenre;
    linkObject.value = Math.round(data.total/d.movieTotal*100);//calculate the percentage
    links.push(linkObject)
  });
});
```

that will give us this:
```
1:{source: "Dance", target: "Thriller", value: 9}
2:{source: "Dance", target: "Comedy", value: 16}
3:{source: "Dance", target: "Romantic", value: 10}
4:{source: "Dance", target: "Sci-fi", value: 7}
5:{source: "Dance", target: "War", value: 7}
6:{source: "Dance", target: "Fantasy/Fairy tales", value: 11}
7:{source: "Dance", target: "Animated", value: 11}
8:{source: "Dance", target: "Documentary", value: 10}
9:{source: "Dance", target: "Western", value: 2}
10:{source: "Dance", target: "Action", value: 11}
etc
```
/Value is in percentage/

Getting all the name (object) is simple because we already have an array that  saved all  name of the music genre and movie genre;
```javascript
var nodes = [];
//Get all nodes
  allMusicGenre.forEach(function(d){
    nodes.push(d);
  });
  allMovieGenre.forEach(function(d){
    nodes.push(d);
  });
```
From there we saved all data data that we have in an objects
```javascript
var sankyData = {nodes, links};
```
This object contains all the 'nodes', 'source', 'target' and 'value';

Ok now we will add the 'sankeyData' object to the sankey function like this:

```javascript
sankey
  .nodes(sankeyData.nodes)
  .links(sankeyData.links)
  .layout(32);
```

If we refresh the browser, the browser will give this error:
```
Uncaught TypeError: Cannot read property 'push' of undefined
```
Why is that?

After searching on the web why it doesnt work, I stumble on the solution:
First of all why I doesn't work:

If we look at the sankey function, it is searching for the index, a number value. Like this:

```
{
"nodes":[
{"node":0,"name":"node0"},
{"node":1,"name":"node1"},
{"node":2,"name":"node2"},
{"node":3,"name":"node3"},
{"node":4,"name":"node4"}
],
"links":[
{"source":0,"target":2,"value":2},
{"source":1,"target":2,"value":2},
{"source":1,"target":3,"value":2},
{"source":0,"target":4,"value":2},
{"source":2,"target":3,"value":2},
{"source":2,"target":4,"value":2},
{"source":3,"target":4,"value":4}
]}
```
Here you can see that the source and target correspont with the index of the nodes.  Instead what we have on those places are the name.
So we need to change the name to the index of the nodes.

This little piece of code will do just that for us:
```javascript
var nodeMap = {};
 sankeyData.nodes.forEach(function(x) { nodeMap[x.name] = x; });
 sankeyData.links = sankeyData.links.map(function(x) {
 return {
 source: nodeMap[x.source],
 target: nodeMap[x.target],
 value: x.value
 };
 });
```
this solution comes from stackoverflow https://stackoverflow.com/questions/14629853/json-representation-for-d3-force-directed-networks

Ok now we will refresh the browser again
It will represent us with this:
![sanky example](assets/image/sankey1.PNG)
That more like it!

Still why are nodes without lines?
If we look at the console it give us this error:/
```
Error: <path> attribute d: Expected number, "…58505670447 490,NaN 944,NaN".
```
So it gets something that is not a number.

If we log the 'nestData' we can see why that is.

```
11:{value: Array(11), musicGenre: "Swing,  Jazz", total: 0, movieTotal: 0}
12:{value: Array(11), musicGenre: "Rock 'n Roll", total: 0, movieTotal: 0}
```
some value are zero. So we need to create a function that fillter this out.
After long digging  I cant come up with a solution. So I just delete it out of the array :)

So lets refresh the page again.
![sanky example](assets/image/sankey1work.gif)
It works!!!

Now lets add different color to the nodes, so we can differentiate them.
This was created by d3noob from here: https://bl.ocks.org/d3noob/013054e8d7807dff76247b81b0e29030;
First lets add a variable color.
```javascript
  var color = d3.scaleOrdinal(d3.schemeCategory20);
```
And in the rect lets add a function that calls the color.
```javascript
// add the rectangles for the nodes
node.append("rect")
  .attr("height", function(d) {
    return d.dy;
  })
  .attr("width", sankey.nodeWidth())
  .style("fill", function(d) {
    return d.color = color(d.name.replace(/ .*/, "")); })//<---here
  .append("title")
  .text(function(d) {
    return d.name + "\n" + format(d.value);
  });
  ```
  now lets see what we have
![sanky example](assets/image/sankeyAddColor.gif)

Still that's a lot of Nodes. Lets make it that if you  click on a Node. lets say for example 'Pop', all the other nodes will disapear and you will only have one node left.

First lets add an ID and a click Handler to the nodes, so we know which nodes we've clicked on.
```javascript
node.append("rect")
  .attr("height", function(d) {
    return d.dy;
  })
  .attr("width", sankey.nodeWidth())
  .attr('id', function(d){//<--here
    return d.name
  })
  .on('click', showOneData)//<--and here
  .style("fill", function(d) {
    return d.color = color(d.name.replace(/ .*/, "")); })
  .append("title")
  .text(function(d) {
    return d.name + "\n" + format(d.value);
  });
```

From there we're going to write a function that redraw the graph but with only one object in an array. The array contains the ID.
```javascript
var allMusicGenre = [genre];//Genre contains the name of the id
```
Lets see what we have
![sanky example](assets/image/sankeyClick.gif)
Very nice!

Ok lets make it a little bit nice and at a transition to it.

I created this function that draw the lines
```javascript
//this is added to the link object to create a white space
.attr("stroke-dashoffset", "1870")
.attr("stroke-dasharray", "1870")
```
```javascript
//transition function
function transition() {
     var path = d3.selectAll('.link');
     path
          .transition()
          .duration(4000)
          .attr("stroke-dashoffset", "0");
}
```
Now lets see the product
![sanky example](assets/image/sankeyTransition.gif)

## The making of the bar chart
By the making of the bar chat I created a new javascript function. This is done to keep the code organized, or else we dont know which code is which anymore.

The first thing I did was getting the height and width of the div container, so we can set our range
```javascript
//this will be our range
widthBar = d3.select('.bar-chart-container').node();
widthBar = widthBar.getBoundingClientRect().width; //get width of container
heightBar = d3.select('.bar-chart-container').node();
heightBar = heightBar.getBoundingClientRect().height; //get width of container
```
From there we add this to the svg
```javascript
//The svg to draw the bar chart in
var svgBar = d3.select(".bar-chart-container").append('svg'),
  margin = {
    top: 20,
    right: 20,
    bottom: 30,
    left: 40
  },
  width = +widthBar - margin.left - margin.right,
  height = +heightBar - margin.top - margin.bottom;

var groups = svgBar.append('g')
  .attr("transform", "translate(" + margin.left + "," + margin.top + ")");;
```

From there we're going to add the x and y axis.
We want to make a horizontal barchart so the y-axis is ordinal and the x is linear
We can also set the domain and range because we already know that from 'SankeyData'
```javascript
//y Scale
var yAs = d3.scaleBand()
     .range([0, height])
     .paddingInner(0.3)
     .domain(data.map(
          function(d) {
               return d.name
          }
     ));

//x Scale
var xAs = d3.scaleLinear()
     .range([0, width])
     .domain([0, d3.max(data, function(d) {
          return d.value;
     })]);
     //create the x-as
     g.append('g')
          .attr('class', 'axis axis--y')
          .call(d3.axisLeft(yAs));

     //create the y-as
     g.append('g')
          .attr('class', 'axis axis--x')
          .call(d3.axisBottom(xAs))
          .attr('transform', 'translate(0,' + height + ')');
     ```
     ![barChart first try](assets/image/barChartNothing.gif)

Ok the bar chart is there, but without any bar. So lets add that to it.
```javascript
//binding
var rect = g.append('g').selectAll('rect').data(data);
//This will be the underweight bar
rect.enter()
     .append('rect')
     .attr('class', 'bar')
     .attr('x', '0')
     .attr('y', function(d){
         return yAs(d.name);
     })
    .attr('width', function(d){
        return xAs(d.value);
    })
    .attr('height', yAs.bandwidth());
```
Now lets see it again
 ![barChart first try](assets/image/barChartAlmost.gif)
 Very nice!  But why does it not fill the whole space.
 After a long of digging, I've found the solution.
In my css I gave the the bar chart container a display of flex and because of that it doesn't get the full width but the full height;

```css
.bar-chart-container{
    display: inline-flex;
    width: 35vw;
    height: 40vh;
}
```
We need to change the direction of the container so it get the full width. So lets and Flex-direction: column;
```css
.bar-chart-container{
    display: inline-flex;
    flex-direction: column;
    width: 35vw;
    height: 40vh;
}
```
After that lets also add a fill color that correspont with the nodes.
Lets see that again
![barChart first try](assets/image/barChartFinisch.gif)

## Todo
- The bar chart ascending based on value
- Make the movie genre clickable

### licence
MIT License

Copyright (c) [2017] [Chanakarn Niyornram]


text:
# EXOS Applications
These directories contain applications/application updates that run on Extreme Switches running the EXOS OS.

They are added to an EXOS switch using either the CLI command:
```
download image <ip> <filename>
```
or
```
download url <url>
```

## License
Copyright© 2016, Extreme Networks
All rights reserved.

Redistribution and use in source and binary forms, with or without modification,
are permitted provided that the following conditions are met:

1. Redistributions of source code must retain the above copyright notice, this
list of conditions and the following disclaimer.

2. Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.

## Support
The software is provided as is and Extreme Networks has no obligation to provide
maintenance, support, updates, enhancements or modifications.
Any support provided by Extreme Networks is at its sole discretion.

Issues and/or bug fixes may be reported on [The Hub](https://community.extremenetworks.com/extreme).

branch_name: refs/heads/master

extension: md

gha_language: HTML

license_type: permissive


text:
# SharedStreets (Python)

This fork has utilities for turning SharedStreets event tiles into geojson.

See https://github.com/sharedstreets/sharedstreets-python for source project README.

## Setup

1. Clone this fork

        git clone git@github.com:schnerd/sharedstreets-python.git
        cd sharedstreets-python

1. Prepare a [Python virtual environment](http://docs.python-guide.org/en/latest/dev/virtualenvs/#virtualenv) running Python 3.

1.  Install the `sharedstreets` module, keeping it editable

        pip install --editable .

1.  Install shapely dependency

        pip install shapely

## Use

### Convert events tiles to geojson file

If you just ran the [SharedStreets matcher](https://github.com/sharedstreets/sharedstreets-matcher), chances are you ended up with tiles containing `SharedStreetsWeeklyBinnedLinearReferences`. You can use `events-to-geojson.py` to convert the output `.events.pbf` tiles to a geojson file, suitable for visualization in kepler.

```
python events-to-geojson.py [input_path] [output_file]
```

For example:
```
python events-to-geojson.py ../event_tiles ./events.geojson
```

### Other scripts

`events-aggregate.py` can be used to convert `SharedStreetsWeeklyBinnedLinearReferences` to `SharedStreetsBinnedLinearReferences`.

`events-filter.py` can be used to filter out non-desirable event types from tiles.

license: MIT

repository: schnerd/sharedstreets-python

repo_name: schnerd/sharedstreets-python


text:
### [CVE-2007-2189](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2189)
![](https://img.shields.io/static/v1?label=Product&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=n%2Fa&color=blue)
![](https://img.shields.io/static/v1?label=Vulnerability&message=n%2Fa&color=brighgreen)

### Description

PHP remote file inclusion vulnerability in admin/admin_album_otf.php in the MX Smartor Full Album Pack (FAP) 2.0 RC1 module for mxBB allows remote attackers to execute arbitrary PHP code via a URL in the phpbb_root_path parameter.

### POC

#### Reference
- https://www.exploit-db.com/exploits/3766

#### Github
No PoCs found on GitHub currently.

repository: trickest/cve

branch_name: refs/heads/main

gha_license_id: MIT

repo_name: trickest/cve


text:
GAE app REST API
================

- [POST /shutdown](#shutdown)
- [POST /extend](#extend)

Failure response format
-----------------------

Failure response body is a JSON object with these fields:

- `status`: HTTP status code
- `error`: Error message

`POST /shutdown`
-------------------------------------

Shutdown all instances and delete target instances in `neco-gcp.yml`.

### Verification

This API is supposed to be called from AppEngine Cron Service.

This API verifies the `X-Appengine-Cron` contained in the request header.

### Successful response

- HTTP status code: 200 OK
- HTTP response header: Content-Type: application/json
- HTTP response body: list of stopped and deleted instances.

```json
{
  "stopped": ["docker-test"],
  "deleted": ["host-vm"]
}
```

### Failure responses

- 400 Bad Request: missing or wrong configuration file.
- 500 Internal Server Error: other error.

`POST /extend`
---------------------------------

Extend the lifetime the given GCP instance is shutdown.

### Request

The request body is a JSON formatted in [slack.InteractionCallback](https://godoc.org/github.com/nlopes/slack#InteractionCallback).

The target instance name will be stored in `actions.block_actions[0].value` field.

### Verification

This API is supposed to be called from Slack Application.

This API verifies the token contained in the request body.
ref. https://api.slack.com/events-api#url_verification

### Successful response

- HTTP status code: 200 OK
- HTTP response header: Content-Type: application/json
- HTTP response body: the name of the extended instance.

```json
{
  "extended": "instance-123"
}
```

### Failure responses

- 500 Internal Server Error: other error.

repository: laashub-soa/neco

repo_name: laashub-soa/neco


text:
---
layout: post
title: "Black Dragon Wyrmling"
date: 2017-09-10
tags: [medium, dragon, cr2, monster-manual]
---

**Medium dragon, chaotic evil**

**Armor Class** 17 (natural armor)

**Hit Points** 33 (6d8+6)

**Speed** 30 ft., fly 60 ft., swim 30 ft.

|   STR   |   DEX   |   CON   |   INT   |   WIS   |   CHA   |
|:-----:|:-----:|:-----:|:-----:|:-----:|:-----:|
| 15 (+2) | 14 (+2) | 13 (+1) | 10 (0) | 11 (0) | 13 (+1) |

**Saving Throws** Dex +4, Con +3, Wis +2, Cha +3

**Skills** Perception +4, Stealth +4

**Damage Immunities** acid

**Senses** blindsight 10 ft., darkvision 60 ft.

**Languages** Draconic

**Challenge** 2 (450 XP)

***Amphibious.*** The dragon can breathe air and water.

**Actions**

***Bite.*** Melee Weapon Attack: +4 to hit, reach 5 ft., one target. Hit: 7 (1d10 + 2) piercing damage plus 2 (1d4) acid damage.

***Acid Breath (Recharge 5-6).*** The dragon exhales acid in a 15-foot line that is 5 feet wide. Each creature in that line must make a DC 11 Dexterity saving throw, taking 22 (Sd8) acid damage on a failed save, or half as much damage on a successful one.

extension: markdown

gha_language: Vue


text:
---
layout:     post
title:      Test Post
subtitle:   测试隐藏按钮
date:       2020-05-02
author:     chmlee
header-img: img/post-bg-re-vs-ng2.jpg
catalog: true
tags:
    - Blog
---

# title

This is a post to test the hide functionality.

    <button onclick="hide('item1')">Button 1</button>

        Press "Button 1" to hide this line.

You are not able to hide this line

    <button onclick="hide('item2')">Button 2</button>

        Press "Button 2" to hide this line.

You don't necessarily need a button element; "onclick" works on almost all elements.

Press HIDE to hide the next sentence

        Something something blablabla

If you download the raw markdown file, you'll notice two non-markdown syntax:

```html
<script src="/js/hide-toggle.js"></script>
```

and

```html
<div class="hide-wrapper">
    <button onclick="hide('item1')">Button 1</button>

    <div id="item1">
        Press "Button 1" to hide this line.
    </div>
</div>
```

The first line of code loads the javascript file that make hiding element possible.
Copy [this javascript file](https://github.com/chmlee/chmlee.github.io/blob/master/js/hide-toggle.js) to [the `js` folder in your repository](https://github.com/chelsiexie7/chelsiexie7.github.io/tree/master/js)

The second line of code is self-explanatory.
Three things to note:
1. You don't necessarily need `class='hide-wrapper'`, but if you want to further customized your post with css, be careful at what you name your class attribute.
2. The `id` attribute in `div` has to match that variable in `hide` function. In this case, to hide `<div id="item1"></div>`, we need a button with `<button onclick="hide('item1')">Button 1</button>`
3. `id` attribute in each `div` has to be unique. We've used `item1` as the `id` for the example, so we should never use this `item1` for other `div`

To learn more about the difference between `class` and `id`, visit [w3school](https://github.com/chelsiexie7/chelsiexie7.github.io/tree/master/js)


text:
#
 Component Definitions for .NET

This framework is a part of [Pip.Services](https://github.com/pip-services/pip-services) project.
It defines components that can be used to implement non-trivial business logic in applications and services.

The key difference of this framework is a portable implementation across variety of different languages.
Currently it supports Java, .NET, Python, Node.js, Golang. The code provides reasonably thin abstraction layer
over most fundamental functions and delivers symmetric implementation that can be quickly ported between different platforms.

- **Auth** - credentials parameters and credential stores
- **Build** - component factories framework
- **Config** - configuration readers
- **Connect** - connection parameters and discovery services
- **Count** - performance counters
- **Info** - context information
- **Lock** - distributed locks
- **Log** - logging components

Quick Links:

* [Downloads](https://github.com/pip-services3-dotnet/pip-services3-components-dotnet/blob/master/doc/Downloads.md)
* [API Reference](https://pip-services3-dotnet.github.io/pip-services3-components-dotnet/)
* [Building and Testing](https://github.com/pip-services3-dotnet/pip-services3-components-dotnet/blob/master/doc/Development.md)
* [Contributing](https://github.com/pip-services3-dotnet/pip-services3-components-dotnet/blob/master/doc/Development.md/#contrib)

## Acknowledgements

The .NET version of Pip.Services is created and maintained by:
- **Sergey Seroukhov**
- **Alex Mazur**
- **Andrew Harrington**
- **Volodymyr Tkachenko**
- **Mark Zontak**

Many thanks to contibutors, who put their time and talant into making this project better:
- **Nick Jimenez**, BootBarn Inc.


text:
# ByteString: Fast, Packed Strings of Bytes

[![Build Status](https://github.com/haskell/bytestring/workflows/ci/badge.svg)](https://github.com/haskell/bytestring/actions?query=workflow%3Aci) [![Hackage](http://img.shields.io/hackage/v/bytestring.svg)](https://hackage.haskell.org/package/bytestring) [![Stackage LTS](http://stackage.org/package/bytestring/badge/lts)](http://stackage.org/lts/package/bytestring) [![Stackage Nightly](http://stackage.org/package/bytestring/badge/nightly)](http://stackage.org/nightly/package/bytestring)

This library provides the `Data.ByteString` module -- strict and lazy
byte arrays manipulable as strings -- providing very time/space-efficient
string and IO operations.

For very large data requirements, or constraints on heap size,
`Data.ByteString.Lazy` is provided, a lazy list of bytestring chunks.
Efficient processing of multi-gigabyte data can be achieved this way.

The library also provides `Data.ByteString.Builder` for efficient construction
of `ByteString` values from smaller pieces during binary serialization.

Requirements:

  * Cabal 1.10 or greater
  * GHC 8.0 or greater

### Authors

`ByteString` was derived from the GHC `PackedString` library,
originally written by Bryan O'Sullivan, and then by Simon Marlow.
It was adapted and greatly extended for darcs by David Roundy and
others. Don Stewart and Duncan Coutts cleaned up and further extended
the implementation and added the `.Lazy` code. Simon Meier contributed
the `Builder` feature.

repository: haskell/bytestring

gha_language: Haskell

gha_license_id: NOASSERTION

repo_name: haskell/bytestring


text:
This is a copy of the text files from the [IANA timezone database](https://www.iana.org/time-zones) To update to the most recent versions change
```xml
    <TimeZoneDataVersion>2020d</TimeZoneDataVersion>
```
To the [latest version](https://data.iana.org/time-zones/tzdb/version) and run `dotnet build /t:UpdateToLatestVersion`

To check if the included version is up to date run `dotnet build /t:CheckVersion`

repository: dotnet/runtime-assets

gha_language: C#

repo_name: dotnet/runtime-assets


text:
# Contributing

The OpenAPI JS Connector is an Open Source Project [licensed under the Apache 2.0 License](LICENSE).

## Getting Started

-   Make sure you have a [GitHub account](https://github.com/signup/free)
-   Submit [a ticket](https://github.com/saxobank/openapi-connector-js/issues) for your issue, assuming one does not already exist.
    -   Clearly describe the issue including steps to reproduce when it's a bug
    -   Make sure you fill in the earliest version that you know as the issue
-   Fork the repository on GitHub

## Making Changes

-   Optionally create a topic branch from where you want to base your work.
    -   This is usually the master branch.
    -   Only target release branches if you are certain your fix must be on that
        branch.
-   Make commits of logical units.
-   Check for unnecessary whitespace with `git diff --check` before committing.
-   Make sure your commit messages are in the proper format:

```
    Make the example in CONTRIBUTING imperative and concrete

    Without this patch applied the example commit message in the CONTRIBUTING
    document is not a concrete example.  This is a problem because the
    contributor is left to imagine what the commit message should look like
    based on a description rather than an example.  This patch fixes the
    problem by making the example concrete and imperative.

    The first line is a real life imperative statement.
    The body describes the behavior without the patch, why this is a problem,
    and how the patch fixes the problem when applied. And lastly, if the commit
    resolves a specific issue, reference that  at the bottom.

    Fixes #12
```

-   Make sure you have added the necessary tests for your changes.
-   Run _all_ the tests to assure nothing else was accidentally broken.

## Submitting Changes

-   Push your changes to a topic branch in your fork of the repository.
-   Submit a pull request to the repository in the SaxoBank organization.
-   The core team looks at Pull Requests on a regular basis.
-   After feedback has been given we expect responses within two weeks.
-   After two weeks we may close the pull request if it isn't showing any activity.

Happy committing!

repository: SaxoBank/openapi-clientlib-js

gha_language: TypeScript

repo_name: SaxoBank/openapi-clientlib-js


text:
### ticks

![ticks.png](images/ticks.png)

```julia
plot(sin, 0, 2π,
    xtick=(0:0.5:2π, ["$i a" for i in 0:0.5:2π]),
    ytick=-1:0.2:1,
    xrotation=60, ## -> rotate xticks 60 degree
    yrotation=90,
    # rotation=60, # x,y ticks rotation
)
```

---

*This page was generated using [Literate.jl](https://github.com/fredrikekre/Literate.jl).*


text:
# Contributing Guidelines
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->

- [Contributor License Agreements](#contributor-license-agreements)
- [Finding Things That Need Help](#finding-things-that-need-help)
- [Versioning](#versioning)
  - [Codebase and Go Modules](#codebase-and-go-modules)
    - [Backporting a patch](#backporting-a-patch)
  - [APIs](#apis)
  - [CLIs](#clis)
- [Branches](#branches)
  - [Support and guarantees](#support-and-guarantees)
  - [Removal of v1alpha3 & v1alpha4 apiVersions](#removal-of-v1alpha3--v1alpha4-apiversions)
- [Contributing a Patch](#contributing-a-patch)
- [Documentation changes](#documentation-changes)
- [Releases](#releases)
- [Proposal process (CAEP)](#proposal-process-caep)
- [Triaging E2E test failures](#triaging-e2e-test-failures)
- [Reviewing a Patch](#reviewing-a-patch)
- [Reviews](#reviews)
  - [Approvals](#approvals)
- [Features and bugs](#features-and-bugs)
- [Experiments](#experiments)
- [Breaking Changes](#breaking-changes)
- [Dependency Licence Management](#dependency-licence-management)
- [API conventions](#api-conventions)
  - [Optional vs. Required](#optional-vs-required)
    - [Example](#example)
    - [Exceptions](#exceptions)
  - [CRD additionalPrinterColumns](#crd-additionalprintercolumns)
- [Google Doc Viewing Permissions](#google-doc-viewing-permissions)
- [Issue and Pull Request Management](#issue-and-pull-request-management)
- [Contributors Ladder](#contributors-ladder)

<!-- END doctoc generated TOC please keep comment here to allow auto update -->

Read the following guide if you're interested in contributing to cluster-api.

Contributors who are not used to working in the Kubernetes ecosystem should also take a look at the Kubernetes [New Contributor Course.](https://www.kubernetes.dev/docs/onboarding/)

## Contributor License Agreements

We'd love to accept your patches! Before we can take them, we have to jump a couple of legal hurdles.

Please fill out either the individual or corporate Contributor License Agreement (CLA). More information about the CLA
and instructions for signing it [can be found here](https://git.k8s.io/community/CLA.md).

***NOTE***: Only original source code from you and other people that have signed the CLA can be accepted into the
*repository.

## Finding Things That Need Help

If you're new to the project and want to help, but don't know where to start, we have a semi-curated list of issues that
should not need deep knowledge of the system. [Have a look and see if anything sounds
interesting](https://github.com/kubernetes-sigs/cluster-api/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22).
Before starting to work on the issue, make sure that it doesn't have a [lifecycle/active](https://github.com/kubernetes-sigs/cluster-api/labels/lifecycle%2Factive) label. If the issue has been assigned, reach out to the assignee.
Alternatively, read some docs on other controllers and try to write your own, file and fix any/all issues that
come up, including gaps in documentation!

If you're a more experienced contributor, looking at unassigned issues in the next release milestone is a good way to find work that has been prioritized. For example, if the latest minor release is `v1.0`, the next release milestone is `v1.1`.

Help and contributions are very welcome in the form of code contributions but also in helping to moderate office hours, triaging issues, fixing/investigating flaky tests, being part of the [release team](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/release/release-team.md), helping new contributors with their questions, reviewing proposals, etc.

## Versioning

### Codebase and Go Modules

> ⚠ The project does not follow Go Modules guidelines for compatibility requirements for 1.x semver releases.

Cluster API follows upstream Kubernetes semantic versioning. With the v1 release of our codebase, we guarantee the following:

- A (*minor*) release CAN include:
  - Introduction of new API versions, or new Kinds.
  - Compatible API changes like field additions, deprecation notices, etc.
  - Breaking API changes for deprecated APIs, fields, or code.
  - Features, promotion or removal of feature gates.
  - And more!

- A (*patch*) release SHOULD only include backwards compatible set of bugfixes.

These guarantees extend to all code exposed in our Go Module, including
*types from dependencies in public APIs*.
Types and functions not in public APIs are not considered part of the guarantee.
The test module, clusterctl, and experiments do not provide any backward compatible guarantees.

#### Backporting a patch

We generally do not accept PRs directly against release branches, while we might accept backports of fixes/changes already
merged into the main branch.

Any backport MUST not be breaking for either API or behavioral changes.

We generally allow backports of following changes to all supported branches:
- Critical bugs fixes, security issue fixes, or fixes for bugs without easy workarounds.
- Dependency bumps for CVE (usually limited to CVE resolution; backports of non-CVE related version bumps are considered exceptions to be evaluated case by case)
- Cert-manager version bumps (to avoid having releases with cert-manager versions that are out of support, when possible)
- Changes required to support new Kubernetes versions, when possible. See [supported Kubernetes versions](https://cluster-api.sigs.k8s.io/reference/versions.html#supported-kubernetes-versions) for more details.
- Changes to use the latest Go patch release. If the Go minor version of a supported branch goes out of support, we will consider on a case-by-case basis
  to bump to a newer Go minor version (e.g. to pick up CVE fixes). This could have impact on everyone importing Cluster API.

We generally allow backports of following changes only to the latest supported branch:
- Improvements to existing docs (the latest supported branch hosts the current version of the book)
- Improvements to CI signal
- Improvements to the test framework

While we recommend to target following type of changes to the next minor release, CAPI maintainers will also consider
exceptions for backport of following changes only to the latest supported branch:
- Enhancements or additions to experimental Cluster API features, with the goal of allowing faster adoption and iteration;
  Please note that stability of the branch will always be top priority while evaluating those PRs, and thus approval
  requires /lgtm from at least two maintainers that, on top of checking that the backport is not introducing any breaking
  change for either API or behavior, will evaluate if the impact of those backport is limited and well-scoped e.g.
  by checking that those changes should not touch non-experimental code paths like utils and/or by applying other
  considerations depending on the specific PR.

Like any other activity in the project, backporting a fix/change is a community-driven effort and requires that someone volunteers to own the task.
In most cases, the cherry-pick bot can (and should) be used to automate opening a cherry-pick PR.

We generally do not accept backports to Cluster API release branches that are [out of support](https://github.com/kubernetes-sigs/cluster-api/blob/main/CONTRIBUTING.md#support-and-guarantees).

### APIs

API versioning and guarantees are inspired by the [Kubernetes deprecation policy](https://kubernetes.io/docs/reference/using-api/deprecation-policy/)
and [API change guidelines](https://github.com/kubernetes/community/blob/f0eec4d19d407c13681431b3c436be67da8c448d/contributors/devel/sig-architecture/api_changes.md).
We follow the API guidelines as much as possible adapting them if necessary and on a case-by-case basis to CustomResourceDefinition.

### CLIs

Any command line interface in Cluster API (e.g. clusterctl) share the same versioning schema of the codebase.
CLI guarantees are inspired by [Kubernetes deprecation policy for CLI](https://kubernetes.io/docs/reference/using-api/deprecation-policy/#deprecating-a-flag-or-cli),
however we allow breaking changes after 8 months or 2 releases (whichever is longer) from deprecation.

## Branches

Cluster API has two types of branches: the *main* branch and
*release-X* branches.

The *main* branch is where development happens. All the latest and
greatest code, including breaking changes, happens on main.

The *release-X* branches contain stable, backwards compatible code. On every
major or minor release, a new branch is created. It is from these
branches that minor and patch releases are tagged. In some cases, it may
be necessary to open PRs for bugfixes directly against stable branches, but
this should generally not be the case.

### Support and guarantees

Cluster API maintains the most recent release/releases for all supported API and contract versions. Support for this section refers to the ability to backport and release patch versions;
[backport policy](#backporting-a-patch) is defined above.

- The API version is determined from the GroupVersion defined in the top-level `api/` package.
- The EOL date of each API Version is determined from the last release available once a new API version is published.

| API Version  | Supported Until                                                                         |
|--------------|-----------------------------------------------------------------------------------------|
| **v1beta1**  | TBD (current stable)                                                                    |
| **v1alpha4** | EOL since 2022-04-06 ([apiVersion removal](#removal-of-v1alpha3--v1alpha4-apiversions)) |
| **v1alpha3** | EOL since 2022-02-23 ([apiVersion removal](#removal-of-v1alpha3--v1alpha4-apiversions)) |

- For the current stable API version (v1beta1) we support the two most recent minor releases; older minor releases are immediately unsupported when a new major/minor release is available.
- For older API versions we only support the most recent minor release until the API version reaches EOL.
- We will maintain test coverage for all supported minor releases and for one additional release for the current stable API version in case we have to do an emergency patch release.
  For example, if v1.2 and v1.3 are currently supported, we will also maintain test coverage for v1.1 for one additional release cycle. When v1.4 is released, tests for v1.1 will be removed.

| Minor Release | API Version  | Supported Until                                     |
|---------------|--------------|-----------------------------------------------------|
| v1.5.x        | **v1beta1**  | when v1.7.0 will be released                        |
| v1.4.x        | **v1beta1**  | when v1.6.0 will be released, tentatively Nov 2023  |
| v1.3.x        | **v1beta1**  | EOL since 2023-07-25 - v1.5.0 release date          |
| v1.2.x        | **v1beta1**  | EOL since 2023-03-28 - v1.4.0 release date          |
| v1.1.x        | **v1beta1**  | EOL since 2022-07-18 - v1.2.0 release date (*)      |
| v1.0.x        | **v1beta1**  | EOL since 2022-02-02 - v1.1.0 release date (*)      |
| v0.4.x        | **v1alpha4** | EOL since 2022-04-06 - API version EOL              |
| v0.3.x        | **v1alpha3** | EOL since 2022-02-23 - API version EOL              |

(*) Previous support policy applies, older minor releases were immediately unsupported when a new major/minor release was available

- Exceptions can be filed with maintainers and taken into consideration on a case-by-case basis.

### Removal of v1alpha3 & v1alpha4 apiVersions

We are going to remove the apiVersions in upcoming releases:
* v1.5:
  * Kubernetes API server stops serving the v1alpha3 apiVersion
* v1.6:
  * v1alpha3 apiVersion is removed from the CRDs
  * Kubernetes API server stops serving the v1alpha4 apiVersion
* v1.7
  * v1alpha4 apiVersion is removed from the CRDs
For more details and latest information please see the following issue: [Removing v1alpha3 & v1alpha4 apiVersions](https://github.com/kubernetes-sigs/cluster-api/issues/8038).

Note: Removal of a deprecated APIVersion in Kubernetes [can cause issues with garbage collection by the kube-controller-manager](https://github.com/kubernetes/kubernetes/issues/102641)
This means that some objects which rely on garbage collection for cleanup - e.g. MachineSets and their descendent objects, like Machines and InfrastructureMachines, may not be cleaned up properly if those
objects were created with an APIVersion which is no longer served.
To avoid these issues it's advised to ensure a restart to the kube-controller-manager is done after upgrading to a version of Cluster API which drops support for an APIVersion - e.g. v1.5 and v1.6.
This can be accomplished with any Kubernetes control-plane rollout, including a Kubernetes version upgrade, or by manually stopping and restarting the kube-controller-manager.

## Contributing a Patch

1. If you haven't already done so, sign a Contributor License Agreement (see details above).
1. If working on an issue, signal other contributors that you are actively working on it using `/lifecycle active`.
1. Fork the desired repo, develop and test your code changes.
1. Submit a pull request.
    1. All code PR must be labeled with one of
        - ⚠ (`:warning:`, major or breaking changes)
        - ✨ (`:sparkles:`, feature additions)
        - 🐛 (`:bug:`, patch and bugfixes)
        - 📖 (`:book:`, documentation or proposals)
        - 🌱 (`:seedling:`, minor or other)
1. If your PR has multiple commits, you must [squash them into a single commit](https://kubernetes.io/docs/contribute/new-content/open-a-pr/#squashing-commits) before merging your PR.

Individual commits should not be tagged separately, but will generally be
assumed to match the PR. For instance, if you have a bugfix in with
a breaking change, it's generally encouraged to submit the bugfix
separately, but if you must put them in one PR, mark the commit
separately.

All changes must be code reviewed. Coding conventions and standards are explained in the official [developer
docs](https://git.k8s.io/community/contributors/devel). Expect reviewers to request that you
avoid common [go style mistakes](https://github.com/golang/go/wiki/CodeReviewComments) in your PRs.

## Documentation changes

The documentation is published in form of a book at:

- [Current stable release](https://cluster-api.sigs.k8s.io)
- [Tip of the main branch](https://main.cluster-api.sigs.k8s.io/)
- [v1alpha4 release branch](https://release-0-4.cluster-api.sigs.k8s.io/)
- [v1alpha3 release branch](https://release-0-3.cluster-api.sigs.k8s.io/)
- [v1alpha2 release branch](https://release-0-2.cluster-api.sigs.k8s.io/)

The source for the book is [this folder](https://github.com/kubernetes-sigs/cluster-api/tree/main/docs/book/src)
containing markdown files and we use [mdBook][] to build it into a static
website.

After making changes locally you can run `make serve-book` which will build the HTML version
and start a web server, so you can preview if the changes render correctly at
http://localhost:3000; the preview auto-updates when changes are detected.

Note: you don't need to have [mdBook][] installed, `make serve-book` will ensure
appropriate binaries for mdBook and any used plugins are downloaded into
`hack/tools/bin/` directory.

When submitting the PR remember to label it with the 📖 (:book:) icon.

[mdBook]: https://github.com/rust-lang/mdBook

## Releases

- Minor versions CAN be planned and scheduled for each quarter, or sooner if necessary.
  - Each minor version is preceded with one or more planning session.
  - Planning consists of one or more backlog grooming meetings, roadmap amendments,
    and CAEP proposal reviews.
  - Cluster API uses [GitHub milestones](https://github.com/kubernetes-sigs/cluster-api/milestones) to track work
    for minor releases.
  - Adding an issue to a milestone provides forward visibility on what the next release will be, so, as soon as there
    is the intent to work on an issue for a specific target release, contributors are expected to work with maintainers to
    set the milestone on the issue so it will be tracked for the release (note: only major features/bug fixes specifically
    targeting a release must be tracked; everything else will simply merge when ready without additional toil).
  - Before adding an issue to a release milestone, maintainers must ensure that the issue have been triaged and
    there is an assignee who expressed the intent to complete the work before the release date.
  - An issue being in the milestone doesn't guarantee inclusion in the release; this depends on the work being
    completed before the release code freeze target date.
  - Code freeze is in effect at least 72 hours (3 days) before a major/minor release.
  - Maintainers should communicate the code freeze date at a community meeting preceding the code freeze date.
  - Only critical bug fixes may be merged in between freeze & release.
    - Each bug MUST be associated with an open issue and properly triaged.
    - PRs MUST be approved by at least 2 project maintainers.
      - First approver should `/approve` and `/hold`.
      - Second approver should `/approve` and `/hold cancel`.
  - [E2E Test grid](https://testgrid.k8s.io/sig-cluster-lifecycle-cluster-api#capi%20e2e%20tests) SHOULD be green before cutting a release.
- Patch versions CAN be planned and scheduled each month for supported minor releases.
- Dates in a release are approximations and always subject to change.

## Proposal process (CAEP)

The Cluster API Enhancement Proposal is the process this project uses to adopt new features, changes to the APIs, changes to contracts between components, or changes to CLI interfaces.

The [template](https://github.com/kubernetes-sigs/cluster-api/blob/main/docs/proposals/YYYYMMDD-template.md), and accepted proposals live under [docs/proposals](https://github.com/kubernetes-sigs/cluster-api/tree/main/docs/proposals).

- Proposals or requests for enhancements (RFEs) MUST be associated with an issue.
  - Issues can be placed on the roadmap during planning if there is one or more folks
    that can dedicate time to writing a CAEP and/or implementing it after approval.
- A proposal SHOULD be introduced and discussed during the weekly community meetings or on the
 [Kubernetes SIG Cluster Lifecycle mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle).
  - Submit and discuss proposals using a collaborative writing platform, preferably Google Docs, share documents with edit permissions with the [Kubernetes SIG Cluster Lifecycle mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle).
- A proposal in a Google Doc MUST turn into a [Pull Request](https://github.com/kubernetes-sigs/cluster-api/pulls).
- Proposals MUST be merged and in `implementable` state to be considered part of a major or minor release.

## Triaging E2E test failures

When you submit a change to the Cluster API repository as set of validation jobs is automatically executed by
prow and the results report is added to a comment at the end of your PR.

Some jobs run linters or unit test, and in case of failures, you can repeat the same operation locally using `make test lint [etc..]`
in order to investigate and potential issues. Prow logs usually provide hints about the make target you should use
(there might be more than one command that needs to be run).

End-to-end (E2E) jobs create real Kubernetes clusters by building Cluster API artifacts with the latest changes.
In case of E2E test failures, usually it's required to access the "Artifacts" link on the top of the prow logs page to triage the problem.

The artifact folder contains:
- A folder with the clusterctl local repository used for the test, where you can find components yaml and cluster templates.
- A folder with logs for all the clusters created during the test. Following logs/info are available:
    - Controller logs (only if the cluster is a management cluster).
    - Dump of the Cluster API resources (only if the cluster is a management cluster).
    - Machine logs (only if the cluster is a workload cluster)

In case you want to run E2E test locally, please refer to the [Testing](https://cluster-api.sigs.k8s.io/developer/testing.html#running-unit-and-integration-tests) guide. An overview over our e2e test jobs (and also all our other jobs) can be found in [Jobs](https://cluster-api.sigs.k8s.io/reference/jobs.html).

## Reviewing a Patch

## Reviews

> Parts of the following content have been adapted from https://google.github.io/eng-practices/review.

Any Kubernetes organization member can leave reviews and `/lgtm` a pull request.

Code reviews should generally look at:

- **Design**: Is the code well-designed and consistent with the rest of the system?
- **Functionality**: Does the code behave as the author (or linked issue) intended? Is the way the code behaves good for its users?
- **Complexity**: Could the code be made simpler?  Would another developer be able to easily understand and use this code when they come across it in the future?
- **Tests**: Does the code have correct and well-designed tests?
- **Naming**: Did the developer choose clear names for variable, types, methods, functions, etc.?
- **Comments**: Are the comments clear and useful? Do they explain why rather than what?
- **Documentation**: Did the developer also update relevant documentation?

See [Code Review in Cluster API](REVIEWING.md) for a more focused list of review items.

### Approvals

Please see the [Kubernetes community document on pull
requests](https://git.k8s.io/community/contributors/guide/pull-requests.md) for more information about the merge
process.

- A PR is approved by one of the project maintainers and owners after reviews.
- Approvals should be the very last action a maintainer takes on a pull request.

## Features and bugs

Open [issues](https://github.com/kubernetes-sigs/cluster-api/issues/new/choose) to report bugs, or discuss minor feature implementation.

Each new issue will be automatically labeled as `needs-triage`; after being triaged by the maintainers the label
will be removed and replaced by one of the following:

- `triage/accepted`: Indicates an issue or PR is ready to be actively worked on.
- `triage/duplicate`: Indicates an issue is a duplicate of another open issue.
- `triage/needs-information`: Indicates an issue needs more information in order to work on it.
- `triage/not-reproducible`: Indicates an issue can not be reproduced as described.
- `triage/unresolved`: Indicates an issue that can not or will not be resolved.

For big feature, API and contract amendments, we follow the CAEP process as outlined below.

## Experiments

Proof of concepts, code experiments, or other initiatives can live under the `exp` folder or behind a feature gate.

- Experiments SHOULD not modify any of the publicly exposed APIs (e.g. CRDs).
- Experiments SHOULD not modify any existing CRD types outside the experimental API group(s).
- Experiments SHOULD not modify any existing command line contracts.
- Experiments MUST not cause any breaking changes to existing (non-experimental) Go APIs.
- Experiments SHOULD introduce utility helpers in the go APIs for experiments that cross multiple components
  and require support from bootstrap, control plane, or infrastructure providers.
- Experiments follow a strict lifecycle: Alpha -> Beta prior to Graduation.
  - Alpha-stage experiments:
    - SHOULD not be enabled by default and any feature gates MUST be marked as 'Alpha'
    - MUST be associated with a CAEP that is merged and in at least a provisional state
    - MAY be considered inactive and marked as deprecated if the following does not happen within the course of 1 minor release cycle:
      - Transition to Beta-stage
      - Active development towards progressing to Beta-stage
      - Either direct or downstream user evaluation
    - Any deprecated Alpha-stage experiment MAY be removed in the next minor release.
  - Beta-stage experiments:
    - SHOULD be enabled by default, and any feature gates MUST be marked as 'Beta'
    - MUST be associated with a CAEP that is at least in the experimental state
    - MUST support conversions for any type changes
    - MUST remain backwards compatible unless updates are coinciding with a breaking Cluster API release
    - MAY be considered inactive and marked as deprecated if the following does not happen within the course of 1 minor release cycle:
      - Graduate
      - Active development towards Graduation
      - Either direct or downstream user consumption
    - Any deprecated Beta-stage experiment MAY be removed after being deprecated for an entire minor release.
- Experiment Graduation MUST coincide with a breaking Cluster API release
- Experiment Graduation checklist:
  - [ ] MAY provide a way to be disabled, any feature gates MUST be marked as 'GA'
  - [ ] MUST undergo a full Kubernetes-style API review and update the CAEP with the plan to address any issues raised
  - [ ] CAEP MUST be in an implementable state and is fully up-to-date with the current implementation
  - [ ] CAEP MUST define transition plan for moving out of the experimental api group and code directories
  - [ ] CAEP MUST define any upgrade steps required for Existing Management and Workload Clusters
  - [ ] CAEP MUST define any upgrade steps required to be implemented by out-of-tree bootstrap, control plane, and infrastructure providers.

## Breaking Changes

Breaking changes are generally allowed in the `main` branch, as this is the branch used to develop the next minor
release of Cluster API.

There may be times, however, when `main` is closed for breaking changes. This is likely to happen as we near the
release of a new minor version.

Breaking changes are not allowed in release branches, as these represent minor versions that have already been released.
These versions have consumers who expect the APIs, behaviors, etc. to remain stable during the lifetime of the patch
stream for the minor release.

Examples of breaking changes include:

- Removing or renaming a field in a CRD
- Removing or renaming a CRD
- Removing or renaming an exported constant, variable, type, or function
- Updating the version of critical libraries such as controller-runtime, client-go, apimachinery, etc.
    - Some version updates may be acceptable, for picking up bug fixes, but maintainers must exercise caution when
      reviewing.

There may, at times, need to be exceptions where breaking changes are allowed in release branches. These are at the
discretion of the project's maintainers, and must be carefully considered before merging. An example of an allowed
breaking change might be a fix for a behavioral bug that was released in an initial minor version (such as `v0.3.0`).

## Dependency Licence Management

Cluster API follows the [license policy of the CNCF](https://github.com/cncf/foundation/blob/main/allowed-third-party-license-policy.md). This sets limits on which
licenses dependencies and other artifacts use. For go dependencies only dependencies listed in the `go.mod` are considered dependencies. This is in line with [how dependencies are reviewed in Kubernetes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/vendor.md#reviewing-and-approving-dependency-changes).

## API conventions

This project follows the [Kubernetes API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md). Minor modifications or additions to the conventions are listed below.

### Optional vs. Required

* Status fields MUST be optional. Our controllers are patching selected fields instead of updating the entire status in every reconciliation.

* If a field is required (for our controllers to work) and has a default value specified via OpenAPI schema, but we don't want to force users to set the field, we have to mark the field as optional. Otherwise, the client-side kubectl OpenAPI schema validation will force the user to set it even though it would be defaulted on the server-side.

Optional fields have the following properties:
* An optional field MUST be marked with `+optional` and include an `omitempty` JSON tag.
* Fields SHOULD be pointers if there is a good reason for it, for example:
  * the nil and the zero values (by Go standards) have semantic differences.
    * Note: This doesn't apply to map or slice types as they are assignable to `nil`.
  * the field is of a struct type, contains only fields with `omitempty` and you want
    to prevent that it shows up as an empty object after marshalling (e.g. `kubectl get`)

#### Example

When using ClusterClass, the semantic difference is important when you have a field in a template which will
have instance-specific different values in derived objects. Because in this case it's possible to set the field to `nil`
in the template and then the value can be set in derived objects without being overwritten by the cluster topology controller.

#### Exceptions

* Fields in root objects should be kept as scaffolded by kubebuilder, e.g.:
  ```golang
  type Machine struct {
    metav1.TypeMeta   `json:",inline"`
    metav1.ObjectMeta `json:"metadata,omitempty"`

    Spec   MachineSpec   `json:"spec,omitempty"`
    Status MachineStatus `json:"status,omitempty"`
  }
  type MachineList struct {
    metav1.TypeMeta `json:",inline"`
    metav1.ListMeta `json:"metadata,omitempty"`
    Items           []Machine `json:"items"`
  }
  ```

* Top-level fields in `status` must always have the `+optional` annotation. If we want the field to be always visible even if it
  has the zero value, it must **not** have the `omitempty` JSON tag, e.g.:
  * Replica counters like `availableReplicas` in the `MachineDeployment`
  * Flags expressing progress in the object lifecycle like `infrastructureReady` in `Machine`

### CRD additionalPrinterColumns

All our CRD objects should have the following `additionalPrinterColumns` order (if the respective field exists in the CRD):
* Namespace (added automatically)
* Name (added automatically)
* Cluster
* Other fields
* Replica-related fields
* Phase
* Age (mandatory field for all CRDs)
* Version
* Other fields for -o wide (fields with priority `1` are only shown with `-o wide` and not per default)

***NOTE***: The columns can be configured via the `kubebuilder:printcolumn` annotation on root objects. For examples, please see the `./api` package.

Examples:
```bash
kubectl get kubeadmcontrolplane
```
```bash
NAMESPACE            NAME                               INITIALIZED   API SERVER AVAILABLE   REPLICAS   READY   UPDATED   UNAVAILABLE   AGE     VERSION
quick-start-d5ufye   quick-start-ntysk0-control-plane   true          true                   1          1       1                       2m44s   v1.23.3
```
```bash
kubectl get machinedeployment
```
```bash
NAMESPACE            NAME                      CLUSTER              REPLICAS   READY   UPDATED   UNAVAILABLE   PHASE       AGE     VERSION
quick-start-d5ufye   quick-start-ntysk0-md-0   quick-start-ntysk0   1                  1         1             ScalingUp   3m28s   v1.23.3
```

## Google Doc Viewing Permissions

To gain viewing permissions to google docs in this project, please join either the
[kubernetes-dev](https://groups.google.com/forum/#!forum/kubernetes-dev) or
[kubernetes-sig-cluster-lifecycle](https://groups.google.com/forum/#!forum/kubernetes-sig-cluster-lifecycle) google
group.

## Issue and Pull Request Management

Anyone may comment on issues and submit reviews for pull requests. However, in order to be assigned an issue or pull
request, you must be a member of the [Kubernetes SIGs](https://github.com/kubernetes-sigs) GitHub organization.

If you are a Kubernetes GitHub organization member, you are eligible for membership in the Kubernetes SIGs GitHub
organization and can request membership by [opening an
issue](https://github.com/kubernetes/org/issues/new?template=membership.md&title=REQUEST%3A%20New%20membership%20for%20%3Cyour-GH-handle%3E)
against the kubernetes/org repo.

However, if you are a member of the related Kubernetes GitHub organizations but not of the Kubernetes org, you
will need explicit sponsorship for your membership request. You can read more about Kubernetes membership and
sponsorship [here](https://git.k8s.io/community/community-membership.md).

Cluster API maintainers can assign you an issue or pull request by leaving a `/assign <your Github ID>` comment on the
issue or pull request.

## Contributors Ladder

New contributors are welcomed to the community by existing members, helped with PR workflow, and directed to relevant documentation and communication channels.
We are also committed in helping people willing to do so in stepping up through the contributor ladder and this paragraph describes how we are trying to make this to happen.

As the project adoption increases and the codebase keeps growing, we’re trying to break down ownership into self-driven subareas of interest.
Requirements from the [Kubernetes community membership guidelines](https://github.com/kubernetes/community/blob/master/community-membership.md) apply for reviewers, maintainers and any member of these subareas.
Whenever you meet requisites for taking responsibilities in a subarea, the following procedure should be followed:
1. Submit a PR.
2. Propose at community meeting.
3. Get positive feedback and +1s in the PR and wait one week lazy consensus after agreement.

As of today there are following OWNERS files/Owner groups defining sub areas:
- [Clusterctl](https://github.com/kubernetes-sigs/cluster-api/tree/main/cmd/clusterctl)
- [kubeadm Bootstrap Provider (CABPK)](https://github.com/kubernetes-sigs/cluster-api/tree/main/bootstrap/kubeadm)
- [kubeadm Control Plane Provider (KCP)](https://github.com/kubernetes-sigs/cluster-api/tree/main/controlplane/kubeadm)
- [Cluster Managed topologies, ClusterClass](https://github.com/kubernetes-sigs/cluster-api/tree/main/internal/controllers/topology)
- [Infrastructure Provider Docker (CAPD)](https://github.com/kubernetes-sigs/cluster-api/tree/main/test/infrastructure/docker)
- [Infrastructure Provider in-memory](https://github.com/kubernetes-sigs/cluster-api/tree/main/test/infrastructure/inmemory)
- [Test](https://github.com/kubernetes-sigs/cluster-api/tree/main/test)
- [Test Framework](https://github.com/kubernetes-sigs/cluster-api/tree/main/test/framework)
- [Docs](https://github.com/kubernetes-sigs/cluster-api/tree/main/docs)

repository: kubernetes-sigs/cluster-api

gha_language: Go

repo_name: kubernetes-sigs/cluster-api


text:
# algore
Automatically exported from code.google.com/p/algore

AL Gore Library
Author: Herb Gilliland

Tasty C++ class wrappers and mixer implementation for OpenAL built on Chris Robinson's ALURE library. Comes with some crunky LinkedList and ListItem classes which you are welcome to use or change.

Use with ALURE, OpenAL, libsndfile / libFLAC etc. Provides a simple and effective programmer interface to easily deal with the ALURE libraries and implements ALURE on Windows and Linux. Effectively uses both the one-off and streaming capabilities of OpenAL/ALURE and via libsndfile libflac et al supports a wide variety of sound file formats.

 #include <Windows.h>
 #include "Audio.h"

 Audio mixer; // Initializes our audio manager

 ALSound *s;

 audio.Load( "godspeed.wav" );
 audio.Load( "sounds/hello.wav" );
 audio.manager.CueAndPlay( "sounds/hello.wav", 1.0f, 1.0f, false, true );
 s=audio.manager.Cue( "sounds/hello.wav", 1.0f, 1.0f, false, true );
 s->Play();

 ALUREStream *streaming=audio.manager.AddStream("afilebiggerthan2mb.flac",null,0,false);
 streaming->Play();

 // Updated on a timer...
 SoundSequencer sequencer;
 SoundEvent event;

 sequencer.audio=&mixer;

 event=new SoundEvent;
 event.stream=audio.manager.AddStream("sounds/spoken/golden.wav",null,0,false);
 event.delay=0.75f;
 sequencer.events.sounds.Add(event);

 // During timed loop:
 ...
 sequencer.Update( deltaSecondsf );
Coming soon:

Full EAX/EFX support
Verified capturing features
Speex integration with networked audio support (TeamSpeak?)
Integrated 3D sourcing (currently supports 3D audio sourcing, but needs more controller objects)


text:
Electronic Paper Toys
============================

Electronic paper toys is an open source project developed by [Laboratório de Criação Digital](https://www.lcdporto.org). The goal of this project is to fuse electronics and paper for educational purposes.

![Electronic Paper Toys](paper_toys_photo.jpg)

## Want to contribute?

Want to contribute? Excellent! We are open to suggestions, collaborations and improvements. Get in touch or make a pull request!

## Donate

If you like the project and don't want or can't contribute why not make a donation. We are a nonprofit organization.

repository: OhMeuMenino/electronic-paper-toys

repo_name: OhMeuMenino/electronic-paper-toys


text:
# UF Sponsor Update

Given a file of sponsors, update or add sponsors to VIVO

## Method

Use filters to transform the sponsors.txt data into an input file
for updating the sponsor data in VIVO.  UF sponsor data is limited -- label and SponsorID only.

## Filters

1. Manage_columns_filter.py -- replace all columns with columns needed for ingest.  Improve the sponsor organization
name (UF supplies all upper case and abbreviations).  Add uri, remove and type as columns to facilitate data
management
1. unique_sponsorid_filter.py -- remove rows that duplicated sponsorid.  sponsorid should be unique prior to ingest.
1. merge_filter.py -- look up each sponsorid in VIVO and add the uri to the input file

## Columns in the source data

Seven columns result from the filters:

1. name
1. sponsorid
1. type
1. uri
1. remove
1. harvested_by
1. date_harvested

    cat sponsors.txt | python manage_columns_filter.py | python unique_sponsorid_filter.py |
    python merge_filter.py -v > sponsor_update_data.txt

gha_language: TeX


text:
# Type: obsoletion

Obsoletion of an element deprecates usage of that element, but does not delete that element.

URI: [ocl:Obsoletion](http://w3id.org/oclObsoletion)

![img](http://yuml.me/diagram/nofunky;dir:TB/class/[NodeObsoletion]uses%20-.->[Obsoletion],[EdgeObsoletion]uses%20-.->[Obsoletion],[ChangeMixin]^-[Obsoletion],[NodeObsoletion],[EdgeObsoletion],[ChangeMixin])

## Parents

 *  is_a: [ChangeMixin](ChangeMixin.md) - root class for all change mixins

## Mixin for

 * [EdgeObsoletion](EdgeObsoletion.md) (mixin)  - An edge change in which an edge is obsoleted.
 * [NodeObsoletion](NodeObsoletion.md) (mixin)  - Obsoletion of a node deprecates usage of that node, but does not delete it.

## Referenced by class

## Attributes

## Other properties

|  |  |  |
| --- | --- | --- |
| **See also:** | | http://wiki.geneontology.org/index.php/Obsoleting_an_Existing_Ontology_Term |


text:
---
layout: post
title: PHP 5.6.31, 7.0.22, 7.1.8 available
tags: [module, php]
---
{% include vars.html %}

Releases of PHP 5.6.31, 7.0.22, 7.1.8 ([Issue #310]({{ var_repo_url }}/issues/310)) are now available.<br />
You can find links to download these releases on the [PHP page](/modules/php).

branch_name: refs/heads/dev


text:
# DATA_512_jiyuw
This is the repository of DATA512 Human-centered Data Science course.

Contents of each assignment (including specific README file) can be found in individual folders.

## A1-Data Curation
Folder: [A1-Data Curation](Data-512-A1/)

## A2-Data Bias
Folder: [A2-Data Bias](Data-512-A2/)

## final project
Folder: [final](Data-512-final/)

gha_language: Jupyter Notebook


text:
# Make Rails Use Minitest::Spec!
##### https://dhh.dk/2012/rails-is-omakase.html

The minitest-spec-rails gem makes it easy to use the Minitest::Spec DSL within your existing Rails 2.3, 3.x or 4.x test suite. It does this by forcing ActiveSupport::TestCase to utilize the Minitest::Spec::DSL.

[![Gem Version](https://badge.fury.io/rb/minitest-spec-rails.svg)](http://badge.fury.io/rb/minitest-spec-rails)
[![CI Status](https://github.com/metaskills/minitest-spec-rails/workflows/CI/badge.svg)](https://launch-editor.github.com/actions?nwo=metaskills%2Fminitest-spec-rails&workflowID=CI)
[![Maintainability](https://api.codeclimate.com/v1/badges/e67addda6fd009b68349/maintainability)](https://codeclimate.com/github/metaskills/minitest-spec-rails/maintainability)

## Usage

Existing or new Rails applications that use the default Rails testing structure can simply drop in the minitest-spec-gem and start writing their tests in the new spec DSL. Since Minitest::Spec is built on top of Minitest::Unit, a replacement for Test::Unit, all of your existing tests will continue to work.

#### Rails 4.1 to 6.0

Our master branch is tracking rails 5.1 up to 6.x active development.

```ruby
group :test do
  gem 'minitest-spec-rails'
end
```

#### For Rails 3.x or 4.0

Our [3-x-stable](https://github.com/metaskills/minitest-spec-rails/tree/3-x-stable) branch is meant for both Rails 3.x or 4.0 specifically. This version uses the latest 4.x series of minitest.

```ruby
group :test do
  gem 'minitest-spec-rails', '~> 4.7'
end
```

### How is this different than Minitest::Rails?

To start off both Mike Moore (@blowmage) and I have worked together and we both LOVE Minitest::Spec. Both projects aim to advocate Minitest and make Rails integration as easy as possible. However, there are a few key differences in our projects. Some of these differences may go away in time too. As always, choose the tool you think fits your needs. So how, is minitest-spec-rails different than [minitest-rails](https://github.com/blowmage/minitest-rails)?

  * We aim to leverage existing Rails test directories and files!
  * No special test helper and/or generators.
  * Easy migration path for existing Rails applications.
  * How we go about freedom patching Rails.
  * Fully support Ruby 1.8.7 with all legacy Test::Unit behavior.
  * Compatibility with ActiveSupport::TestCase's setup and teardowns.

So the goal of this project is to make Rails 3 or 4 applications just work as if rails-core had decided to support Minitest::Spec all along. We believe that eventually that day will come and when it does, all your tests will still work! So bundle up and get started!

```ruby
gem 'minitest-spec-rails'
```

## Test Styles

This cheat sheet shows both the Minitest::Unit assertions along with the Minitest::Spec assertion syntax. Remember, Minitest::Spec is built on top of Minitest::Unit which is a Test::Unit replacement. That means you can mix and match styles as you upgrade from Test::Unit to a more modern style. For example, both of these would work in Minitest::Spec and are interchangeable.

```ruby
# Minitest::Unit Assertion Style:
assert_equal 100, foo

# Minitest::Spec Assertion Style:
expect(foo).must_equal 100
```

```ruby
require 'test_helper'
class UserTest < ActiveSupport::TestCase
  let(:user_ken)   { User.create! :email =><EMAIL_ADDRESS>}
  it 'works' do
    expect(user_ken).must_be_instance_of User
  end
end
```

```ruby
require 'test_helper'
describe User do
  # THIS IS NOT RECOMMENDED!
end
```

RSpec 3 is also moving away from the outer describe test type inference, as described in this line from their [release notes](https://www.relishapp.com/rspec/rspec-rails/v/3-1/docs/changelog).

> Spec types are no longer inferred by location, they instead need to be explicitly tagged. The old behaviour is enabled by config.infer_spec_type_from_file_location!, which is still supplied in the default generated spec_helper.rb. (Xavier Shay, Myron Marston)

Not that we want to mimic RSpec, but the aim of this gem is very straight forward and minimalistic. We simply want to expose the Minitest Spec::DSL and core assertion style within ActiveSupport. Period. So it is very possible that us matching outer describe to classes is simply going to go away one day soon.

Just for reference, here is a full list of each of Rails test case we support.

```ruby
# Model Test (or anything else not listed below)
class UserTest < ActiveSupport::TestCase
end

# Controller Test
class UsersControllerTest < ActionController::TestCase
end

# Integration Tests - Must use subclass style!
class IntegrationTest < ActionDispatch::IntegrationTest
end

# Mailer Test
class UserMailerTest < ActionMailer::TestCase
end

# View Helper Test
class UsersHelperTest < ActionView::TestCase
end

# Job Helper Test
class MyJobTest < ActiveJob::TestCase
end
```

## Extras

We have baked in a few extra methods behind the scenes to minitest-spec-rails. Most directly support our needs to reflect on described classes, however, they may be useful to you too when meta-programming on top of minitest-spec-rails.

### #described_class
The `described_class` method is available both via a class method and an instance method in any Rails test case. It is guaranteed to work despite the described level too. This allows class level macros to be built, much like Shoulda. Remember, it can only do this if you follow Rails naming conventions for your tests.

```ruby
class UserTest < ActiveSupport::TestCase
  described_class # => User(id: integer, email: string)
  it 'works here' do
    described_class # => User(id: integer, email: string)
  end
  describe 'and' do
    it 'works here too' do
      described_class # => User(id: integer, email: string)
    end
  end
end
```

### Setup & Teardown Compatability

Rails ActiveSupport::TestCase allows multiple setup and teardown methods per class. It also allows you to specify these either with a symbol or a block. Unlike normal ActiveSupport setup and teardown callbacks, our blocks are evaluated in the scope of the instance, just like before and after. So this just works!

```ruby
class ActiveSupportCallbackTest < ActiveSupport::TestCase

  setup :foo
  setup :bar
  before { @bat = 'biz' }

  it 'works' do
    expect(@foo).must_equal 'foo'
    expect(@bar).must_equal 'bar'
    expect(@bat).must_equal 'biz'
  end

  private

  def foo ; @foo = 'foo' ; end
  def bar ; @bar = 'bar' ; end

end
```

### mini_shoulda

If you are migrating away from Shoulda, then minitest-spec-rails' mini_shoulda feature will help. To enable it, set the following configuration in your test environment file.

```ruby
# In config/environments/test.rb
config.minitest_spec_rails.mini_shoulda = true
```

Doing so only enables a few aliases that allow the Shoulda `context`, `should`, and `should_eventually` methods. The following code demonstrates the full features of the mini_shoulda implementation. It basically replaces the shell of [shoulda-context](https://github.com/thoughtbot/shoulda-context) in a few lines of code.

```ruby
class PostTests < ActiveSupport::TestCase
  setup    { @post = Post.create! :title => 'Test Title', :body => 'Test body' }
  teardown { Post.delete_all }
  should 'work' do
    @post.must_be_instance_of Post
  end
  context 'with a user' do
    should_eventually 'have a user' do
      # ...
    end
  end
end
```

If you prefer the assertions provided by shoulda-context like `assert_same_elements`, then you may want to consider copying them [from here](https://github.com/thoughtbot/shoulda-context/blob/master/lib/shoulda/context/assertions.rb) and including them in `Minitest::Spec` yourself. I personally recommend just replacing these assertions with something more modern. A few examples are below.

```ruby
assert_same_elements a, b         # From
expect(a.sort).must_equal b.sort  # To

assert_does_not_contain a, b  # From
expect(a).wont_include b      # To
```

### Matchers

**I highly suggest that you stay away from matchers** since Minitest::Spec gives you all the tools you need to write good tests. Staying away from matchers will make your code's tests live longer. So my advice is to stay away from things like `.should ==` and just write `.must_equal` instead. However, if matchers are really your thing, I recommend the [minitest-matchers](https://github.com/wojtekmach/minitest-matchers) gem. You can also check out the [valid_attribute](https://github.com/bcardarella/valid_attribute) gem built on top of minitest-matchers.

```ruby
describe Post do
  subject { Post.new }
  it { must have_valid(:title).when("Hello") }
  it { wont have_valid(:title).when("", nil, "Bad") }
end
```

Alternatively, try the [mintest-matchers_vaccine](https://github.com/rmm5t/minitest-matchers_vaccine) gem to avoid _infecting_ the objects that you want to test.

```ruby
describe User do
  subject { User.new }
  it "should validate email" do
    must<EMAIL_ADDRESS><EMAIL_ADDRESS>    wont have_valid(:email).when(nil, "", "foo", "foo@bar")
  end
end
```

## Gotchas

### Assertion Methods

If you are upgrading from Test::Unit, there are a few missing assertions that have been renamed or are no longer available within Minitest.

* The method `assert_raise` is renamed `assert_raises`.
* There is no method `assert_nothing_raised`. There are good reasons for this on [Ryan's blog entry](http://blog.zenspider.com/blog/2012/01/assert_nothing_tested.html).

### Mocha

If you are using [Mocha](https://github.com/freerange/mocha) for mocking and stubbing, please update to the latest, 0.13.1 or higher so it is compatible with the latest Minitest. If you do not like the deprecation warnings in older versions of Rails, just add this below the `require 'rails/all'` within your `application.rb` file :)

```ruby
require 'mocha/deprecation'
Mocha::Deprecation.mode = :disabled
```

### Rails 3.0.x

If you are using minitest-spec-rails with Rails 3.0, then your controller and mailer tests will need to use the `tests` interface for the assertions to be setup correctly within sub `describe` blocks. I think this is a bug with `class_attribute` within Rails 3.0 only. So use the following patterns.

```ruby
class UsersControllerTest < ActionController::TestCase
  tests UsersController
end
class UserMailerTest < ActionMailer::TestCase
  tests UserMailer
end
```

### Rails 3.1 & 3.2

If your view helper tests give you an eror like this: `RuntimeError: In order to use #url_for, you must include routing helpers explicitly.`, this is something that is broken only for Rails 3.1 and 3.2, both 3.0 and 4.0 and above do not exhibit this error. I have heard that if you `include Rails.application.routes.url_helpers` in your tests or inject them into the helper module before the test it may work. Lemme know what you find out.

 If you detect a problem, open up a github issue or fork the repo and help out. After you fork or clone the repository, the following commands will get you up and running on the test suite.

```shell
$ bundle install
$ bundle exec appraisal update
$ bundle exec appraisal rake test
```

We use the [appraisal](https://github.com/thoughtbot/appraisal) gem from Thoughtbot to help us generate the individual gemfiles for each Rails version and to run the tests locally against each generated Gemfile. The `rake appraisal test` command actually runs our test suite against all Rails versions in our `Appraisal` file. If you want to run the tests for a specific Rails version, use `bundle exec appraisal -h` for a list. For example, the following command will run the tests for Rails 4.1 only.

```shell
$ bundle exec appraisal rails_v6.0.x rake test
$ bundle exec appraisal rails_v6.1.x rake test
$ bundle exec appraisal rails_v7.0.x rake test
```

We have a few branches for each major Rails version.

* [2-3-stable](https://github.com/metaskills/minitest-spec-rails/tree/2-3-stable) - Tracks Rails 2.3.x with MiniTest 4.x.
* [3-x-stable](https://github.com/metaskills/minitest-spec-rails/tree/3-x-stable) - Oddly tracks Rails 3.x and 4.0 with MiniTest 4.x.
* master - Currently tracks Rails 4.1 which uses Minitest 5.0.

repository: metaskills/minitest-spec-rails

gha_language: Ruby

repo_name: metaskills/minitest-spec-rails


text:
Log in with VMware Identity Manager
===================================

This demo application shows how to use Spring Boot and the Spring
security SAML2 extensions to let a user authenticate with VMware
Identity Manager™, using the SAML2 protocol.

This application is based on the [Spring SAML2 Demo application](https://github.com/vdenotaris/spring-boot-security-saml-sample)
and has been modified to integrate VMware Identity Manager as an identity provider (IdP).

Building the project
--------------------

### Prerequisites

-   You need a [VMware Identity Manager](http://www.air-watch.com/vmware-identity-manager-free-trial)
    tenant, like https://dev.vmwareidentity.asia, where you have
    **admin** access (if you want to add your own application). You can
    test the application as is, as it is configured by default on an
    provided tenant.

-   The project requires JDK 8.

### Building from IDE

-   Clone this project.

-   Then import the root folder. You can run the main class named
    `com.vmware.idm.samples.saml.Application`.

### Building from the Command Line

You can run the application locally by using

-   `$ ./gradlew bootRun`

-   Navigate to `http://localhost:8080`

Another option is to build the jar file and run it with
`./gradlew build` and
`java -jar build/libs/webapp-spring-boot-saml2.jar` (per the Spring Boot
docs and other available documentation).

You can now select the "SSO Login Page" and the first IdP and click
`Login`. You can use `user1` as username and `vmware` as the password.

### Configure the Demo Application

If you want to configure the application to log in users from your own
VMware Identity Manager organization, you need to add and configure that
SAML2 application in your Identity Manager catalog.

1.  Edit the local `./src/main/resources/application.properties`
    file to setup your organization URL:
    ```properties
    vmware.url=https://<your VMware IDM URL>
    ```
    and run the application: `$ ./gradlew bootRun.`

2.  Login to your VMware Identity Manager organization (https://<your VMware IDM URL>)) as an
    administrator

3.  Create a new SAML2 application, by clicking on the `Catalog` tab,
    and `Add Application` button, then select `...create a new one.`
    ![Create SAML2 app](images/CreateSAML2App.png)

Then edit the name, description and icon of the application. Click
`Next.`
![Edit SAML2 app details](images/EditSAML2App.png)

4.  In the `Application Configuration` page, select `Meta-data XML` for
    the `Configure Via` option. And paste the XML content that you
    downloaded from your running local application:
    http://localhost:8080/saml/metadata.
    Click `Save`.
    ![Configure SAML2 app](images/ConfigureSAML2App.png)

5.  Add the entitlements to this application. You can choose
    `Add group entitlement` and type `ALL USERS` to entitle this
    application to all users in your system.

You can now log in to your application from http://localhost:8080, and
you can also launch your application from the VMware Identity Manager
end user catalog.

repository: vmware/idm

repo_name: vmware/idm


text:
# React Weather App

Weather app built with React, MobX and styled-components.

### Built With

*   [Create React App](https://github.com/facebook/create-react-app)
*   [Styled Components](https://github.com/styled-components/styled-components)
*   [MobX](https://github.com/mobxjs/mobx)

## Demo

Live demo: [weather-app](http://react-weather-forecast-app.surge.sh/)

## Installing / Getting started

```shell
yarn install
yarn run start
```

Open your browser and visit http://localhost:3000/

### Building

```shell
yarn build
```

All the static files will be in the build folder.

## Deployment

```shell
yarn deploy
```

## License

This project is licensed under the MIT License - see the [LICENSE.md](LICENSE.md) file for details

repository: srdjanRakic/weather-app

repo_name: srdjanRakic/weather-app


text:
# 007 Discovering and Deleting Indexes

```
db.<collection>.getIndexes()
```

Note: the index on '_id' is created automatically and cannot be deleted.

To drop an index, use `dropIndex({<key1>:1})`. Use the name as given when you do `getIndexes()`

Example:

```
db.employees.dropIndex({username:1})
```

url: https://raw.githubusercontent.com/martianfield/M101JS/7b672f68248243ed3f08b9cdfa39fdb15bc90e9e/week05 - Indexes and Performance/007 Discovering and Deleting Indexes.md

filename: 007 Discovering and Deleting Indexes.md


text:
# Fusarium moniliforme var. lactis (Pirotta & Riboni) Bilai, 1987 VARIETY

#### Status
SYNONYM

#### According to
The Catalogue of Life, 3rd January 2011

#### Published in
Mikrobiol. Zh. 49(6): 7 (1987)

#### Original name
Fusarium lactis Pirotta, 1879

### Remarks
null

repository: mdoering/backbone

path: /life/Fungi/Ascomycota/Sordariomycetes/Hypocreales/Nectriaceae/Fusarium/Fusarium lactis/ Syn. Fusarium moniliforme lactis/README.md

repo_name: mdoering/backbone


text:
# fyt
Downloads a youtube channel and its videos and stores them locally as a podcatcher-friendly feed.

## Installation
Configure by running:
```
fyt config
```

## How to use it

### Adding a new feed
```
fyt add
```

### Fetching and downloading feeds
```
fyt run
```

repository: ChaosSteffen/fyt

repo_name: ChaosSteffen/fyt


text:
**[137. Single Number II](https://leetcode.com/problems/single-number-ii/)**

Given a non-empty array of integers, every element appears three times except for one, which appears exactly once. Find that single one.

**Note:**

Your algorithm should have a linear runtime complexity. Could you implement it without using extra memory?

**Example 1：**

```
Input: [2,2,3,2]
Output: 3

```

**Example 2：**

```
Input: [0,1,0,1,0,1,99]
Output: 99

```

**Solution:**

Runtime: 0 ms<br/>
Memory Usage: 42.1 MB

```java
class Solution {
    public int singleNumber(int[] nums) {
        int m = 0, n = 0;
        for(int num : nums) {
            m = ~ n & (m ^ num);
            n = ~ m & (n ^ num);
        }
        return m;
    }
}

```

repository: HughQS/leetcode

path: /medium/137. Single Number II.md

filename: 137. Single Number II.md

repo_name: HughQS/leetcode


text:
# What is VitePress?

VitePress is a [Static Site Generator](https://en.wikipedia.org/wiki/Static_site_generator) (SSG) designed for building fast, content-centric websites. In a nutshell, VitePress takes your source content written in [Markdown](https://en.wikipedia.org/wiki/Markdown), applies a theme to it, and generates static HTML pages that can be easily deployed anywhere.

<div class="tip custom-block" style="padding-top: 8px">

Just want to try it out? Skip to the [Quickstart](./getting-started).

</div>

## Use Cases

- **Documentation**

  VitePress ships with a default theme designed for technical documentation. It powers this page you are reading right now, along with the documentation for [Vite](https://vitejs.dev/), [Rollup](https://rollupjs.org/), [Pinia](https://pinia.vuejs.org/), [VueUse](https://vueuse.org/), [Vitest](https://vitest.dev/), [D3](https://d3js.org/), [UnoCSS](https://unocss.dev/), [Iconify](https://iconify.design/) and [many more](https://www.vuetelescope.com/explore?framework.slug=vitepress).

  The [official Vue.js documentation](https://vuejs.org/) is also based on VitePress, but uses a custom theme shared between multiple translations.

- **Blogs, Portfolios, and Marketing Sites**

  VitePress supports [fully customized themes](./custom-theme), with the developer experience of a standard Vite + Vue application. Being built on Vite also means you can directly leverage Vite plugins from its rich ecosystem. In addition, VitePress provides flexible APIs to [load data](./data-loading) (local or remote) and [dynamically generate routes](./routing#dynamic-routes). You can use it to build almost anything as long as the data can be determined at build time.

  The official [Vue.js blog](https://blog.vuejs.org/) is a simple blog that generates its index page based on local content.

## Developer Experience

VitePress aims to provide a great Developer Experience (DX) when working with Markdown content.

- **[Vite-Powered:](https://vitejs.dev/)** instant server start, with edits always instantly reflected (<100ms) without page reload.

- **[Built-in Markdown Extensions:](./markdown)** Frontmatter, tables, syntax highlighting... you name it. Specifically, VitePress provides many advanced features for working with code blocks, making it ideal for highly technical documentation.

- **[Vue-Enhanced Markdown:](./using-vue)** each Markdown page is also a Vue [Single-File Component](https://vuejs.org/guide/scaling-up/sfc.html), thanks to Vue template's 100% syntax compatibility with HTML. You can embed interactivity in your static content using Vue templating features or imported Vue components.

## Performance

Unlike many traditional SSGs, a website generated by VitePress is in fact a [Single Page Application](https://en.wikipedia.org/wiki/Single-page_application) (SPA).

- **Fast Initial Load**

  The initial visit to any page will be served the static, pre-rendered HTML for blazing fast loading speed and optimal SEO. The page then loads a JavaScript bundle that turns the page into a Vue SPA ("hydration"). The hydration process is extremely fast: on [PageSpeed Insights](https://pagespeed.web.dev/report?url=https%3A%2F%2Fvitepress.dev%2F), typical VitePress sites achieve near-perfect performance scores even on low-end mobile devices with a slow network.

- **Fast Post-load Navigation**

  More importantly, the SPA model leads to better user experience **after** the initial load. Subsequent navigation within the site will no longer cause a full page reload. Instead, the incoming page's content will be fetched and dynamically updated. VitePress also automatically pre-fetches page chunks for links that are within viewport. In most cases, post-load navigation will feel instant.

- **Interactivity Without Penalty**

  To be able to hydrate the dynamic Vue parts embedded inside static Markdown, each Markdown page is processed as a Vue component and compiled into JavaScript. This may sound inefficient, but the Vue compiler is smart enough to separate the static and dynamic parts, minimizing both the hydration cost and payload size. For the initial page load, the static parts are automatically eliminated from the JavaScript payload and skipped during hydration.

## What About VuePress?

VitePress is the spiritual successor of VuePress. The original VuePress was based on Vue 2 and webpack. With Vue 3 and Vite under the hood, VitePress provides significantly better DX, better production performance, a more polished default theme, and a more flexible customization API.

The API difference between VitePress and VuePress mostly lies in theming and customization. If you are using VuePress 1 with the default theme, it should be relatively straightforward to migrate to VitePress.

There has also been effort invested into VuePress 2, which also supports Vue 3 and Vite with more compatibility with VuePress 1. However, maintaining two SSGs in parallel isn't sustainable, so the Vue team has decided to focus on VitePress as the main recommended SSG in the long run.

repository: vuejs/vitepress

repo_name: vuejs/vitepress