text:
## Building an Icon Library

<!-- prettier-ignore-start -->
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
## Table of Contents

- [Introduction](#introduction)
- [Getting Started](#getting-started)
  - [Philosophy](#philosophy)
  - [Project structure](#project-structure)
    - [`package.json` scripts](#packagejson-scripts)
    - [Breaking down `tasks/build.js`](#breaking-down-tasksbuildjs)
    - [Understanding `@carbon/icon-helpers`](#understanding-carbonicon-helpers)

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

## Introduction

So you want to build an icon library for your favorite framework? That's
awesome! We're so happy to hear that 🎉 We hope that this guide can serve as a
reference to help get you up-and-running quickly so you can start using these
icons as quickly as possible.

However, before getting started, make sure that you have
[created an issue](https://github.com/IBM/carbon-elements/issues/new?labels=&template=feature_request.md)
on the Carbon Elements project and have received a green light from one of the
core contributors. This is in order to verify that the work is going to the
right place in the Carbon Elements ecosystem.

After you've received the green light, then you're ready to get started!

## Getting Started

The main package that exports all icon information is
[`@carbon/icons`](/packages/icons). This package contains all of the source SVG
assets, in addition to exporting the following assets:

- Optimized SVG assets from source files
- Icon descriptors that encode SVG information in JavaScript
- A `meta.json` file useful for individuals like yourself building an icon
  library!

If you're curious about `@carbon/icons` and want to learn more, definitely check
out our [Icon documentation](/docs/guides/icons.md)!

### Philosophy

At a high-level, each icon library should have the following design goals when
determining how to best architect their implementation:

- Given the size of the IBM Design Language icon set, each library should aim to
  support both direct imports and a tree-shakeable entrypoint
  - Direct path: `/es/icon-name/16.js`
  - Entrypoint: `/es/index.js`
  - In general, this means that we cannot support a generic
    `<Icon name="icon-name">` component given that we could not tree-shake
    `@carbon/icons` descriptors
  - A system could support `<Icon icon={descriptor} />`, however this would
    require a user to install two dependencies versus only your icon library
- Minimize the amount of runtime logic that has to be run. As a result, prefer
  generating markup statically from SVG data versus using the data at runtime to
  build up the SVG markup
- Verify that your `<svg>` containers have the right attributes by using the
  `@carbon/icon-helpers` package. This includes a helper called `getAttributes`
  that will provide the proper attributes to apply on the `<svg>` container
- Make sure that the import paths of your icons are consistent with the
  `@carbon/icons` package. This information is made available through
<EMAIL_ADDRESS>  - In other words, don't create ad-hoc direct import paths. We should try and
    stay consistent across packages

### Project structure

After following our [contribution guidelines](/.github/CONTRIBUTING.md), you
should have a local version of Carbon Elements on your own machine. In order to
add a new package to the project, you add a folder in the `packages` directory
and run `yarn init -y` to generate the `package.json` file. Make sure to edit
the `name` field in the `package.json` file and then run the following task:

```bash
yarn sync
```

This should populate your `package.json` with all the necessary information in
order to be published correctly.

Each icon library package ends up taking on the following folder structure when
everything is built:

```
icon-library-package-name
├── README.md
├── es              # Output directory for ESM
├── examples        # Examples directory for showing usage in projects
├── lib             # Output directory for CommonJS modules
├── package.json
├── src
├── tasks
│   └── build.js    # Build task for generating the icon library
└── umd             # Output directory for UMD modules
```

#### `package.json` scripts

Most icon libraries should have the following scripts available in their
`package.json`:

```json
{
  "...": "...",
  "scripts": {
    "build": "yarn clean && node tasks/build.js",
    "clean": "rimraf es lib umd"
  }
}
```

The `clean` task allows us to integrate with the global `yarn clean` command at
the workspace root. The `build` task should be run before a package is
published. In addition, exposing the `build` task will allow the workspace root
to build all application assets with `yarn build`.

#### Breaking down `tasks/build.js`

The `tasks/build.js` script structure is intentionally generic in order to allow
you to implement whatever logic is needed for your icon library. At a
high-level, the pattern for this file matches:

```js
'use strict';

const path = require('path');
const build = require('../src/build');

build({ cwd: path.resolve(__dirname, '../') }).catch((error) => {
  console.error(error);
});
```

The path to the `build` command is dependant on your implementation. The `build`
command itself should take on the following shape:

```js
'use strict';

// Reporter for logging information to the console
// Useful for `reporter.info`, `reporter.success`, `reporter.error`, etc.
const { reporter } = require('@carbon/cli-reporter');

// Meta information from the icons build process
const meta = require('@carbon/icons/meta.json');

const fs = require('fs-extra');
const path = require('path');
const rollup = require('rollup');

async function build({ cwd }) {
  // Define our bundle entrypoints for ESM, CJS, and UMD
  const ESM_DIR = path.join(cwd, 'es');
  const BUNDLE_FORMATS = [
    {
      format: 'cjs',
      directory: 'lib',
    },
    {
      format: 'umd',
      directory: 'umd',
    },
  ];

  reporter.info('Building ESM and bundle sources...');

  // Use the fan-out pattern with Promise.all to try and make these tasks run in
  // parallel
  await Promise.all(
    // `meta` is a map that provides a hash of information about the current
    // icon to build
    meta.map(async (info) => {
      // Typically, implementations will have a way to create a source module
      // from a source file and use that to write to the ESM path.
      const source = createModuleFromInfo(info);
      const jsFilepath = path.join(cwd, info.outputOptions.file);

      await fs.ensureDir(path.dirname(jsFilepath));
      await fs.writeFile(jsFilepath, source);

      // Afterwards, use BUNDLE_FORMATS and rollup to compile the ESM module to
      // CJS and UMD
      await Promise.all(
        BUNDLE_FORMATS.map(async ({ format, directory }) => {
          const bundle = await rollup({
            input: jsFilepath,
            external: ['@carbon/icon-helpers', 'prop-types', 'react'],
          });
          const outputOptions = {
            format,
            file: jsFilepath.replace(/\/es\//, `/${directory}/`),
          };
          if (format === 'umd') {
            outputOptions.name = info.moduleName;
            outputOptions.globals = {
              '@carbon/icon-helpers': 'CarbonIconHelpers',
            };
          }
          await bundle.write(outputOptions);
        })
      );
    })
  );

  // Afterwards, you should try and construct an entrypoint of all icons for
  // your library under `es/index.js`. It's important that this entrypoint is
  // tree-shakeable given the size of our library
  reporter.info('Building ESM and bundle entrypoints...');

  // You can then use `BUNDLE_FORMATS` again to generate CJS and UMD entrypoints

  // After constructing all the necessary module files, feel free to use this to
  // generate example information in the `examples` directory

  // And then we're all done!
  reporter.success('Done! 🎉');
}

module.exports = build;
```

#### Understanding `@carbon/icon-helpers`

The [`@carbon/icon-helpers`](/packages/icon-helpers) package provides a variety
of methods that help with converting icon descriptors from the `@carbon/icons`
package into DOM nodes or strings, in addition to getting the correct attributes
for the overall `<svg>` container.

You can import this helper from `@carbon/icon-helpers` by including the
following in your icon module source:

```
import { getAttributes } from '@carbon/icon-helpers';
```

At a high-level, `getAttributes` helps with setting a variety of attributes for
accessibility, like `aria-label`, in addition to browser quirks in IE11, like
the `focusable` attribute. Feel free to re-implement this logic if you feel like
it would be better suited embedded in your icon library.

repository: carbon-design-system/carbon

repo_name: carbon-design-system/carbon


text:
## GraphQL transactions and spans

**NB:** This document is not guaranteed to be final.

### Problems with our current approach

Grouping transactions by HTTP method and path fits perfectly for REST-style APIs and the like.

With a GraphQL API, the client always requests the same endpoint.
This means queries and mutations with very different costs and consequences all end up in the same transaction group.
Spans are likewise impossible to tell apart.

This document describes and explains a common approach to better support GraphQL.

Example GraphQL query:

```graphql
{
  user(id: "99") {
    name
    comments {
      body
    }
  }
}
```

Turns into an HTTP POST request like so:

```plain
POST /graphql
Content-Type: application/json

{
  "query": "query ($id: ID!) {
    user(id: $id) {
      name
      comments {
        body
      }
    }
  }",
  "variables": { "id": "99" }
}
```

**Sidenote:** The Node.js agent already supports GraphQL. This document is written with that in mind but not necessarily with its implementation as a target result.

### Transactions

#### Prefix

To distinguish GraphQL transactions from others we prefix them with `GraphQL:`.

#### Operation Name

It is common (and [recommended](https://graphql.org/learn/queries/#operation-name)) to provide an _Operation Name_ for queries. Here for example `UserWithComments`:

```graphql
query UserWithComments {
  user {
    id
    name
    comments {
      body
    }
  }
}
```

The point of these are to provide an easy way for the developers, when things go wrong, to pinpoint where exactly they did so.

This name is available on the server too and serves as a great distinguishing key.

Transaction name examples:
- `GraphQL: UserWithComments`
- `GraphQL: UpdateUser`

##### Sidenote: Multiple endpoints

The Node.js implementation adds the request path to the GraphQL span names.

We do not find serving multiple endpoints and using them with the same Operation Names likely enough to add it to this document.

#### Anonymous queries

An Operation Name isn't required. When one isn't provided it's hard for us to tell apart the queries.

We considered hashing queries to tell them apart, but decided against it.
Instead we will just consider all unnamed queries _unnamed_ and consequently put them in the same bucket.

<details>
<summary>Rationale:</summary>

1. Some clients generate `id`s from hashing the contents of the query (see [apollo-tooling](https://github.com/apollographql/apollo-tooling/blob/1dfd737eaf85b89b2cfb13913342e091e3c03d18/packages/apollo-codegen-core/src/compiler/visitors/generateOperationId.ts#L5)). This would split the anonymous queries into separate buckets.

    A problem with this approach is that a user of the APM UI has no way to recognise queries in the transactions list before clicking through.

    Using just the `id` will not reveal the true culprit since there can be variables associated with the query. Different values for the variables can lead to very different workloads and response times.

2. Another approach is to simply label them `[unnamed]`.

    A problem with _that_ approach is that the contents and thereby the relevant db queries and other sub-span actions that the server might do while resolving these queries may be wildly different making it hard to provide a _true_ sample waterfall.

    These two examples for example will look the same for the top-level GraphQL spans but will represent significantly different workloads.

    ```
    [- anonymous graphql span --------------]
      [- 1,000x SELECT * ---------------]
        [- 1,000 more SELECT * -]

    [- anonymous graphql span --------------]
      [- SELECT id FROM users WHERE id=? -]
    ```

No one of these are perfect. Because the benefits of using `id`s in the worst case could be misleading anyway, we're going with option 2.
</details>

To further help and nudge developers to use Operation Names for their queries, a tooltip will be shown in the Kibana UI, suggesting to use Operation Names.

Transaction name examples:
- `GraphQL: [unnamed]`

#### Batching/Multiplexing queries

Some clients and servers allow batching/multiplexing queries (see for example [apollo-link-batch-http](https://www.apollographql.com/docs/link/links/batch-http/#gatsby-focus-wrapper) or [dataloader](https://github.com/graphql/dataloader#batching)) allowing multiple queries to be run from the same HTTP request.

If multiple queries are run from the same request, we join their operation names in the transaction name with a `+`.

Transaction name examples:
- `GraphQL: UserWithComments+PostWithSiblings+MoreThings+[unnamed]`

To avoid very long transaction names, if a request has more than five queries, we abbreviate it to `[more-than-five-queries]`.

Transaction name examples:
- `GraphQL: [more-than-five-queries]`

### Spans

The life cycle of responding to a GraphQL query is mostly split in two parts. First, the quer(y/ies) are read, parsed and analyzed. Second, they are executed.

![Example GraphQL waterfall](https://user-images.githubusercontent.com/2163464/90007930-dfbd7b00-dc9b-11ea-8729-5d0237a0d6a4.png)

This example shows the server responding to one request, with two named queries, `SKUs` and `Names`.

As each language's server implementation can vary slightly in phases and their names, these might be named differently between agents.

GraphQL spans have the following parameters:

- `name: graphql.[action]`
- `type: "app"`
- `subtype: "graphql"`
- `action: [action]`

repository: elastic/apm

branch_name: refs/heads/main

extension: md

gha_language: Gherkin

license_type: permissive

repo_name: elastic/apm


text:
# Spigot Guides
This section lists already existing guides available at [SpigotMC](https://www.spigotmc.org).

## Contents
- [Database](#Database)
- [Environment](#Environment)
- [World](#World)

## Database
- [`Guide: DataSource and Try-with-Resources. How to Connect to your Database properly`](https://www.spigotmc.org/threads/guide-datasource-and-try-with-resources-how-to-connect-to-your-database-properly.480002/) by [Eldoria](https://www.spigotmc.org/members/eldoria.585216/) ([@RainbowDashLabs](https://github.com/RainbowDashLabs), implementation [BasicSQLPlugin](https://github.com/RainbowDashLabs/BasicSQLPlugin))

## Environment
- [`Windows - Extremely productive development environment`](https://www.spigotmc.org/threads/guide-windows-extremely-productive-development-environment.394754/) by [PiggyPiglet](https://www.spigotmc.org/members/piggypiglet.266605/)

## World
- [`Methods for changing massive amount of blocks (Up to 14M blocks/s)`](https://www.spigotmc.org/threads/methods-for-changing-massive-amount-of-blocks-up-to-14m-blocks-s.395868/) by [NascentNova](https://www.spigotmc.org/members/nascentnova.220001/)

license: MIT

repository: NyCodeGHG/spigot-plugin-resources

branch_name: refs/heads/master

gha_license_id: MIT

repo_name: NyCodeGHG/spigot-plugin-resources


text:
appengine-pullqueue-counter
===========================

A simple counter with App Engine pull queue

To deploy:
```
$ gcloud app deploy app.yaml worker.yaml queue.yaml
```

To view default service log:
```
$ gcloud app logs tail -s default
```

To view worker service log:
```
$ gcloud app logs tail -s worker
```

gha_language: Python


text:
# Alexa skill example

This skill is the proposal for Alexa Skill Contest on Alexa Day 2018.
[https://alexaday2018.jaws-ug.jp/session/207/](https://alexaday2018.jaws-ug.jp/session/207/)

## Features

- You can listen to Okinawan Japanese that called "uchina-guchi".

## Repository Contents

```
/.ask	- ASK CLI (Command Line Interface) Configuration
/lambda/custom - Back-End Logic for the Alexa Skill hosted on AWS Lambda
/models - Voice User Interface and Language Specific Interaction Models
skill.json	- Skill Manifest
```

## How to build / Tutorial

Requirement: Node.js 4.5 or greater and Node Package Manager.

Preparing SDK.

```
$ npm install --save alexa-sdk
$ npm install -g ask-cli
$ ask init
```

Create skill.

(Notice: This command creates skill name's directory. If already exists, fail to create skill project.)

```
$ ask new -p default
```

detail: see [https://developer.amazon.com/ja/docs/smapi/ask-cli-command-reference.html#new-command](https://developer.amazon.com/ja/docs/smapi/ask-cli-command-reference.html#new-command)

Okay, you can write your code and deploy your skill!

Your lambda function is here.

```
./lambda/custom/index.js
```

Please check some details via [https://github.com/alexa/skill-sample-nodejs-fact](https://github.com/alexa/skill-sample-nodejs-fact)

Deploy skill.

```
$ ask deploy -p default
```

You can check your skill via developer console. see [https://developer.amazon.com/](https://developer.amazon.com/)

## Author

[Koichiro Nishijima](https://github.com/k-nishijima/)

## License

MIT

repository: k-nishijima/uchina-guchi-skill

gha_language: JavaScript

repo_name: k-nishijima/uchina-guchi-skill


text:
# vertx3-spock-example

Show use of spock to do async testing with vertx3

There's no gradle wrapper.  Known to work with gradle 2.7

The idea is to test vertx java or groovy code with Spock's async capability -- no need for the Vertx test package.  But this is a trivial example so far.

Spock test reports will be in `build/reports/test`

## todo

* Port more of the official Vertx test examples to spock.
* Show tests of both java and groovy code under test.


text:
# An Introduction to Disk Partitions 硬盘分区介绍

*ps: 来自 Fedora 21 官方文档 `Installation Guide` 附录Ｂ*

**个人翻译供学习用，版权归Fedora所有。因中国大陆的网络问题，暂无法提交到 `Fedora  Documentation` 项目。 -- ssbunny**

> This appendix is not necessarily applicable to architectures other than AMD64 and Intel 64. However, the general concepts mentioned here may apply.

> 该附录不仅适用于 AMD64 或 Intel64 系统。这里提到的一般性概念通常可以通用。

This section discusses basic disk concepts,
disk repartitioning　strategies,
the partition naming scheme　used　by Linux systems, and related topics.

该部分讨论了磁盘的基本概念、磁盘重分区策略、Linux系统分区命名方案及相关主题。

If you are comfortable with disk partitions,
you can skip ahead to　Section 2,　“Strategies for　Disk　Repartitioning” for more information on the process of freeing up disk space to prepare for a Fedora　installation.

如果你对磁盘分区感兴趣，可以直接跳至第2小节《磁盘重新分区策略》，
以便了解更多关于Fedora安装时释放磁盘空间的过程。

## 1.Hard Disk Basic Concepts 硬盘的基本概念

Hard disks perform a very simple function - they store data and reliably retrieve it on command.

硬盘的功能非常简单——它们被用来存储数据并可以通过命令可靠地检索到这些数据。

When discussing issues such as disk partitioning,
it is important to have a understanding of the　underlying hardware;
however, since the　theory is very complicated and expansive,
only the basic　concepts will be explained here.
This appendix uses a set of simplified diagrams of a disk drive to help explain what is the process and theory behind partitions.

当讨论磁盘分区时，对其底层硬件有个基本理解是非常重要的。然而由于这部分理论十分复杂且宽泛，在此只会解释一些基础概念。该附录通过一组简易的磁盘驱动器图表解释了分区背后的过程和理论。

Figure 1, “An Unused Disk Drive”, shows a brand-new, unused disk drive.

图1　"未使用的磁盘驱动器"展示了一个全新的、未使用的磁盘驱动器。

![An Unused Disk Drive](img/disk_partition_1.png)

Figure 1　An Unused Disk Drive

图1 未使用的磁盘驱动器

### 1.1. File Systems　文件系统

To store data on a disk drive,　it is necessary to format the disk drive　first. Formatting (usually known　as "making a file system") writes information to the drive, creating order out of the empty space in an　unformatted drive.

若想在磁盘驱动器上存储数据，必需先进行格式化。格式化(通过被当作"制作文件系统")会往驱动器上写入一些规则信息，这些规则信息创建在未格式化的空闲驱动器上。

![Disk Drive with a File System](img/disk_partition_2.png)

Figure 2. Disk Drive with a File System

图2 带有文件系统的磁盘驱动器

As Figure 2, “Disk Drive with a File System”, implies, the order imposed by a file system involves some trade-offs:

图2 "带有文件系统的磁盘驱动器", 显示了文件系统规则包含的权衡：

* A small percentage of the driver's available space is used to store file system-related data and can be considered as overhead.
* 磁盘驱动器的可用空间中，有一小部分被用来存放系统相关的数据文件。
* A file system splits the remaining space into small, consistently-sized segments. For Linux, these segments are known as blocks.
* 文件系统会将剩余空间切分成大小一致的小片段。在Linux中，这些片段被称为 `块` 。

Note that there is no single, universal file system. As Figure 3, “Disk Drive with a Different File System”, shows, a disk drive may have one of many different file systems written on it. Different
file systems tend to be incompatible; that is, an operating system that supports one file system (or a handful of related file system types) may not support another. However, Fedora supports a wide
variety of file systems (including many commonly used by other operating systems such as Microsoft Windows), making data interchange between different file systems easy.

要知道，并没有单一通用的文件系统。像图3 “装有不同文件系统的磁盘驱动器”中展示的那样，一个磁盘驱动器中可以写入多个不同的文件系统。不同的文件系统往往是不相兼容的；换句话说，支持一种文件系统(或少量相关文件系统类型)的操作系统通常不支持另一种文件系统。然而，Fedora支持多种类型的文件系统(包括许多在其它操作系统,如微软Windows下使用的),使得不同文件系统间的数据交换十分容易。

![Disk Drive with a Different File System](img/disk_partition_3.png)

Figure 3. Disk Drive with a Different File System

图3 装有不同文件系统的磁盘驱动器

Writing a file system to disk is only the first step. The goal of this process is to actually store and retrieve data. The figure below shows a drive disk after some data have been written to it:

将文件系统写入磁盘仅仅是第一步。这一过程的目的是实际存储及数据检索。下图展示了已经写入数据的磁盘驱动器：

![Disk Drive with Data Written to It](img/disk_partition_4.png)

Figure 4. Disk Drive with Data Written to It

图4 写入数据的磁盘驱动器

As Figure 4, “Disk Drive with Data Written to It”, shows, some of the previously-empty blocks are now holding data. However, by just looking at this picture, we cannot determine exactly how many files
reside on this drive. There may only be one file or many, as all files use at least one block and some files use multiple blocks. Another important point to note is that the used blocks do not have to form a contiguous region; used and unused blocks may be interspersed. This is known as fragmentation.Fragmentation can play a part when attempting to resize an existing partition.

在图4中，先前的一些空块被放入了数据，但是仅通过看图，我们并不能判断出到底有多少文件位于此驱动器上，也许是一个文件，也可能是很多文件，因为任何文件至少会占用一个块当然也可能更多的块。另一个值得注意的要点是，已使用的块并不必是连续的区域，使用的、未使用的块可以穿插出现，这被称为 `碎片` 。碎片在调整现有分区时会产生影响。

As with most computer-related technologies, disk drives changed over time after their introduction. In particular, they got bigger. Not larger in physical size, but bigger in their capacity to store information. And, this additional capacity drove a fundamental change in the way disk drives were used.

和大多数计算机相关技术一样，磁盘驱动器技术自诞生之日起曾发生多次变化。特别是，它们变得越来越大。并不是说它们的实际尺寸在变大，而是存储信息的容量变的越来越大。同时，多出来的容量也给磁盘驱动器的使用方式带来了根本性的变革。

### 1.2. Partitions: Turning One Drive Into Many 分区：将一个驱动器划分为多个

Disk drives can be divided into partitions. Each partition can be accessed as if it was a separate disk. This is done through the addition of a partition table.

磁盘驱动器可以划分成多个 `分区` ，每个分区均可以被当作独立的磁盘访问。分区操作通过磁盘分区表完成。

There are several reasons for allocating disk space into separate disk partitions, for example:

有很多将磁盘空间分成独立的磁盘分区的原因，例如：

* Logical separation of the operating system data from the user data
* 实现操作系统数据和用户数据的逻辑分离
* Ability to use different file systems
* 提供使用不同文件系统的能力
* Ability to run multiple operating systems on one machine
* 提供在一台机器上运行多个操作系统的能力

There are currently two partitioning layout standards for physical hard disks: Master Boot Record (MBR) and GUID Partition Table (GPT). MBR is an older method of disk partitioning used with BIOS-based computers. GPT is a newer partitioning layout that is a part of the Unified Extensible Firmware Interface (UEFI). This section and Section B.1.3, “Partitions Within Partitions - An Overview of Extended Partitions” mainly describe the Master Boot Record (MBR) disk partitioning scheme. For information about the GUID Partition Table (GPT) partitioning layout, see Section B.1.4, “GUID Partition Table (GPT)”.

目前有两种硬盘分区配置标准：主引导记录(Master Boot Record, MBR)和 GUID 分区表(GUID Partition Table, GPT). MBR是基于BIOS的电脑的一种老的分区方法，而GPT是一种新的分区方法，它是统一可扩展固件接口(UEFI)的一部分。该小节以及1.3小节主要描述 MBR 分区模式。关于 GPT 分区，参见第1.4小节。

> While the diagrams in this chapter show the partition table as being
> separate from the actual disk drive, this is not entirely accurate.
> In reality, the partition table is stored at the very start of the disk,
> before any file system or user data. But for clarity,
> they are separate in our diagrams.

> 由于本章中的图表展示的分区表和实际的磁盘驱动器是分离的，因此并不完全准确。事实上，
> 分区表存储在磁盘的始端，位于任何文件系统或用户数据之前，但为了清晰起见，
> 在我们的图表中将其分离出来。

![Disk Drive with Partition Table](img/disk_partition_5.png)

Figure 5. Disk Drive with Partition Table

图5 带有分区表的磁盘驱动器

As Figure 5, “Disk Drive with Partition Table” shows, the partition table is divided into four sections or four primary partitions. A primary partition is a partition on a hard drive that can contain only one logical drive (or section). Each section can hold the information necessary to define a single partition, meaning that the partition table can define no more than four partitions.

图5 展示出分区表分成四部分或者说四个主分区。主分区是这样一种硬盘分区，它只能包含一个逻辑驱动器(或一部分)，每部分持有其所需信息以定义独立的分区，这意味着分区表最多可定义四个分区。

Each partition table entry contains several important characteristics of the partition:

• The points on the disk where the partition starts and ends
• Whether the partition is "active"
• The partition's type

repository: ssbunny/my-notes

repo_name: ssbunny/my-notes


text:
---
title: How to Setup a Bitcoin Node
templateKey: guide-post
type: node-setup
date: "2015-05-01T22:12:03.284Z"
dateModified: "2015-05-01T22:12:03.284Z"
excerpt: This is the first step when getting started with Bitcoin. Setup your own node to begin interacting with the network.
description: Tutorial on how to setup, configure, and run a bitcoin core node. Explains details needed to get started on the bitcoin network.
tags:
  - Node Setup
  - Bitcoin
featuredImage: ./006-online money.png
twitterImage: ./twitter_image.jpg
---

**Bitcoin Core** is an application that can be run on **Windows**, **Mac**, and **Linux**.

The application itself is <20 mb, however additional block data _will need to be downloaded_ to run a node.

## Install

*Download* and *install* **Bitcoin** from [bitcoin.org](https://bitcoin.org/en/download).

Installing Bitcoin won't begin downloading block data. You will need to start the application first, which we will do shortly.

## Node Options

Before starting Bitcoin Core, decide whether you want to use **mainnet** or **testnet** and if you want to run a **full** or **pruned** node.

| Node Type           | Size Requirements | Approximate Sync Time |
| :------------------ | :---------------- | :-------------------- |
| Full Mainnet Node   | **`>320 gb`**       | 3-5 days              |
| Full Testnet Node   | **`~30 gb`**    | Less than 1 day       |
| Pruned Mainnet Node | **`>577 mb`**    | 3-5 days              |
| Pruned Testnet Node | **`>577 mb`**    | Less than 1 day       |
| Regtest Node        | **`<100 mb`**  | Immediately           |

### Mainnet, Testnet, or Regtest

**Mainnet** (default) is the actual bitcoin network. This option takes the longest to sync, and requires at least **320 gb** to store the full blockchain.

**Testnet** is the bitcoin test network. **tBTC** have no value and can be acquired from various [testnet faucets](https://testnet-faucet.mempool.co/) for free. The current testnet blockchain is around **30gb** in size. The testnet blockchain mines blocks faster and occasionally resets (currently on the 3rd blockchain).

**Regtest** (regression testing) allows the user to start from the first block on a new local test blockchain. Blocks can be generated with the **generate** command.

Learn more about [Mainnet, Testnet, and Regtest](http://localhost:8000/mainnet-testnet-and-regtest-modes/) modes.

### Full or Pruned Node
By default, bitcoin will download and store every block in the blockchain on your computer. If you *don't have enough* storage space for a **full node**, use the **prune** setting. This will allow you to specify how much storage space to allow for blocks, and bitcoin will automatically delete blocks older than that amount.

Learn more about [Full vs Pruned Bitcoin Nodes](http://localhost:8000/mainnet-testnet-and-regtest-modes/).

## Configuring Bitcoin Core

Unless you want to run bitcoin with the default settings, create a `bitcoin.conf` file in your recently installed `Bitcoin/` folder where you can specify various options.

Each **configuration option**, on it's own line, is a *property name* set equal to *a value*. There are default values already set for many options.

Using a **#** sign at the start of a line indicates that line is a **comment**, which won't be included in the configuration.

Here is an example `bitcoin.conf` file with some common configuration options:

bitcoin.conf

```bash
prune=5500
# Sets pruned mode, amount in MiB (minimum is 5500 or ~577mb)

testnet=1
# Starts Node in testnet (default is 0)

regtest=0
# Starts Node in regtest (default is 0)

txindex=1
# Indexes all transactions on the blockchain (default is 0)
```

The most important options to consider when first setting up a node are: whether you want to use **testnet** or **regtest** mode instead of mainnet, if you want to **prune** your blockchain instead of store all blocks, and whether you want to index transactions with **txindex**.

### Transaction Indexing

If you want to be able to lookup any transaction on testnet or mainnet, make sure to include the `txindex=1` option so that Bitcoin Core indexes your transactions as you download them. Otherwise, you will only be able to view transactions pertinent to your wallet and mempool transactions.

Transaction indexing can take up *approximately 10%* of the blockchain size additionally but is useful for developing applications like a block explorer.

## Starting Bitcoin

There are two options for running bitcoin core: **bitcoind** (the daemon) or **bitcoin-qt** (the wallet GUI).

If you are new to Bitcoin Core, the GUI is a great option to get familiar with the software. The daemon is useful for building applications and using the CLI for commands.

For both options we will be specifying the `datadir` startup command to our `Bitcoin` directory. This will ensure our blocks are stored in the right folder and our correct configuration is used. Feel free to omit this option if you're running a full mainnet node and don't care where your blocks get stored.

### Bitcoin-qt

To open the **wallet GUI**, enter the following command from your `Bitcoin` folder in the terminal

```bash
bitcoin-qt -datadir=C:\Bitcoin
```

This will start Bitcoin QT using the `bitcoin.conf` in your `Bitcoin/` folder.

### Bitcoind

To start the **daemon**, enter the following command from your `Bitcoin/daemon` folder in the terminal

```bash
bitcoind -datadir=C:\Bitcoin
```

This will start the daemon using the `bitcoin.conf` in your `Bitcoin/` folder.

Bitcoin will automatically start downloading blocks based on which configuration you specified.

## Syncing the Blockchain

If this is your first time starting Bitcoin Core, your node will need to download and verify all of the blocks. This can take *several hours* on **testnet** and a *few days* on **mainnet**. If you decide to run a pruned node, your software will still need to download and verify all the same data. A pruned node will discard any older blocks past the specified size (577 mb in the example).

Once the blockchain is synced, you are successfully running a node on the bitcoin network!

repository: peterdurham/node-update-site

repo_name: peterdurham/node-update-site


text:
# ShapefileReader
__A shapefile reader in Swift__

__Description__

Reads data from files in [Shapefile](https://en.wikipedia.org/wiki/Shapefile) format.

__API Overview__

ShapefileReader is the only object you instantiate.

```swift
guard let sr = ShapefileReader(path: "g1g15.shp") else { assertionFailure() }

print("bbox: \(sr.shp.bbox)")
```

    bbox:<PHONE_NUMBER>99999, 75286.5438000001, 833837.895,<PHONE_NUMBER>00002)

Internally, it builds the three following objects, depending on the available auxiliary files:
- `SHPReader` to read the shapes, ie the list of points
- `DBFReader` to read the data records associated with the shapes
- `SHXReader` to read the indices of the shapes, thus allowing direct access

```swift
// if dbf file exists
if let dbf = sr.dbf {
    // number of records
    let n = dbf.numberOfRecords

    // iterate over records
    for r in dbf.recordGenerator() {
        // ...
    }

    // access a record by its index
    print(dbf.fields)
    let r = dbf[1847]
    print(r)
}
```

    [[DeletionFlag, C, 1, 0], [GMDNR, N, 9, 0], [GMDNAME, C, 50, 0], [BZNR, N, 9, 0], [KTNR, N, 9, 0], [GRNR, N, 9, 0], [AREA_HA, N, 9, 0], [X_MIN, N, 9, 0], [X_MAX, N, 9, 0], [Y_MIN, N, 9, 0], [Y_MAX, N, 9, 0], [X_CNTR, N, 9, 0], [Y_CNTR, N, 9, 0], [Z_MIN, N, 9, 0], [Z_MAX, N, 9, 0], [Z_AVG, N, 9, 0], [Z_MED, N, 9, 0], [Z_CNTR, N, 9, 0]]
    [5586, Lausanne, 2225, 22, 1, 4138, 534438, 544978, 150655, 161554, 538200, 152400, 371, 930, 670, 666, 585]

```swift
// iterate over shapes
for (i,s) in sr.shp.shapeGenerator().enumerate() {
    print("[\(i)] \(s.shapeType), \(s.points.count) points, \(s.parts.count) part(s), bbox \(s.bbox)")
}
```

    [0] Polygon, 15 points, 1 part(s), bbox (678122.18,<PHONE_NUMBER>00001, 681154.07,<PHONE_NUMBER>00001)
    [1] Polygon, 19 points, 1 part(s), bbox<PHONE_NUMBER>00001, 235223.84,<PHONE_NUMBER>99999,<PHONE_NUMBER>99999)
    [2] Polygon, 11 points, 1 part(s), bbox<PHONE_NUMBER>, 238997.66,<PHONE_NUMBER>00001,<PHONE_NUMBER>99998)

```swift
// if index file exists
if let shx = sr.shx {
    // access a shape by its index
    if let shape = sr[1847] {
        print(shape.shapeType)
        print(shape.points)
    }
}
```

    Polygon
    [(536987.156300001,<PHONE_NUMBER>99999),<PHONE_NUMBER>00001,<PHONE_NUMBER>99999),<PHONE_NUMBER>00001, 158915.75), ..., ]

```swift
// iterate over both shapes and records in the same time
for (s,r) in sr.shapeRecordGenerator() {
    //
}
```

__Implementation Details__

- points are CGPoint arrays
- direct access and enumerators are used each time it is possible
- the code will crash when it doesn't find the expected data

__Tests and Drawing__

The project comes with a unit test target.

Also, it comes with `BitmapCanvas` and its subclass `BitmapCanvasShapefile` which will generate the following PNG file.

You just need to change the path at the beginning of the `draw()` function in `main.swift` according the project's location.

repository: kerasking/ShapefileReader

repo_name: kerasking/ShapefileReader


text:
Mikrotik queue speed limits
==========

Queues for speed limitations on the Mikrotik RoutersOS can be created by Splynx using API.

To set this up, Mikrotik API should be enabled on the router and in Splynx router settings. To create a Simple queue rule we have to enable Shaping on the router in settings and set the Shaping type to "Simple queue".

The Configuration is shown on the image below:

![Mikrotik settings](static_IP_API.png)

![IP Service List](ipsrv_list.png)

When both things are enabled, it is necessary to create a special admin account for Splynx, which will be used for API login to routers and for making changes to the router. You can create an admin named API or with another name and assign the admin to a special access group for API login:

![Add Group](group.png)
![Add API User](user.png)

To create rules on the router, the router should be selected in the service of the customer. Please note that API queuing only works with permanent/static IP address assignments:

![Edit service](edit_service.png)

After saving these settings, a simple queue for the customer will be added to the router:

![Simple queue](simple_queue.png)

If a FUP rule is applied, the queue speeds will be updated via API, automatically.

### Simple Queue tree shaping

The Simple queue type of shaping does not provide a way to put customers under one shared plan or to create contentions per router.

To successfully setup contentions, we need to change the Shaping type to "Simple Queue (with Tree)".

![Simple queue tree](simple_queue_tree.png)

Then Splynx will create a tree design of queues, where tariff plan queues are always the Parent for client's queues:

![Queue list](simple_queue_mt.png)

If we apply per router contentions, the first step is to define the router max. speed for upload and download:

![Contention](simple_contention.png)

Then choose the router contention on the Internet service:

![Sector](sector.png)

After saving these settings, Splynx will push the rules to router:

\* Please **don't combine** router contentions with Plan contetions, this will overcomplicate the queue setup and the Mikrotik will not handle this well.

### PCQ shaping

Versions before Mikrotik RouterOS v.6, simple queues were not optimized and that is why one of the popular solutions for shaping was PCQ shaping, using address-list. To enable this type of shaping in Splynx, change the shaping type in Splynx router settings to "PCQ (Address-List)":

![PCQ](pcq.png)

Please note, in PCQ shaping, contentions and FUP policies do not work.

![PCQ](PCQ_1.png)
![PCQ](PCQ_2.png)

### Double queues issue

If you have Radius and API queues enabled, Splynx will create two queues - one via API and the other by the Radius server via attributes. This is not correct and one of the queues should be removed.

You can disable the API queue and leave automatic Radius queues enabled, or if you want to use API queues, then under `Config → Networking → Radius` (NAS Config (MikroTik), then click on `Load` → MikroTik Configuration) you can simply remove rate-limit attributes and the Radius server will not create automatic queues when the customer connects their device. Simply delete the lines `Mikrotik-Rate-Limit = {{ }}` in Rate-limit attributes, COA attributes and FUP attributes:

![Rate limit](remove_ratelimit.png)

For more information on the different bandwidth management options, please read the following tutorials: [FUP bandwidth management](networking/bandwidth_management/fup/fup.md) and [contentions in Splynx](networking/bandwidth_management/contentions/contentions.md).

repository: splynx/docs

repo_name: splynx/docs


text:
(whats-new-anchor)=
# What's new?

Upcoming...  **September 20, 2023 16:00 CEST**: **INCF Workshop on HED and BIDS**
> Event annotation in neuroimaging using HED: from experiment to analysis
> Half-day workshop at [**INCF Assembly 2023**](https://neuroinformatics.incf.org/register).
> Speakers: Scott Makeig, Dung Truong, Dora Hermes, and Monique Dennisen.

**August 21, 2023**: **INCF 2022 HED workshop videos available**
> [**Part 1: Documenting temporal structure** (48:04)](https://youtu.be/cCp314DXMos)
> [**Part 2: Annotating a BIDS dataset** (59:58)](https://youtu.be/BBiGNMyY3x8)
> [**Part 3: EEG annotation with HED** (22:50)](https://youtu.be/9MRXw5YMHJk)
> [**Part 4: HED and fMRI** (30:00)](https://youtu.be/QsYWi0mMLT4)
> [**Part 5: HED for clinical annotation** (18:51)](https://youtu.be/dmNxVWaduEE)

**August 2, 2023**: **HED has a mailing list/discussion forum**
> The HED mailing list/discussion forum is managed via googlegroups.
> To join email: [**hed-discussion+subscribe@googlegroups.com**](mailto:hed-discussion+subscribe@googlegroups.com).

**July 12, 2023**: **HED SCORE version 1.1.0 released**
> This is the first HED partnered schema.

**July 5, 2023**: **HEDTools version 0.3.1 released**
> [**HEDTools**](https://pypi.org/project/hedtools/) version 0.3.1 has been released on PyPI.
> See also [**hed-python**](https://github.com/hed-standard/hed-python) on GitHub.
> This patch includes improvement to models exception handling, minor bug fixes, and improvement of format for JSON format of remodeling summaries.

**June 20, 2023**: **HEDTools version 0.3.0 released**
> [**HEDTools**](https://pypi.org/project/hedtools/) version 0.3.0 has been released on PyPI.
> See also [**hed-python**](https://github.com/hed-standard/hed-python) on GitHub.
> This version uses the new DataFrame implementation of the models for improved efficiency.

**June 14, 2023**: **HED brain initiative meeting video poster online.**
> [**HED video poster**](https://brainmeeting2023.ipostersessions.com/?s=DA-51-73-83-1B-EA-B8-0A-CB-8F-41-BD-78-CD-68-D2) available until June 2024:
> *HED: Annotation standards and software infrastructure to enable sharing of analysis-reading neuroimaging and behavior data*
> Presented as part of the [**Brain Initiative Meeting 2023**](https://brainmeeting.swoogo.com/2023/begin?i=SChfLW2xODsF7JgaKhJT1nJAhf5QcbGi).

**June 2, 2023**: **HED online tools have a new look.**
> The HED online tools at [**https://hedtools.ucsd.edu/hed**](https://hedtools.ucsd.edu/hed) have been redesigned and streamlined.

**May 12, 2023**: **Version 3.2.0 of the HED specification released.**
> [**Version 3.2.0**](https://doi.org/10.5281/zenodo.7869149) of the HED specification
introduces the `Inset` tag as well as partnered and rooted library schemas.
> This version is the first to support the curly brace notation in sidecars.

**April 28, 2023**: **HED standard schema v8.2.0 released.**
> The [**HED schema v8.2.0**](https://doi.org/10.5281/zenodo.7876037) has just
been released. This release supports the `Inset` tag for annotating intermediate
points in an ongoing event as well as partnered library schemas.

**April 25, 2023**: **HED playlist goes live on YouTube.**
> The [**Hierarchical Event Descriptor**](https://www.youtube.com/playlist?list=PLeII6cRFsP6L5S6icwRrJp0DHkhOHtbp-) playlist is now available on YouTube. A 5-part short-course on HED (from OHBM 2022) has just been released.

**April 6, 2023**: **Version 3.1.0 of the HED specification released.**
> [**Version 3.1.0**](https://hed-specification.readthedocs.io/en/stable/) of the HED specification clarifies existing features.
>
> HED validators will be able to link error messages directly to descriptions in the spec.

**April 3, 2023**: **New versions of HED schema browser available.**
> You can now use the [**HED Schema Viewer**](https://www.hedtags.org/display_hed.html) to view both standard and library schemas.

**March 28, 2023**: **Release of HED Javascript validator for BIDS v3.9.0 on npm**
> The new version supports checking of onsets and offsets.

**March 27, 2023**: **HED Workshop at CNS 2023**
> **Title:** *Recording what happened during your experiment using Hierarchical Event Descriptors (HED)*
> **Presenter**: [**Scott Makeig**](https://sccn.ucsd.edu/~scott/) UCSD and assisted by members of the HED Working Group.
> **Time and location:** 12:15-1:15 pm Seacliff Room  Hyatt Regency San Francisco Hotel.

**March 24, 2023**: **HED is now on Twitter**
> Follow us at @HedDescriptors

**March 22-23, 2023**: **HED at the 2023 Annual Assembly of the Global Brain Consortium**

> Directions in EEG data-sharing - panel co-chaired by Kay Robbins and Dora Hermes
> [**Program and Registration**](https://globalbrainconsortium.org/documents/GBC_March-2023_Agenda_Annual_Meeting.pdf)

**Feb 28, 2023**: **INCF Software Highlight on HED**
> **Title:** *HED, a practical system for describing an experiment using an analysis-ready framework*
> **Presenter:** [**Kay Robbins**](https://www.utsa.edu/sciences/computer-science/faculty/KayRobbins.html) UTSA,
> member of the HED Working Group.
> [**Abstract**](https://ocns.github.io/SoftwareWG/2023/02/17/software-highlight-kay-robbins-hed.html).

**February 22, 2023**: **HED YouTube Channel goes live**

> First video:  [**HED Tagging 101**](https://youtu.be/iRAWO-Fn6Bw)
> HED YouTube channel: [**https://www.youtube.com/@hedworkinggroup/videos**](https://www.youtube.com/@hedworkinggroup/videos)

**February 14, 2023**: **HEDTools 0.2.0 is released.**
- This release includes the HED remodeling tools.
- Improved local caching and schema validation messages are included.
- This is the first release with distinct `stable`, `master`, and `develop` branches.

**January 28, 2023**: **HED SCORE Library v1.0.0 released**

> The HED score library schema v1.0.0 has been officially released.
> This library is based on the Standardized Computer-based Organized Reporting of EEG
> ([**SCORE**](https://pubmed.ncbi.nlm.nih.gov/28838815/)) standard and adapted for
> annotation using the HED infrastructure and requirements.
> For more information see the [**SCORE schema library**](https://hed-schemas.readthedocs.io/en/latest/hed_score_library.html) guide.

**January 20, 2023**: **New preprint available**

> **Actionable event annotation and analysis in fMRI** [**preprint**](https://osf.io/h7puk)

> *Monique Denissen*, *Fabio Richlan*, *Jürgen Birkibauer*, *Mateusz Pawlik*, *Anna Ravenschlag*, *Nicole Himmelstoß*, *Florian Hutzler*, *Kay Robbins*

> Supporting materials and data are available at [**https://osf.io/93km8/**](https://osf.io/93km8/).

> Chapter to appear in the book *Methods for analyzing large neuroimaging datasets*
edited by Robert Whelan and Herve Lemaitre.

**January 4, 2023**: **New preprint available**

> **End-to-end processing of M/EEG data with BIDS, HED, and EEGLAB** [**preprint**](https://osf.io/h7puk)

> *Dung Truong*, *Kay Robbins*, *Arnaud Delorme*, and *Scott Makeig*

> Supporting materials and data are available at [**https://osf.io/8brgv/**](https://osf.io/8brgv/).

> Chapter to appear in the book *Methods for analyzing large neuroimaging datasets*
edited by Robert Whelan and Herve Lemaitre.

**January 3, 2023**: **Project page live**

>New HED organization homepage goes live at [**https://www.hedtags.org**](https://www.hedtags.org).

repository: hed-standard/hed-examples

gha_language: Jupyter Notebook

repo_name: hed-standard/hed-examples


text:
bgclass: forcompanies-bg
headline: Better employee engagement through charitable giving

# SoGive for Enterprise

Working with SoGive, you can easily setup donation and Corporate Social Responsibility (CSR) schemes that employees love.

* Give employees a powerful reason to believe in the company: The good you do in the world.
* Put the power in the hands of your employees by giving them the decision about where the donation goes.
* By using SoGive's specialist impact database and insights, the software can support donors to make high-impact decisions
* SoGive can show the donor how much of the charity’s impact is attributable to each donation, courtesy of our unique database.
* Turn employees into advocates on social media. SoGive's approach encourages sharing.
* Easily demonstrate value with impact-based reporting.
* Benefit from our research into effective charities to achieve greater impact.

We support a range of charity schemes:

* [Payroll giving](forpayrollgiving): A tax efficient way for your employees to give.
* Matched-funding: The company boosts an employee's donations, building loyalty.
* Charity gifts: The company provides employees with funding to give to charity.

Care about what your employees care about. Do good. Have impact.

repository: winterstein/SoGive

gha_language: HTML

gha_license_id: NOASSERTION

repo_name: winterstein/SoGive


text:
# C Simple Small-C Compiler

An implementation of an Small-C compiler for the Compiler course.

## Grammar
The grammar accepted by the compiler is on the repository with the source code. [[here](https://github.com/elvishribeiro/SmallC-Compiler/tree/master/Csmall)]

## Building
To compile just type the following

```Shell
$ make
```

## Running
Running is as simple as building
```Shell
$ ./main arg
```
- `arg` can be either a file or a path. In the case of a path the compiler will compile all the .c files in there

## License
This project was made by Elvis Ribeiro and released by under the GPLv3.

repository: elvishribeiro/SmallC-Compiler

repo_name: elvishribeiro/SmallC-Compiler


text:
---
type: "Details"
language: "EN"
composer: "Four Aces Guitar Quartet"
title: "Menno Buggenhout, Inti De Maet, Maarten Vandenbemden, Stein Verrelst"
index: 4
---
Classical guitar won't get more fancy than with the Four Aces
Guitar Quartet. Eight years after their debut these four well
dressed hot shots have outgrown their flemish roots. Especially
their second cd Odyssee was a big succes, even in China. Whilst
Bart, Inti, Menno and Stein are now leaving the Odyssee behind,
they are eagerly exploring new, unknown territories. On their
newest album For Aces you'll only find compositions written
especially for them.
The quartet was born in the summer of 2008 during the
International Guitar Symposium in Iserlohn, where they first met.
Their first gig was part of a final project at the conservatory of
Antwerp. The audience and he jury were immediately impressed
with the virtuosity and musical colours the four managed to
present.
Afterwards the Four Aces Guitar Quartet played concerts in major
halls in Belgium. Abroad they performed in the Netherlands,
Germany, France, Slovenia, Italy, Georgia and China. The quartet
also appeared in live broadcasting shows on the Dutch station
Radio 4, on the Belgian tv-channel Canvas and on Belgian classical
radio Klara.

In 2013 the Four Aces Guitar Quartet returned to Iserlohn, but
now to give masterclasses during the Guitar Symposium. That
same year they won Supernova, a Belgian chamber music
competition that is supported by the national radio and tv-
channel, as well as the Flemish government and numerous
cultural partners.
As a quartet Bart, Inti, Menno and Stein continued looking for
perfection by taking masterclasses with some of the most famous
guitarists of the planet. To name a few: Aniello Desiderio, the
Katona Twins, David Russel and Johan Fostier. One of their
highlights so far remains the common concert with Grammy
award winner Andrew York, who also is one of the founding
members of the Los Angeles Guitar Quartet.
In 2013 the ensemble won Supernova, a Belgian chamber music
competition organised by national television and radio, the
Belgian government and many cultural partners across the
country. In 2017 the quartet won the international chamber
music competition ‘Paola Ruminelli’ in Ossola (Italy)

Four Aces Guitar Quartet is:
Menno Buggenhout, Inti De Maet, Maarten Vandenbemden,
Stein Verrelst.

repository: Boomstam/FourAces

repo_name: Boomstam/FourAces


text:
### Goals
- The trainee should know how to effectively search for information
- The trainee **must** learn to follow manuals and orders
- The trainee should learn shortcuts, signs and expressions for Google manipulation

### Tasks
- Read about the term RTFM
  - Take that lesson to heart
  - Remeber this lesson and follow it
  - When you think you are donr with this lesson, talk to your instructor to get a sticker.
- Use the following signs in searches and say what they do:
  - `-word`
  - `"word"`
  - `word:nameOfSite`
  - `word1 OR word2`
  - `word1 AND word2`

license: Unlicense

gha_license_id: Unlicense


text:
# Homebridge Logitech Circle Controls

This is a Homebridge plugin that exposes extended controls for Logitech Circle cameras, such as toggles for privacy mode, camera on/off, and LED on/off.

This plugin only works with older cameras using Logitech's web service, not newer cameras based on HomeKit Secure Video.

## ⚠ Project in Maintenance Mode ⚠

**This project is in maintenance mode and will only receive bug fixes (if I can even do that). No new features are planned.**

My Logi Circle stopped working so I'm not able to use this plugin anymore, which makes new feature development very difficult! 😅

## Install

```
npm i -g homebridge-logi-circle-controls
```

### Minimum Requirements

- Node v12+
- Homebridge v1.3+

## Log In

Run the included command line tool to log into your Logitech account:

```
homebridge-logi-circle-controls login
```

Use the `-h` option to get additional help.

Refer to the ["How to Log In" wiki page](https://github.com/klanchman/homebridge-logi-circle-controls/wiki/How-to-Log-In) for more detailed information about how to complete the process.

### Homebridge Configuration Path

The tool expects that your Homebridge `config.json` is located in `~/.homebridge`.

If this is not the case (e.g. Synology, Docker, etc.), use the `-d` option to specify the directory where your `config.json` is located:

```
homebridge-logi-circle-controls login -d /path/to/homebridge/config/dir
```

## Configure

In your Homebridge `config.json` file, add a new entry in `platforms` that looks like this:

```jsonc
{
  "platform": "Logi Circle Controls",

  /* Optional: overrides for names of accessories the platform provides */
  "nameOverrides": {
    "camera": "<Optional: the desired name of the camera switch | Default: 'Camera'>",
    "led": "<Optional: the desired name of the LED switch | Default: 'LED'>",
    "recording": "<Optional: the desired name of the recording switch | Default: 'Recording'>",
    "nightVisionMode": "<Optional: the desired name of the night vision mode switch | Default: 'Night Vision'>",
    "nightVisionIR": "<Optional: the desired name of the night vision IR switch | Default: 'Night IR'>"
  }
}
```

gha_language: TypeScript


text:
# LAB - Component Lifecycle / `useEffect()` Hook

**RESTy Phase 3:** Connect RESTy with APIs, running live requests

## Before you begin

Refer to *Getting Started*  in the [lab submission instructions](../../../reference/submission-instructions/labs/README.md) for complete setup, configuration, deployment, and submission instructions.

> Continue working in your 'resty' repository, in a branch called 'effect-hook'

## Business Requirements

Refer to the [RESTy System Overview](../../apps-and-libraries/resty/README.md) for a complete review of the application, including Business and Technical requirements along with the development roadmap.

## Phase 3 Requirements

In phase 3, we will be connecting RESTy to live APIs, fetching and displaying remote data. Our primary focus will be to service *GET* requests

The following user stories detail the major functionality for this phase of the project.

- As a user, I want to enter the URL to an API and issue a GET request so that I can retrieve it's data
- As a user, I want to see the results returned from an API request in my browser in a readable format

Application Flow:

- User enters an API URL
- Chooses a REST Method
- Clicks the  "Go" button
- Application fetches data from the URL given, with the method specified
- Displays the response headers and results separately
- Both headers and results should be "pretty printed" JSON

> One possible design/layout. Please use your judgement and taste in styling your version of this application.

![Resty](resty.png)

## Technical Requirements / Note

> Extend your application to include the ability to send http requests and display response data, when the `Form` experiences a submission event.

1. Refactor application methods to allow for browser side HTTP requests to be sent.
   - Your implementation should allow the user to set a url, method, and request body.
1. Make sure all relavent request and response data is displayed to the User.

Suggested approach

- `<Form />` component, `onSubmit()` sends the user's entries to the `<App />` via method sent in through props
- `<App />` does a check on the request data from the form and updates the request variable in state with the `url`, `method`, and potentially the `body`
- `<App />` has an effect hook that's looking for changes to the request variable in state, and in response, runs the API request with the new request options from state
- `<App />` updates state with the results of the API Request
- `<Results />` sees the new API data as a prop and renders the JSON

Note: update your `<Results />` component to use a 3rd party component to "pretty print" the JSON in a color-coded, user-friendly format

## Tests

- Install the React Testing Library framework
- Assert that upon submitting the form will result in data being rendered in the output area
- You will need to "mock" the API request with React Testing Library
  - Note the example here: <https://testing-library.com/docs/react-testing-library/example-intro/>
    - This shows how to use the `msw` package to setup a fake server that returns fake data in your tests so that you can run tests without having to call an actual API

## Deployment

Deploy your application to GitHub pages using a GitHub action which will publish the "build" to the `gh-pages` branch of your repository on all check-ins

## Stretch Goals

Add support for all REST methods

- **GET** a single record by ID
- **DELETE** a single record by ID
- **PUT** a single record by ID
  - Requires the addition of a text area where you can type in the JSON body for the update
- **POST** to create a new record
  - Requires the addition of a text area where you can type in the JSON body for the new record

## Assignment Submission Instructions

Refer to the the [Submitting React Apps Lab Submission Instructions](../../../reference/submission-instructions/labs/react-apps.md) for the complete lab submission process and expectations


text:
# 01 Workspaces

In this example, we are going to learn how we can work with `npm` workspaces.

We will start from `00-boilerplate`.

## Steps to build it

Let's start by creating the main `package.json` (we can use `npm init -y` to create it and then edit it):

```bash
npm init -y

```

Let's edit:

_./package.json_

```json
{
  "name": "game-of-thrones",
  "private": true
}
```

Create a `.gitignore` file:

_./.gitignore_

```
node_modules
dist
.turbo

```

If we want to create a new `workspace`:

```bash
npm init -y -w ./helpers/my-workspace

```

> NOTE: we can use the flag `-w` or `--workspace`.

Notice that we have updated the main `package.json` with a new field called `workspaces`:

_./package.json_

```json
{
  "name": "game-of-thrones",
  "private": true,
  "workspaces": ["helpers/my-workspace"]
}
```

In addition, we have created a new `package.json` inside the `helpers/my-workspace` folder, a `package-lock.json` in the root path and a `node_modules` folder with the `helpers/my-workspace` project symslink (although we don't have any third party dependency yet).

We can update the `package.json` root file to consider more that one workspace inside the `helpers` folder:

_./package.json_

```diff
{
  "name": "game-of-thrones",
  "private": true,
  "workspaces": [
-    "helpers/my-workspace"
+    "helpers/*"
  ]
}

```

Let's run `npm install` to update the `package-lock.json`:

```bash
npm install

```

Let's remove the `my-workspace` project and copy the `house-helpers` and `motto-helpers` projects from the `00-boilerplate` folder.

Let's run `npm install` again:

```bash
npm install

```

Notice that the `package-lock.json` has been updated with the `house-helpers` and `motto-helpers` projects dependencies and the symlinks have been created ( inside `node_modules/@my-org` folder).

> NOTE: also, we only have the root `node_modules` folder and the `package-lock.json` file, not inside each project.

## house-helpers project

This project is configured as an internal project, intended to be used without compilation, but directly reference the source code files.

_./helpers/house-helpers/package.json_

```json
{
  ...
  "types": "src/index.ts",
  "type": "module",
  "main": "src/index.ts",
}

```

## motto-helpers project

This project is configured to be published as a library in `npm`. Therefore, it has the `build` command for that purpose and the `start` command to be able to run it locally.

_./helpers/motto-helpers/package.json_

```json
{
  ...
  "type": "module",
  "module": "./dist/motto-helpers.js",
  "main": "./dist/motto-helpers.umd.cjs",
  "types": "./dist/index.d.ts",
  "exports": {
    ".": {
      "import": "./dist/motto-helpers.js",
      "require": "./dist/motto-helpers.umd.cjs",
      "types": "./dist/index.d.ts"
    }
  },
  "scripts": {
    "start": "npm run build -- --watch",
    "build": "vite build"
  },

```

Delete the `package-lock.json` file to force `npm` to create a new one:

```bash
rm package-lock.json

```

This project has the `house-helpers` project as a dependency because we are sharing the `House` enum type. We are going to install it using the workspace :

```bash
npm install @my-org/house-helpers -w @my-org/motto-helpers

```

> NOTE: We must install all the dependencies from the root path.

Update `motto-helpers` project:

_./helpers/motto-helpers/src/motto.helpers.ts_

```diff
+ import { House } from '@my-org/house-helpers';

const MOTTOS: Record<House, string> = {
  stark: 'Winter is Coming!',
  targaryen: 'Fire and Blood!',
  lannister: 'Hear Me Roar!',
  baratheon: 'Ours is the Fury!',
};

export const getHouseMotto = (house: House): string => MOTTOS[house];

```

Everything seems to be working fine, including the typings. Let's run it locally:

```bash
npm run start -w @my-org/motto-helpers

```

> Check the build in the `dist/motto-helpers.js` file.

If we add a new house in the `house-helpers` project:

_./helpers/house-helpers/src/house.models.ts_

```diff
export enum House {
  stark = 'stark',
  targaryen = 'targaryen',
  lannister = 'lannister',
+ baratheon = 'baratheon',
}

```

We can see that the `motto-helpers` project has a new compilation error (even without saving the file):

_./helpers/motto-helpers/src/motto.helpers.ts_

```diff
import { House } from '@my-org/house-helpers';

const MOTTOS: Record<House, string> = {
  stark: 'Winter is Coming!',
  targaryen: 'Fire and Blood!',
  lannister: 'Hear Me Roar!',
+ baratheon: 'Ours is the Fury!',
};

export const getHouseMotto = (house: House): string => MOTTOS[house];

```

## Web apps

Let's add a new workspace for the web apps:

_./package.json_

```diff
{
  "name": "game-of-thrones",
  "private": true,
  "workspaces": [
    "helpers/*",
+    "apps/*"
  ]
}

```

Copy the `baratheon`, `lannister`, `stark` and `targaryen` projects from the `00-boilerplate` folder to the `./apps/*` path.

Run it:

```bash
npm install

```

Every app will have the `house-helpers` and `motto-helpers` projects as dependencies. Let's install them using the workspace:

```bash
npm install @my-org/house-helpers @my-org/motto-helpers -w @my-org/house-baratheon

npm install @my-org/house-helpers @my-org/motto-helpers -w @my-org/house-lannister

npm install @my-org/house-helpers @my-org/motto-helpers -w @my-org/house-stark

npm install @my-org/house-helpers @my-org/motto-helpers -w @my-org/house-targaryen

```

Update the `stark` app project:

_./apps/stark/src/app.component.tsx_

```diff
import './app.css';
import logo from '/logo.png';
+ import { House, getHouseTitle } from '@my-org/house-helpers';
+ import { getHouseMotto } from '@my-org/motto-helpers';

function App() {
  return (
    <>
      <img src={logo} className="logo" />
+     <h1>{getHouseTitle(House.stark)}</h1>
+     <h2>{getHouseMotto(House.stark)}</h2>
    </>
  );
}

export default App;

```

> NOTE: Rest app projects are updated.

If we want to run all the projects at the same time, [npm has some flags](https://docs.npmjs.com/cli/v7/using-npm/workspaces#ignoring-missing-scripts) to run multiple workspaces commands at the same time:

```bash
npm start --workspaces --if-present

```

> But it doesn't work with watch mode because it blocks the execution on the first project.

Let's install a third party library [npm-run-all](https://www.npmjs.com/package/npm-run-all) to run commands in parallel:

```bash
npm install npm-run-all --save-dev

```

Update the root `package.json` file:

_./package.json_

```diff
{
  "name": "game-of-thrones",
  "private": true,
  "workspaces": [
    "helpers/*",
    "apps/*"
  ],
+ "scripts": {
+   "start": "run-p start:*",
+   "start:motto-helpers": "npm start -w @my-org/motto-helpers",
+   "start:stark": "npm start -w @my-org/house-stark",
+   "start:targaryen": "npm start -w @my-org/house-targaryen",
+   "start:lannister": "npm start -w @my-org/house-lannister",
+   "start:baratheon": "npm start -w @my-org/house-baratheon"
+ },
...

```

Run it:

```bash
npm start

```

> Add some updates in `motto-helpers` and `house-helpers` to check the watch mode.

# About Basefactor + Lemoncode

We are an innovating team of Javascript experts, passionate about turning your ideas into robust products.

[Basefactor, consultancy by Lemoncode](http://www.basefactor.com) provides consultancy and coaching services.

[Lemoncode](http://lemoncode.net/services/en/#en-home) provides training services.

For the LATAM/Spanish audience we are running an Online Front End Master degree, more info: http://lemoncode.net/master-frontend

repository: Lemoncode/master-frontend-lemoncode

repo_name: Lemoncode/master-frontend-lemoncode


text:
## Master Thesis Project: Harshita Agarwala

Extracting Interpretable Latent Spaces for scRNA-seq Using Disentangled Representations

### Usage

Reproducing results from Jupyter Notebooks:
* JN1_train.ipynb - loads, normalizes and trains the data
* JN2_kang_analysis.ipynb - further analyses the trained model for Kang dataset. It calculates both types of disentanglement scores and also visualizes the latent space as well as gene-feature space plots.
* JN3_dentate_analysis.ipynb - further analyses the trained model for Dentate Gyrus dataset.
* JN4_Out of Sample Prediction.ipynb - implements Out of Sample Prediction and analyses the results further
* Model Comparisons folder provides the notebooks to reproducs the model architecture comparison plots.

### Misc
* The **environment.yml** file specifies the conda environment in which the project was run.
* Data can be accessed from [here](https://drive.google.com/open?id=1ywXG0K-_nuqnFL8u3x4klsPNOrEdeg27)

repository: theislab/disent

path: /Master Thesis Project/README.md

repo_name: theislab/disent


text:
# hackers_conversion_service_sip
A SIP service that offers a decimal to hex/bin conversion service.

You are in the supermarket, and suddenly you feel the urge to convert the price of that loaf of bread to hexadecimal. But how are you going to do that with just your dumbphone?

Easy!

Earlier that day, you created a `sip.conf` configuration file, ran this python script on your dusty old server, and connected it to your favorite landline SIP service. Lo and behold, hexadecimal and binary is now within arm's reach from anywhere on the planet (mileage may vary)! It's the best thing since sliced bread!

Released in CC0 (Public Domain) for everyone to tinker at.


text:
## Functions

setsEqual(a, b) ⇒ boolean

Compares two sets for their equality.

orderedSetsEqual(a, b) ⇒ boolean

Determines if two sets are equal, not just in terms of existence, but also
in their ordering.

This differs from setsEqual in that the order matters, when checking for
equality.

The rationale for this function is that all sets in JavaScript are
technically ordered sets. Not only will JavaScript developers want to know if
two sets are equal by content, but also equal in ordering of said content.

isSubset(a, b) ⇒ boolean

Determines if the first set is a subset of the second set.

isProperSubset(a, b) ⇒ boolean

Determines if the first set is a proper subset of the second set. That is,
the size of the first set must be less than the second set, and all elements
in the first set must also be in the second set.

isProperSubset differs from isSubset in that if both the first set and
second set are equal, then false is returned, since the size of the first
set is not less than the second set.

isSuperset(a, b) ⇒ boolean

Determines if the first set is a superset of the second set.

isProperSuperset(a, b) ⇒ boolean

Determines if the first set is a proper superset of the second set. That is,
the size of the first set must be greater than the second set, and all
elements in the second set must also be in the first set.

isProperSuperset differs from isSubset in that if both the first set and
second set are equal, then fals is returned, since the size of the first
set is not greater than the second set.

union(...sets) ⇒ Set

Returns the union of all the supplied sets.

This is just a named function to initialize a new set via ES6's rest-spread.

intersect(...sets) ⇒ Set

Returns the intersection of all the supplied sets.

difference(a, b) ⇒ Set

Returns the set difference between the first and second set.

That is, derive a new set where, elements in the resulting set are also in
the first set  (a), but not in the second set (b).

## setsEqual(a, b) ⇒ boolean
Compares two sets for their equality.

**Kind**: global function

| Param | Type | Description |
| --- | --- | --- |
| a | Set | The first set to compare |
| b | Set | The second set to compare |

## orderedSetsEqual(a, b) ⇒ boolean
Determines if two sets are equal, not just in terms of existence, but also
in their ordering.

This differs from `setsEqual` in that the order matters, when checking for
equality.

The rationale for this function is that all sets in JavaScript are
technically ordered sets. Not only will JavaScript developers want to know if
two sets are equal by content, but also equal in ordering of said content.

**Kind**: global function

| Param | Type | Description |
| --- | --- | --- |
| a | Set | The first set to compare |
| b | Set | The second set to compare |

## isSubset(a, b) ⇒ boolean
Determines if the first set is a subset of the second set.

**Kind**: global function

| Param | Type | Description |
| --- | --- | --- |
| a | Set | The set that we hypothesize as being a subset |
| b | Set | The set for which we want to test if it is a superset |

## isProperSubset(a, b) ⇒ boolean
Determines if the first set is a proper subset of the second set. That is,
the size of the first set must be less than the second set, and all elements
in the first set must also be in the second set.

`isProperSubset` differs from `isSubset` in that if both the first set and
second set are equal, then false is returned, since the size of the first
set is not less than the second set.

**Kind**: global function

| Param | Type | Description |
| --- | --- | --- |
| a | Set | The set that we hypothesize as being a proper subset |
| b | Set | The set for which we want to test if it is a proper superset |

## isSuperset(a, b) ⇒ boolean
Determines if the first set is a superset of the second set.

**Kind**: global function

| Param | Type | Description |
| --- | --- | --- |
| a | Set | The set that we hypothesize as being a superset |
| b | Set | The set for which we want to test if it is a subset |

## isProperSuperset(a, b) ⇒ boolean
Determines if the first set is a proper superset of the second set. That is,
the size of the first set must be greater than the second set, and all
elements in the second set must also be in the first set.

`isProperSuperset` differs from `isSubset` in that if both the first set and
second set are equal, then fals is returned, since the size of the first
set is not greater than the second set.

**Kind**: global function

| Param | Type | Description |
| --- | --- | --- |
| a | Set | The set that we hypothesize as being a proper superset |
| b | Set | TThe set for which we want to test if it is a proper subset |

## union(...sets) ⇒ Set
Returns the union of all the supplied sets.

This is just a named function to initialize a new set via ES6's rest-spread.

**Kind**: global function

| Param | Type | Description |
| --- | --- | --- |
| ...sets | Array.<Set> | parameter of multiple sets |

## intersect(...sets) ⇒ Set
Returns the intersection of all the supplied sets.

**Kind**: global function

| Param | Type | Description |
| --- | --- | --- |
| ...sets | Array.<Set> | parameter of multiple sets |

## difference(a, b) ⇒ Set
Returns the set difference between the first and second set.

That is, derive a new set where, elements in the resulting set are also in
the first set  (`a`), but not in the second set (`b`).

**Kind**: global function

| Param | Type | Description |
| --- | --- | --- |
| a | Set | The set from which we want to derive a new set, but with some   elements removed |
| b | Set | The set that will determine which elements to remove |

repository: shovon/sets-utils

repo_name: shovon/sets-utils


text:
# MSP430 BSLprog
C# .NET implementation of GUI application for flashing MSP430 microcontrolers over the UART using Texas Instruments Bootstrap Loader

This project is in alpha alpha alpha version (basicaly it's only bunch of spaghetti code tested on the MSP430G2553 only)

Let me know if You are interested in testing or adding support for other MSP430 microcontrolers

![Alt text](https://github.com/micovo/msp430_bslprog/blob/master/docs/screenshot.png "MSP430 BSLprog screenshot")

More information about TI Bootstrap Loader is available at
http://processors.wiki.ti.com/index.php/BSL_%28MSP430%29


text:
# Highlightr Backend

Ruby on Rails backend for Highlightr. User information is persisted through a sign up process, allowing users to log in and customize their experience. Uses JWT as an eimplmentation of auth. Handles streamers, VoDs, and VoD highlights. A Python3 script parses twitch chat logs and analyzes them for "highlights".

### Installation and Usage
```
bundle i
rails db:create db:migrate db:seed
rails s
```

### Environment Variables
Create a .env file containing the following.
```
export KEY=YOUR TWITCH CLIENT ID
export SECRET=YOUR SECRET FOR JWT
```

### Models and Relationships
```
Streamer has many Vods, has many highlights through Vods
Vod belongs to Streamer, has many highlights
Highlight belongs to Vod

User
  - email
  - password
  - username
  - first_name
  - profile_picture

Streamer
  - twitch_id
  - login
  - display_name
  - broadcaster_type
  - description
  - profile_image_url
  - offline_image_url

Vod
  - streamer_id
  - twitch_id
  - login

Highlight
  - vod_id
  - twitch_id
  - start
  - end
```

### Routes
```
             api_v1_login POST /api/v1/login                                                                  api/v1/auth#create
      api_v1_current_user GET  /api/v1/current_user                                                           api/v1/auth#show
            api_v1_signup POST /api/v1/signup                                                                 api/v1/users#create
                   api_v1 GET  /api/v1/profile/:id                                                            api/v1/users#show
         api_v1_streamers GET  /api/v1/streamers                                                              api/v1/streamers#index
                          GET  /api/v1/streamers/:login                                                       api/v1/streamers#show
               api_v1_vod POST /api/v1/vod                                                                    api/v1/vods#create
                          GET  /api/v1/vod/:twitch_id                                                         api/v1/vods#show
         api_v1_highlight POST /api/v1/highlight                                                              api/v1/highlights#create
                          GET  /api/v1/highlight/:id                                                          api/v1/highlights#show
```

### Directory Structure
```
app/ - Contains controllers, models, and serializers
  controllers/
    api/
      v1/ Controllers for auth, highlights, streamers, users, vods
  models/ - Models for highlight, streamer, user, vod
  serializers/ - Serializers for highlight, streamers, user, vod

db/ - Database migration files, schema, and seed
  migrate/ - Migrations files for creating users, streamers, highlights, and vods

.env - Environment Variables
```

# findHighlights.py
The Twitch Chat for a VoD is downloaded using https://github.com/PetterKraabol/Twitch-Chat-Downloader.
findHighlights.py scans the directory for appropriate .txt files, parses each file and then sends a post request to backend server, persisting each timestamp as a highlight.

### Usage
```
python3 findHighlights.py
```

repository: NorbertLam/highlightr-backend

gha_language: Ruby

repo_name: NorbertLam/highlightr-backend