text:
# Documentation

**[issue-dashboard](https://github.com/ethomson/issue-dashboard)** is a framework for creating dashboards from user data on GitHub, utilizing [GitHub Actions](https://github.com/features/actions) and [GitHub Pages](https://pages.github.com/).

You can define the data to collect out of GitHub -- using issue queries or arbitrary scripts -- and this tool will generate dashboards in HTML, that can be published to GitHub Pages, or Markdown, that can be published as a file in a repository or a comment in an issue.

Currently, this tool only supports instantaneous data -- for example: how many issues with a certain label are open _right now_, or how many pull requests are currently open that were created within the last week.  It does not support time series, meaning you cannot plot a graph of the number of open issues per day.

## Overview

A dashboard has one or more _sections_, which are logical divisions and serve as collections of _widgets_ that display data.  A widget is one of:

**String widget**

A string widget simply displays a string.  The data could be static, or the result of a JavaScript execution.  A string widget has a text _value_, and an optional _title_, _color_ and _url_.

**Number widget**

A number widget simply displays a numeric value.  Like string widgets, the data could be static or the result of a JavaScript expression.  But since only numbers are supported, instead of free-form strings, number widgets may be rendered smaller to save space in display.

In addition, the data source could be a GitHub [issue query](https://help.github.com/en/github/searching-for-information-on-github/searching-issues-and-pull-requests), in which case the number of results for the query will be displayed, and the widget will link to the query itself for more information.

A number widget has an _issue\_query_ or a numeric _value_, and an optional _title_, _color_ and _url_.

**Graph widget**

A graph widget displays a bar chart of multiple different numeric values.  Like a number widget, the data source for the values could be a static number, the result of executed JavaScript, or the number of matching results of a GitHub issue query.

A graph widget has _elements_, and an optional _title_.  Each element has an _issue\_query_ or a numeric _value_, and an optional _title_, _color_ and _url_.

**Table widget**

A table widget displays tabular data containing strings or numbers.  A table contains an optional header row and multiple element rows, each row containing cells.  Each cell may be a static string or the result of a Javascript expression.

In addition, the data source could be a GitHub [issue query](https://help.github.com/en/github/searching-for-information-on-github/searching-issues-and-pull-requests), in which case the table will contain the results of the query, and each row will link to the issue itself.

A table widget has an _issue\_query_ or _elements_, and an optional _title_ and _header_.  Each element is an array of rows.  Each row has a string _value_  and an optional _align_, _color_ and _url_.

## Installation

This dashboard tool is an _action_ meant to be used in a [GitHub Actions](https://github.com/features/actions) workflow.  You should provide your input in your workflow, and it will produce HTML or Markdown.  You can then either upload the result to GitHub Pages, or update an issue or file in the repository.

For example, to run this hourly (on the hour) and upload the results to GitHub Pages:

```yaml
name: Build Dashboard

on:
  schedule:
  - cron: 0 * * * *

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Check out repository
      uses: actions/checkout@v2
    - name: Check out GitHub Pages branch
      uses: actions/checkout@v2
      with:
        ref: 'gh-pages'
        path: 'out'

    - name: 'Generate Dashboard'
      uses: ethomson/issue-dashboard@v1
      with:
        config: |
          title: 'Dashboard'
          output:
            format: html
            filename: 'out/dashboard.html'
          sections:
          - title: 'Pull Requests'
            widgets:
            - type: 'table'
              title: 'New Pull Requests (This Week)'
              issue_query: 'repo:libgit2/libgit2 is:open is:issue created:>{{ date("-7 days") }} sort:created-asc'
        token: ${{ github.token }}

    - name: Publish Documentation
      run: |
        git add .
        git config user.name 'Dashboard User'
        git config user.email 'nobody@nowhere'
        git commit -m 'Documentation update' --allow-empty
        git push origin gh-pages
      working-directory: out
```

## Configuration

Configuration is specified by YAML or JSON.  At the top-level, the dashboard must have an `output.format` of either `html` or `markdown`, and an `output.filename` that will be written with the dashboard contents.  The dashboard should have a `title` and `description` that will be shown on the dashboard.

One or more `sections` can be defined, each with their own `title` and `description`.  A section acts as a container for `widgets` that will display dashboard data.

### String widgets

A string widget will simply display a textual value.  An example of a dashboard with a single section that contains two string widgets:

![Static string widgets](static-strings.png)

This dashboard has a single section ('Memorable quotes') that contains two string widgets.  Widgets can have titles, values, colors and URLs.  The data is strictly static, it does not use a script to produce the values.

```yaml
output:
  format: html
  filename: dashboard.html

sections:
- title: 'Memorable quotes'
  description: 'Some notable quotations'
  widgets:
  - type: 'string'
    title: 'Ernest Hemingway'
    value: 'The way to make people trustworthy is to trust them.'
    color: 'red'
  - type: 'string'
    title: 'Joshua from War Games'
    value: 'The only way to win is not to play.'
    color: 'black'
```

### Number widgets

A number widget will simply display an integer or floating point number.  An example of a dashboard with two sections, each with three number widgets:

![Static number widgets](static-numbers.png)

This dashboard has a title ('Conversions') and a description.  It has two sections ('Metric to US' and 'US to metric'), each with three number widgets. Widgets can have titles, values, colors and URLs. The data is strictly static, it does not use GitHub issue queries or scripts to produce the values.

```yaml
# The title and description of the overall dashboard; these will be
# displayed at the top of the file.
title: 'Conversions'
description: 'Some handy metric to US conversions.'

# The name of the file that will be output, and the type of output.
# 'format' may be 'markdown' or 'html'
output:
  format: html
  filename: dashboard.html

sections:

# The first section is metric to US conversions
- title: 'Metric to US'
  description: 'Distance, mass and volume; metric to US.'
  widgets:
  - type: number
    value: '1.61'
    title: 'Kilometers in a mile'
    url: 'https://www.google.com/search?q=km+to+miles'
    color: 'blue'
  - type: number
    value: '0.454'
    title: 'Kilograms in a pound'
    color: 'red'
  - type: number
    value: '1.06'
    title: 'Liters in a quart'
    color: 'green'

# The section section is US to metric conversions
- title: 'US to metric'
  description: 'Distance, mass and volume; US to metric.'
  widgets:
  - type: number
    value: '0.621'
    title: 'Miles in a kilometer'
    url: 'https://www.google.com/search?q=miles+to+km'
    color: 'blue'
  - type: number
    value: '2.20'
    title: 'Pounds in a kilogram'
    color: 'red'
  - type: number
    value: '0.946'
    title: 'Quarts in a liter'
    color: 'green'
```

### Graph widgets

A graph widget will display a bar chart of multiple numeric values.  An example of a dashboard with a single section containing a graph widget with 3 elements:

![Static graph](static-graph.png)

This dashboard a single section ('Pizza preferences') with a graph widget.  The graph widget has a title 'Pizza variety' and four elements showing that there is broad support for all pizza varieties except New Haven style.

```yaml
output:
  format: html
  filename: dashboard.html

sections:
- title: 'Pizza preferences'
  description: 'Type of pizza preferred by respondents.'
  widgets:
  - type: graph
    title: Pizza variety
    elements:
    - title: New York
      value: 18
      color: green
    - title: Chicago
      value: 16
    - title: Neopolitan
      value: 15
    - title: 'New Haven'
      value: 1
      color: red
```

The `elements` themselves behave as number widgets, and the query, expression and syntax described below applies to the numeric value elements of graph widgets.

### Table widgets

A table widget will display a table of multiple string values.  An example of a dashboard with a single section containing a table widget with a header and 6 elements:

![Static table](static-table.png)

This dashboard a single section ('Important Dates') with a table widget.  The table widget has a title 'Historic US dates' and two headers ('Date' and 'Description').  There are 6 elements, each with two cells.  The first element uses strings for simplicity.  The second element shows static data as a _value_ with additional attributes.

```yaml
output:
  format: html
  filename: dashboard.html

sections:
- title: 'Important Dates'
  description: 'Important dates throughout history.'
  widgets:
  - type: 'table'
    title: 'Historic US dates'
    headers:
    - 'Date'
    - 'Description'
    elements:
    - [ '1775-04-19', 'Battles of Lexington and Concord' ]
    - - value: '1776-07-04'
        color: 'blue'
        url: 'https://en.wikipedia.org/wiki/Independence_Day_(United_States)'
      - value: 'Independence Day'
        color: 'red'
        url: 'https://en.wikipedia.org/wiki/Independence_Day_(United_States)'
    - - value: '1929-10-24'
        color: 'black'
      - value: 'Black Thursday; the stock market crash of {{ 1928 + 1 }}'
        color: 'black'
    - [ '1933-12-05', 'Repeal of prohibition' ]
    - [ '1973-01-22', 'Roe v Wade' ]
    - [ '2015-06-26', 'Obergefell v Hodges' ]
```

### Querying GitHub issues and pull requests

Instead of providing a static numeric value for number widgets and graph elements, you can provide an `issue_query` that will be run against GitHub, using [their query syntax](https://help.github.com/en/github/searching-for-information-on-github/searching-issues-and-pull-requests).  The number of results will be displayed as the value.  If a `url` is not provided, it will be provided as a link to the query on github.com.

For example, the issue query `repo:libgit2/libgit2 is:pr is:open` will query the number of pull requests in the open state in the `libgit2/libgit2` repository.  The dashboard widget will show the number of results, and if no `url` is specified, the widget will link to the corresponding query on github.com for full results.

```yaml
widgets:
- type: number
  issue_query: 'repo:libgit2/libgit2 is:pr is:open'
  title: 'Open pull requests'
  color: 'blue'
```

Similarly, instead of providing a list of values for a table widget, you can provide an `issue_query` that will be run against GitHub, using their query syntax.  The results will be displayed as the rows.  By default the issue or pull request number and title will be shown.

For example, the query `repo:libgit2/libgit2 is:pr is:open` will query the pull requests in the open state in the `libgit2/libgit2` repository.  The table widget will show each result, one per line.  The table cell will link to the corresponding issue on github.com.

```yaml
widgets:
- type: table
  issue_query: 'repo:libgit2/libgit2 is:pr is:open'
  title: 'Open pull requests'
```

### Using JavaScript expressions

You can use JavaScript expressions within the fields to compute them by surrounding the script within double curly-braces (`{{` and `}}`).

For example, this number widget will have a value of the result of the computation of `42 * 2`.

```yaml
widgets:
- type: number
  value: '{{ 42 * 2 }}'
  title: 'Simple arithmetic'
  color: 'blue'
```

The `value` is calculated first, and available to other fields.  This number widget will have a color of `red` if the value is below 10, or `green` otherwise.

```yaml
widgets:
- type: number
  value: '12'
  title: 'Simple arithmetic'
  color: '{{ value < 10 ? "red" : "green" }}'
```

Some helper functions are available, including date manipulation functions, since many GitHub issue queries take dates and times.

```yaml
widgets:
- type: number
  issue_query: 'repo:libgit2/libgit2 is:open created:<{{ date("-1 month") }}'
  title: 'Issues and PRs older than 1 month'
```

For more information, see [Data available to scripts](#data-available-to-scripts).

### Running function to produce data

For more complicated computations, you can provide a `script` that will be evaluated in an `async` context.  The return value of the function will be used as the numeric value.  Some data is provided, including the `github` context, which is an instance of [the Octokit API](https://github.com/octokit/rest.js/).

This widget will search open pull requests in the `libgit2/libgit2` repo that are older than 1 day.

```yaml
widgets:
- type: number
  script: |
    const results = await github.search.issuesAndPullRequests({
      q: `repo:libgit2/libgit2 is:pr is:open created:<${date('-1 day')}`
    })
    return results.data.total_count
```

You can also return an object, with a `value` property set to the numeric value for the widget.  The object may also include the `title`, `url` and `color` properties.  These will override the properties set in the YAML configuration.

```yaml
widgets:
- type: number
  script: |
    const repo = 'libgit2/libgit2'
    const results = await github.search.issuesAndPullRequests({
      q: `repo:${repo} is:pr is:open created:<${date('-1 day')}`
    })
    const count = results.data.total_count
    const title = 'PRs older than 1 day'
    const color = (count > 10) ? 'red' : 'green'
    return { value: count, title: title, color: color }
```

### Data available to scripts

Scripts will be run with some additional data available:

**`github`**: An instance of the [Octokit API](https://github.com/octokit/rest.js/) for interacting with GitHub REST APIs.  This will be authenticated with the `GITHUB_TOKEN` from the GitHub Actions instance creating this dashboard.

**`userdata`**: An object that is initially empty, and that you can use to store data between script invocations.  See "[Storing user data for scripts](#storing-user-data-for-scripts)", below.

**`value`** is available to the _title_, _url_ and _color_ expressions, and will be populated with the value of the widget.

**`item`** is available to the _value_ expressions of table fields that are generated from queries, and will be populated with the returned item from the query.

And additional helper functions:

**`date()`**: A function to produce a date in `YYYY-MM-DD` format.  Without arguments, it will return the current date in UTC.  You can specify a date or full timestamp as the argument, and include date or time adjustments, specified below.

**`datetime()`**: A function to produce a date and time in `YYYY-MM-DDThh:mm:ssZ` format.  Without arguments, it will return the current date and time in UTC.  You can provide a date or full timestamp as the argument, and include date or time adjustments as specified below.

**`time()`**: A function to produce a time in `hh:mm:ss` format.  Without arguments, it will return the current time in UTC.  You can provide a time or full timestamp as the argument, and include date or time adjustments as specified below.

Time and date adjustments:

Adjustment strings can be provided to the date functions so that you can calculate dates and times in the past or future.  Adjustments are given as `+` or `-` an integer number of units (`days`, `hours`, etc.)  Additionally, adjustments may be given as `+` or `-` a number of hours, minutes and seconds in `hh:mm:ss` format.

For example:

**`date('2018-12-31T11:33:44Z')`**: will return just the date portion of the timestamp given.  This will return `2018-12-31`.

**`date('2018-11-25 + 1 month')`**: will return the date one month after `2018-11-25`.  This will return `2018-12-25`.

**`date('-1 month')`**: will return the date in `YY-MM-DD` as of one month ago.  If today's date is `2020-04-15` then this will return `2020-03-15`.

**`datetime('-1 year-1 month-1 day+1 hour+1 minute+1 second')`**: will return the date and time in `YY-MM-DDThh:mm:ssZ` format as of one year, one month and one day ago.  If today's date and time is `2020-04-15T13:46:14` then this will return `2019-03-14T12:45:13`.

**`time('-01:02:03')`**: will return the time in `hh:mm:ss` format as of one hour, 2 minutes and 3 seconds ago.  If the current time is `12:45:13`, then this will return `11:43:10`.

### Storing user data for scripts

The `userdata` object is available for scripts to store data between script invocations.  For example, the expression `userdata.num = 2` will be executed for the first widget, which will have a value of `2`.  The `userdata` object will be available for the subsequent widget's expression, so it will evaluate to a value of `4`.

```yaml
widgets:
- type: number
  value: '{{ userdata.num = 2 }}'
- type: number
  value: '{{ userdata.num * 2 }}'
```

### Setup and shutdown scripts

A top-level `setup` script can be defined, which will be executed at the beginning of dashboard execution.  This may be useful to set up properties or define functions in the `userdata` object for subsequent scripts.  A top-level `shutdown` script can be defined, which will be executed after the dashboard is built.

```yaml
title: 'Dashboard'
output:
  format: html
  filename: dashboard.html
setup: |
  userdata.color_func = function(num) {
    if (num < 10) return 'green'
    if (num > 50) return 'blue'
    return 'yellow'
  }
sections:
- title: 'Pull requests'
  widgets:
  - type: number
    issue_query: 'repo:libgit2/libgit2 is:pr is:open'
    color: '{{ userdata.color_func(value) }}'
```

### Colors

Currently supported colors are:

* `black`
* `red`
* `yellow`
* `green`
* `blue`

## Configuration reference

Configuration is specified by YAML or JSON; the general structure is defined below.  Syntactically:

* Dot-notation (`a.b`) is used to denote properties on maps.  For example:

  `output.format` refers to a property `format` on the `output` map, which would be specified in YAML as:

      output:
        format: 'markdown'

* Array notation (`a`_[n]_) is used to denote sequences.  This may be combined with dot-notation, for a sequence of maps, or array notation, for a sequence of sequences.  For example:

   `sections`_[i]_`.title` refers to a property `title` on an element in the `sections` sequence, which would be specified in YAML as:

      sections:
      - title: 'The title of the first section'
      - title: 'The title of the second sequence'

   A more complex example, `sections`_[i]_`.widgets`_[j]_`.elements`_[k][m]_`.value` refers to the `value` property on an element in the multi-dimensional sequence `elements`, on the `widgets` sequence, itself a part of the `sections` sequence, which would be specified in YAML as:

      sections:
      -  widgets:
         - elements:
           - - value: 'First cell in the first row'
             - value: 'Second cell in the first row'
             - value: 'Third cell in the first row'
           - - value: 'First cell in the second row'
             - value: 'Second cell in the second row'
             - value: 'Third cell in the second row'

### Global options

**`title`**: the title for the dashboard; this will generally be displayed at the top of the page.  This setting is optional.

**`description`**: the description for the dashboard; this will generally be displayed at the top of the page; his setting is optional.

**`output.format`**: the format that the dashboard will be rendered; one of `html` or `markdown`.

**`output.filename`**: the name of the file that the dashboard will be written to.

**`setup`**: a script that will be executed before analytics are collected; this can be used to initialize global state for script widgets to use later.  This setting is optional.

**`shutdown`**: a script that will be executed after analytics are collected; this can be used to shut down global state that was set up by prior scripts.  This setting is optional.

### Sections

**`sections`**: a list of sections that serve as logical containers for widgets.

**`sections`_[i]_`.title`**: the title for a section; this setting is optional.

**`sections`_[i]_`.description`**: the description for a section; this setting is optional.

**`sections`_[i]_`.widgets`**: a list of widget definitions for the current section.

### Widgets

**`sections`_[i]_`.widgets`_[j]_`.type`**: the type of widget; one of `string`, which displays textual data, `number`, which displays a single numeric value, `graph`, which displays multiple numeric values in bar chart form, or `table`, which displays multiple strings in tabular form.

### String widgets

**`sections`_[i]_`.widgets`_[j]_`.title`**: the name of the widget.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.

**`sections`_[i]_`.widgets`_[j]_`.url`**: the URL of the widget; the widget will have a hyperlink to this URL.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.

**`sections`_[i]_`.widgets`_[j]_`.color`**: the color of the widget.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.

**`sections`_[i]_`.widgets`_[j]_`.value`**: the value of the widget.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.issue_query` or `sections`_[i]_`.widgets`_[j]_`.script`.

**`sections`_[i]_`.widgets`_[j]_`.issue_query`**: a GitHub [issue query](https://help.github.com/en/github/searching-for-information-on-github/searching-issues-and-pull-requests) to perform.  The total number of results for the query will be used as the value of the widget.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.value` or `sections`_[i]_`.widgets`_[j]_`.script`.

**`sections`_[i]_`.widgets`_[j]_`.script`**: a JavaScript function to evaluate.  If the return value is numeric, then the return value will be used as the value of the widget.  If the return value is an object, then the `value` property on the return value will be used as the value of the widget, and the returned object may have `title`, `color` and `url` properties, which will override values specified in the configuration.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.value` or `sections`_[i]_`.widgets`_[j]_`.issue_query`.

### Number widgets

**`sections`_[i]_`.widgets`_[j]_`.title`**: the name of the widget.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.

**`sections`_[i]_`.widgets`_[j]_`.url`**: the URL of the widget; the widget will have a hyperlink to this URL.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.

**`sections`_[i]_`.widgets`_[j]_`.color`**: the color of the widget.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.

**`sections`_[i]_`.widgets`_[j]_`.value`**: the value of the widget.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.issue_query` or `sections`_[i]_`.widgets`_[j]_`.script`.

**`sections`_[i]_`.widgets`_[j]_`.issue_query`**: a GitHub [issue query](https://help.github.com/en/github/searching-for-information-on-github/searching-issues-and-pull-requests) to perform.  The total number of results for the query will be used as the value of the widget.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.value` or `sections`_[i]_`.widgets`_[j]_`.script`.

**`sections`_[i]_`.widgets`_[j]_`.script`**: a JavaScript function to evaluate.  If the return value is numeric, then the return value will be used as the value of the widget.  If the return value is an object, then the `value` property on the return value will be used as the value of the widget, and the returned object may have `title`, `color` and `url` properties, which will override values specified in the configuration.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.value` or `sections`_[i]_`.widgets`_[j]_`.issue_query`.

### Graph widgets

**`sections`_[i]_`.widgets`_[j]_`.elements`**: a list of elements to draw in the graph widget.

**`sections`_[i]_`.widgets`_[j]_`.elements`_[k]_`.title`**: the name of an item in the bar graph.

**`sections`_[i]_`.widgets`_[j]_`.elements`_[k]_`.url`**: the URL of the bar graph element; the name and element will have a hyperlink to this URL.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.

**`sections`_[i]_`.widgets`_[j]_`.elements`_[k]_`.color`**: the color of the bar graph element.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.

**`sections`_[i]_`.widgets`_[j]_`.elements`_[k]_`.value`**: the value of the bar graph element.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.elements`_[k]_`.issue_query` or `sections`_[i]_`.widgets`_[j]_`.elements`_[k]_`.script`.

**`sections`_[i]_`.widgets`_[j]_`.elements`_[k]_`.issue_query`**: a GitHub [issue query](https://help.github.com/en/github/searching-for-information-on-github/searching-issues-and-pull-requests) to perform.  The total number of results for the query will be used as the value of the bar graph element.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.elements`_[k]_`.value` or `sections`_[i]_`.widgets`_[j]_`.elements`_[k]_`.script`.

**`sections`_[i]_`.widgets`_[j]_`.elements`_[k]_`.script`**: a JavaScript function to evaluate.  If the return value is numeric, then the return value will be used as the value of the bar graph element.  If the return value is an object, then the `value` property on the return value will be used as the value of the bar graph element, and the returned object may have `title`, `color` and `url` properties, which will override values specified in the configuration.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.elements`_[k]_`.value` or `sections`_[i]_`.widgets`_[j]_`.elements`_[k]_`.issue_query`.

### Table widgets

**`sections`_[i]_`.widgets`_[j]_`.issue_query`**: a GitHub [issue query](https://help.github.com/en/github/searching-for-information-on-github/searching-issues-and-pull-requests) to perform.  Each result item will be shown in a cell, using either the fields defined by `sections`_[i]_`.widgets`_[j]_`.fields` or the issue number and title fields.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.elements`.

**`sections`_[i]_`.widgets`_[j]_`.fields`**: a list of the fields in the returned issues to display.  By default, this is the issue `number` and `title` fields.  This may only be specified when using a table configured with a `sections`_[i]_`.widgets`_[j]_`.issue_query`.

**`sections`_[i]_`.widgets`_[j]_`.fields`_[k]_**: a field to display in the table.  If this is an object with `title` and either `property` or `value` properties, then the `title` property will be used as the table header for this column, and the `property` or `value` property will be used for the data.  Otherwise, this is a string value which will be used literally for the header, and will be used as the property to return from each item in the query.

**`sections`_[i]_`.widgets`_[j]_`.fields`_[k]_.title**: the title of the table header for this column.

**`sections`_[i]_`.widgets`_[j]_`.fields`_[k]_.property**: the property to return from the returned issue item for this column.  For example, `created_date` will use the issue's `created_date` as the value for this cell.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.fields`_[k]_`.value`.

**`sections`_[i]_`.widgets`_[j]_`.fields`_[k]_.value**: the value to use for this cell.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.fields`_[k]_`.property`.

**`sections`_[i]_`.widgets`_[j]_`.headers`**: a list of the column headers for the table data.

**`sections`_[i]_`.widgets`_[j]_`.headers`_[k]_**: a cell in the table header.  This can be specified as a string, or an object with additional properties.

**`sections`_[i]_`.widgets`_[j]_`.headers`_[k]_`.value`**: the text to place in this column's header.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.headers`_[k]_`.script`.

**`sections`_[i]_`.widgets`_[j]_`.headers`_[k]_`.script`**: a JavaScript function to evaluate.  If the return value is a string, then the return value will be used as the value of this column's header.  If the return value is an object, then the `value` property on the return value will be used as the value of this column's header, and the returned object may have `color` and `url` properties, which will override values specified in the configuration.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.headers`_[k]_`.value`.

**`sections`_[i]_`.widgets`_[j]_`.elements`**: a list of the rows for the table data.  Each row is an array of cells.

**`sections`_[i]_`.widgets`_[j]_`.elements`_[k]_**: a list of the cell data.

**`sections`_[i]_`.widgets`_[j]_`.elements`_[k][m]_**: a cell in the table.  This can be specified as a string, or an object with additional properties.

**`sections`_[i]_`.widgets`_[j]_`.elements`_[k][m]_`.url`**: the URL of the table cell; the cell's value will have a hyperlink to this URL.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.

**`sections`_[i]_`.widgets`_[j]_`.elements`_[k][m]_`.color`**: the color of the table cell.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.

**`sections`_[i]_`.widgets`_[j]_`.elements`_[k][m]_`.value`**: the value of the table cell.  Expressions within double curly-braces (`{{` and `}}`) will be expanded.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.elements`_[k][m]_`.script`.

**`sections`_[i]_`.widgets`_[j]_`.elements`_[k][m]_`.script`**: a JavaScript function to evaluate.  If the return value is numeric, then the return value will be used as the value of the table cell.  If the return value is an object, then the `value` property on the return value will be used as the value of the table cell, and the returned object may have `color` and `url` properties, which will override values specified in the configuration.  This may not be specified with `sections`_[i]_`.widgets`_[j]_`.elements`_[k][m]_`.value`.

repository: railsbob/issue-dashboard

repo_name: railsbob/issue-dashboard


text:
# hapi-react-views

A hapi view engine for React components.

[![Build Status](https://travis-ci.org/jedireza/hapi-react-views.svg?branch=master)](https://travis-ci.org/jedireza/hapi-react-views)
[![Dependency Status](https://david-dm.org/jedireza/hapi-react-views.svg?theme=shields.io)](https://david-dm.org/jedireza/hapi-react-views)
[![Peer Dependency Status](https://david-dm.org/jedireza/hapi-react-views/peer-status.svg?style=flat)](https://david-dm.org/jedireza/hapi-react-views#info=peerDependencies)
[![Dev Dependency Status](https://david-dm.org/jedireza/hapi-react-views/dev-status.svg?theme=shields.io)](https://david-dm.org/jedireza/hapi-react-views#info=devDependencies)

By default, we render static markup. We can also choose to use
`React.renderToString`, preserving the `data-react-id` attributes so
re-mounting client side is possible.

## Install

```bash
$ npm install hapi-react-views
```

Note: Your project should have it's own `react` dependency installed. We depend
on `react` via `peerDependencies`.

## Usage

Note: As of hapi v9.x, your project must register the
[`vision`](https://github.com/hapijs/vision) plugin in order for the
`server.views()` method to be available.

Configuring the server manually:

```js
var Hapi = require('hapi');
var Vision = require('vision');
var HapiReactViews = require('hapi-react-views');

var server = new Hapi.Server();

server.register(Vision, function (err) {

    if (err) {
        console.log("Failed to load vision.");
    }

    server.views({
        engines: {
            jsx: HapiReactViews
        },
        compileOptions: {}, // optional
        relativeTo: __dirname,
        path: 'views'
    });
});
```

Configuring with a CLI manifest using
[`visionary`](https://github.com/hapijs/visionary):

```json
{
    "servers": [{
        "port": 8080
    }],
    "plugins": {
        "vision": {},
        "visionary": {
            "engines": {
              "jsx": "hapi-react-views"
            },
            "compileOptions": {},
            "path": "./views"
        }
    }
}
```

## API

### `server.views(options)`

[Please refer to the `vision` docs on
`server.views(options)` for complete details.](https://github.com/hapijs/vision/blob/master/API.md#serverviewsoptions)

We'll be focusing on the `compileOptions` property that you can include when
passing `options` to `server.views`.

The following `compileOptions` will customize how `hapi-react-views` works.

  - `compileOptions` - options object passed to the engine's compile function.
    Defaults to `{}`.
    - `doctype` - a simple string prepended to the response. Defaults to
      `<!DOCTYPE html>`
    - `renderMethod` - the method to invoke on `React` to generate our output.
       Available options are `renderToStaticMarkup` and `renderToString`.
       Defaults to `renderToStaticMarkup`.
    - `removeCache` - since `node-jsx` takes a while to startup, we can remove
      templates from the cache so we don't need to restart the server to see
      changes. Defaults to `'production' !== process.env.NODE_ENV`.
    - `useNodeJsx` - a boolean that controls if `node-jsx` is used. Defaults to
      `true`. Set to `false` if you're using another transformer (ex:
      `babel/require`) or don't need `jsx` transformations.
    - `node-jsx` - options object passed to
      [`node-jsx`](https://github.com/petehunt/node-jsx)'s `install` method.
      Defaults to `undefined`.

You're able to override all these `compileOptions` at runtime except `node-jsx`
which only happens once.

```js
var context = { name: 'Steve' };
var renderOpts = {
    runtimeOptions: {
        doctype: '<!DOCTYPE html>',
        renderMethod: 'renderToString'
    }
};

server.render('template', context, renderOpts, function (err, output) {

    // ...
});
```

[Please refer to `vision`'s docs on
`server.render(template, context, [options], callback)` for complete details.](https://github.com/hapijs/vision/blob/master/API.md#serverrendertemplate-context-options-callback)

## Examples

Before you can run the examples, you need to clone this repo and install the dependencies.

```bash
$ git clone git@github.com:jedireza/hapi-react-views.git
$ cd hapi-react-views
$ npm install
```

### Rendering a simple page

This example renders a simple component as HTML output. [View the
code.](https://github.com/jedireza/hapi-react-views/tree/master/examples/simple)

```bash
$ npm run simple-example
```

### Rendering with layouts

This example is renders simple components as HTML but adds the idea of using
layouts. [View the
code.](https://github.com/jedireza/hapi-react-views/tree/master/examples/layout)

```bash
$ npm run layout-example
```

### Remounting on the client (universal/isomorphic)

This example demonstrates the idea of remounting client side in order to create
universal/isomorphic applications.

license: MIT

repository: albertchan/hapi-react-views

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: albertchan/hapi-react-views


text:
# Changelog

## v2.0.2

* Allow passing custom `headers` to internal `update` DSL method

## v2.0.1

* Support for seperate URL used by oAuth2 redirect flow
* Fix handling of empty `Location` header for confirmable actions

## v2.0.0

* Complete rewrite of the gem
* Switched (back) to
* Fixed design issue regarding concurrency / thread safety

---

## v1.x.x

See changelog in `v1` branch.

## v0.x.x

See changelog in `v1` branch.


text:
## Welcome

I am a Senior Data Scientist in the Research Scientific Computing group at
Seattle Children's Research Institute.  My prior background is
in plant population genetics and breeding. I also provided general bioinformatics
support while working with HPCBio at the University of Illinois from 2019-2022.
I am a developer of software
for the genetic analysis of polyploid organisms.  I earned a PhD in Genetics
from UC Davis in 2011 and a BA in Genetics, Cell & Developmental Biology from
Dartmouth College in 2004.

[LinkedIn](https://www.linkedin.com/in/lindsay-clark-75539aa9/)

[ORCID](https://orcid.org/0000-0002-3881-9252)

[Google Scholar](https://scholar.google.com/citations?user=d2OkHU4AAAAJ)

[GitHub](https://github.com/lvclark/)

[Publons](https://publons.com/researcher/734253/lindsay-virginia-clark/)

## Excellence in Breeding meeting May 8-10, 2019

Datasets for tutorials are available at
<https://gobiiproject.atlassian.net/wiki/spaces/WG/pages/70451254/Data+sets>

Wednesday, May 8

* Tools for variant and genotype calling -- [Powerpoint](excellence_in_breeding/Variant_and_Genotype_Calling_in_Polyploids.pdf)
* File formats for polyploid genotypes -- [Powerpoint](excellence_in_breeding/File_formats_for_polyploid_genotypes.pdf)
* Genotype calling with polyRAD in a sweetpotato F1 population -- [Tutorial on web](excellence_in_breeding/sweetpotato_F1_polyRAD_tutorial.html) -- [Download R markdown](excellence_in_breeding/sweetpotato_F1_polyRAD_tutorial.Rmd)
* Genotype calling with polyRAD in a *Miscanthus* diversity panel -- [Tutorial on web](excellence_in_breeding/polyRAD_diversity_panel.html) -- [Download R markdown](excellence_in_breeding/polyRAD_diversity_panel.Rmd)

Thursday, May 9

* GWAS in GAPIT with posterior mean genotypes -- [Tutorial on web](excellence_in_breeding/GAPIT_tetraploid.html) -- [Download R markdown](excellence_in_breeding/GAPIT_tetraploid.Rmd)
* Genomic prediction in rrBLUP using posterior mean genotypes -- [Tutorial on web](excellence_in_breeding/rrBLUP_tetraploid.html) -- [Download R markdown](excellence_in_breeding/rrBLUP_tetraploid.Rmd)

Friday, May 10

* [Software Carpentry lesson](https://swc-uiuc.github.io/2019-05-10-cip/)
* Calling variants without a reference genome using GBS-SNP-CROP -- [Tutorial on web](excellence_in_breeding/calling_without_reference.html) -- [Download markdown](https://raw.githubusercontent.com/lvclark/lvclark.github.io/master/excellence_in_breeding/calling_without_reference.md)
* Exploring and filtering VCFs using Bioconductor -- [Tutorial on web](excellence_in_breeding/vcf_filter.html) -- [Download R Markdown](excellence_in_breeding/vcf_filter.Rmd)


text:
[![Build Status](https://travis-ci.org/Amber-MD/ambertools-conda-build.svg?branch=master)](https://travis-ci.org/Amber-MD/ambertools-conda-build)
[circleci](https://circleci.com/gh/Amber-MD/ambertools-conda-build)

Build AmberTools with conda and docker. This is beta version.

- Update AmberTools version

```bash
    # change v16 to v17
    python scripts/update_ambertools_version.py 16 17
```

- centos:5 derived image is used.

- Proposed usage
```bash
    conda install -c http://ambermd.org/conda/ ambertools=16

    # current working version with python=3.5
    conda install -c hainm ambertools=16

    # search
    anaconda search ambertools
```

- How to build

    1. Make a git commit to this repo. Circleci (and travis) will do the rest.
    Built packages can retrieved from below url:

    ```bash
        https://circleci.com/gh/Amber-MD/ambertools-conda-build/{build_number}#artifacts/containers/0
        Note: Need to replace {build_number} by the commit number
        e.g:
        https://circleci.com/gh/Amber-MD/ambertools-conda-build/153#artifacts/containers/0
    ```

    2. Or: build locally
    - by docker container
    ```bash
        # update build.sh if needed
        sh build.sh
    ```

    - by conda
    ```bash
    conda build recipe
    ```

 - How continuous integration services are being used?

     - travis : test building ambermini, full ambertools with GNU compiler, not use docker.
     - circleci: test building ambermini with our ('ambermd/amber-build-box') docker image.
     - Why? just for testing

repository: hainm/ambertools-binary-build

repo_name: hainm/ambertools-binary-build


text:
# Hex to Decimal

## Description
Using loops implement a javascript function that converts a hex number number to its decimal representation.

## Input
- The input will consists of a single line containing a single hexadecimal number as string.

## Output
- The output should consist of a single line - the decimal representation of the number as string.

## Constraints
- All numbers will be valid 64-bit integers.
- Time limit: **0.1s**
- Memory limit: **16MB**

## Sample tests

|      Input        |      Output                  |
|-------------------|------------------------------|
| FE                | 254                          |
| 1AE3              | 6883                         |
| 4ED528CBB4        |<PHONE_NUMBER>84                 |

url: https://raw.githubusercontent.com/dushka-dragoeva/TelerikSeson2016/ecddeea2e02755f2096d580de653aa10ceb72bcd/Web Design and UI/JS Fundamentals/06. Loops/05. Hex to Decimal/README.md


text:
---
layout: doc_page
---

# Miscellaneous Tasks

## Noop Task

These tasks start, sleep for a time and are used only for testing. The available grammar is:

```json
{
    "type": "noop",
    "id": <optional_task_id>,
    "interval" : <optional_segment_interval>,
    "runTime" : <optional_millis_to_sleep>,
    "firehose": <optional_firehose_to_test_connect>
}
```

## Segment Merging Tasks (Deprecated)

### Append Task

Append tasks append a list of segments together into a single segment (one after the other). The grammar is:

```json
{
    "type": "append",
    "id": <task_id>,
    "dataSource": <task_datasource>,
    "segments": <JSON list of DataSegment objects to append>,
    "aggregations": <optional list of aggregators>,
    "context": <task context>
}
```

### Merge Task

Merge tasks merge a list of segments together. Any common timestamps are merged.
If rollup is disabled as part of ingestion, common timestamps are not merged and rows are reordered by their timestamp.

The grammar is:

```json
{
    "type": "merge",
    "id": <task_id>,
    "dataSource": <task_datasource>,
    "aggregations": <list of aggregators>,
    "rollup": <whether or not to rollup data during a merge>,
    "segments": <JSON list of DataSegment objects to merge>,
    "context": <task context>
}
```

### Same Interval Merge Task

Same Interval Merge task is a shortcut of merge task, all segments in the interval are going to be merged.

The grammar is:

```json
{
    "type": "same_interval_merge",
    "id": <task_id>,
    "dataSource": <task_datasource>,
    "aggregations": <list of aggregators>,
    "rollup": <whether or not to rollup data during a merge>,
    "interval": <DataSegment objects in this interval are going to be merged>,
    "context": <task context>
}
```

repository: chinpeng/druid

gha_language: Java

repo_name: chinpeng/druid


text:
# GPWM Project

## What's GPWM?

GPWM are the initials for *Gwynedd Purves Wynn-Aubrey Meredith's*

For the few who don't yet know, Major GPW Meredith, of the Seventh Heavy
Battery of the Royal Australian Artillery was the veteran commander of the
Australians against the Emus in the bloody [Emu War](https://en.wikipedia.org/wiki/Emu_War)
of 1932.

Here we honor his courage, sacrifice, and life-story by aptly naming an
*infrastructure-as-code* tool after his legacy.

##### The great GPW Meredith - Australian Hero

![The great GPW Meredith, Australian Hero](docs/gpwm.jpg "The great GPW Meredith")

##### Evil Emu - Enemy Of The State
![Evil Emu - Enemy Of The State](docs/emu.png "Evil Emu")

### Major GPW Meredith... Father, patriot and true hero. Lest we forget!

## Infrastructure as Code

The idea behind this is to allow for small, re-usable, independent, and readable infrastructure building blocks that different teams (networking/security/application) can own without affecting others, and allowing microservices in different environments and AWS accounts to be created just by modifying a set of values given to a template. 3 main components make up the system:

* Consumables: A YAML-like template rendered through a Python’s Mako engine that results in a CF template.
* Stacks (input values): A YAML file representing values that will be fed to a template (similar to the *–cli-input-json* option in the AWS CLI).
* Script: Interpolates the input values of a stack with a consumable and
  executes an action with the resulting rendered stack: creates, deletes,
  render, etc.

Cloudformation, GCP and pretty much all cloud providers infrastructure DSL have a few small deficiencies that make it somewhat hard to build reusable, concise, and easy to read templates, for example:

* No “for loops”.
* No high-level data structures like dictionaries or objects as variables.
* No ability to run custom code locally.
* Exports/Imports for linking stacks impose a hard dependency between stacks.

To address these shortcomings, the tool first uses a higher-level templating engine (Mako or Jinja) before sending the resulting stack to the cloud provider. This is not an abstraction layer like Terraform. The resulting template is an AWS Cloudformation stack, or GCP deployment, etc

## Usage Examples

```
pip install gpwm
export BUILD_ID="SOME_BUILD_ID"  # for example "$(date -u +'%F-%H-%M-%S')-$BITBUCKET_COMMIT"
export AWS_DEFAULT_PROFILE=some-profile
export AWS_DEFAULT_REGION=us-west-2

# getting help
python3 gpwm.py --help

# render: only print stack on screen
python3 gpwm.py render aws/stacks/vpc-training-dev.mako
python3 gpwm.py render google/deployments/instance.mako

# create: creates the stack in cloudformation
python3 gpwm.py create aws/stacks/vpc-training-dev.mako
python3 gpwm.py create google/deployments/instance.mako

# delete
python3 gpwm.py delete aws/stacks/vpc-training-dev.mako
python3 gpwm.py delete google/deployments/instance.mako

# update
python3 gpwm.py update aws/stacks/vpc-training-dev.mako
python3 gpwm.py update google/deployments/instance.mako

# update with review (change set)
python3 gpwm.py update aws/stacks/vpc-training-dev.mako -r
python3 gpwm.py update google/deployments/instance.mako -r

# Stack files can be fed via stdin (-t option must be used).
# Very handy when another tool is creating the stack file on the fly
cat my-stack.txt | python3 gpwm.py create -t jinja -
some-script.sh | python3 gpwm.py create -t jinja -
```

## Stacks

Amazon popularized the concept of "infrastructure as code" by proving a
declarative, standardized way for their users to describe what their
infrastructure should look like. Now, most reputable cloud providers offer their
own versions of templated, declarative resource managers:

* AWS: [Cloudformation](https://aws.amazon.com/cloudformation)
* Google Cloud: [Cloud Deployment Manager](https://cloud.google.com/free-trial/docs/map-aws-google-cloud-platform)
* Azure: [Resource Manager](https://azure.microsoft.com/en-us/features/resource-manager)
* Openstack: [Heat](https://docs.openstack.org/developer/heat/)
* Hashicorp: [Terraform](https://www.terraform.io/)

In this context, Stacks are text files that are processed through a templating
engine of choice, and must result in a YAML file after processing.
As of now, Mako and Jinja are supported, with raw Json and YAML in the roadmap
(if using these last two, the provider's CLI suffice)

These stacks are meant to represent resources in the cloud provider of choice,
either:

* Via the cloud provider's own *declarative* language which, describes the final state of the infrastructure
* Via commands or API calls used to get to that final states (*procedural* approach)

At this point, these types of stacks are supported:

* [Cloudformation](docs/aws.md) (declarative)
* [GCP](docs/gcp.md) (declarative)
* [Shell](docs/shell.md) (procedural)

Azure is in the roadmap.

Regardless of the provider, the idea behind this tool
is to never abstract, or dumb-down  the cloud provider's native
resource manager, only enhance it.

Also, the stacks/input files for each cloud provider try to use the syntax and
constructs native to the provider, instead of, for example, trying to make GCP
Deployment Manager configurations look similar to AWS Cloudformation stacks.
To illustrate, in AWS, the variable and section names used in a CFN stack are
 all *CamelCase*, while GCP uses *Python-style* (lowercase with underscores) in
its Deployment Manager configuration. This tool tries hard to keep that spirit,
so not to throw off users already familiar with a particular cloud provider's DSL.

### Why a higher level template engine? And why Mako as default?

A text templating engine extends the functionality of a CFN template or any
other text file by allowing "for loops", the use of more complex data types like
dictionaries and objects, and overall better readability by not having to deal
with CFN's hard-to-read intrinsic functions. On top of that, Mako allows for
inline python code right inside the template.

Mako is the default because it's very easy to define simple blocks of python
code inside the template, making it a very powerful tool. But to simplify the
lives of the folks familiar to Ansible, Saltstack, and others, Jinja is also
supported, but be warned that it's just not as flexible as Mako.

### Stack Types

* [Cloudformation](docs/aws.md)
* [GCP](docs/gcp.md)
* [Shell](docs/shell.md)

### Development

Follow the guidelines in the [development page](docs/development.md)

## Contacts
- Gustavo Baratto: gbaratto AT gmail

repository: tiadobatima/gpw

repo_name: tiadobatima/gpw


text:
# activate-power-mode-delete atom package
A package forked from [activate-power-mode](https://atom.io/packages/activate-power-mode). Original package was overwhelming, these effects are on delete only. Available through the Atom package installer (https://atom.io/packages/activate-power-mode-delete).

Activate with Ctrl-Alt-o or through the command panel with `Activate Power Mode: Toggle`. Use the command again to deactivate.

![activate-power-mode-0 4 0](https://cloud.githubusercontent.com/assets/688415/11615565/10f16456-9c65-11e5-8af4-265f01fc83a0.gif)

repository: valmassoi/activate-power-mode-delete

repo_name: valmassoi/activate-power-mode-delete


text:
# Taggers Server

This project is used for spinning up a server that runs a single cascade file.

When sentences are `POST` to the server, the response will be the output of the extractors--one per line.

repository: allenai/taggers

gha_language: Scala

repo_name: allenai/taggers


text:
# Template-Engine-Employee-Summary
## Description
This application helps to creat a webpage that contain basic employees' information. As a result, a manager can quickly gather his/her team members' information. This applicaiton is command-line interface when run it will ask the user information based on his/her role with the company. After the user finishes answering prompted questions, a `html` file will be created that contains information retrieved from the user's inputs.
## Installation
* Clone down this repository
* Install some dependencies by running `npm install` in the terminal. If no `package.jason` is present, run `npm init` before running `npm.install`
## Usage
* Open `app.js` in terminal
* Run `node app.js`
* Answer prompted questions
* A `team.html` that contains information from inputs will be created.

    ![demo](./develop/assets/demo.gif)

    ![screenshot](./develop/assets/Screenshot.png)
## Tech
* JAVASCRIPT
* HTML
* CSS
## Question
Github account: https://github.com/sarah-nguyen1993
If you have any questions, send me an email at<EMAIL_ADDRESS>## License
![badge](https://img.shields.io/badge/license-MIT-green)

branch_name: refs/heads/main


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

### Description

TP-Link TL-WR840N v5 00000005 devices allow XSS via the network name. The attacker must log into the router by breaking the password and going to the admin login page by THC-HYDRA to get the network name. With an XSS payload, the network name changed automatically and the internet connection was disconnected. All the users become disconnected from the internet.

### POC

#### Reference
- http://packetstormsecurity.com/files/153027/TP-LINK-TL-WR840N-Cross-Site-Scripting.html

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

repository: trickest/cve

gha_language: HTML

gha_license_id: MIT

repo_name: trickest/cve


text:
# Test Suite 16

**Release Branch Code List Management for Developer**

> Generally, the developer cannot do anything but viewing code lists.

## Test Case 16.1

**Code list access**

Pre-condition: The developer is on the View/Edit Code List page with a particular release branch selected.

### Test Assertion:

#### Test Assertion #16.1.1
The developer can see in the list both developer code lists and end user code lists created in the release. All developer code lists must be in the Published state.

#### Test Assertion #16.1.2
The developer can view the detail of a developer code list not owned by himself.

#### Test Assertion #16.1.3
The developer can view the detail of an end user code list (not owned by him) in any state, he cannot make any change, but he can add comment.

### Test Step Pre-condition:

### Test Step:

repository: OAGi/Score

repo_name: OAGi/Score


text:
# Idiopappus H.Rob. & Panero GENUS

#### Status
ACCEPTED

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

#### Published in
Syst. Bot. 19: -. [359-362]

#### Original name
null

### Remarks
null

repository: mdoering/backbone

repo_name: mdoering/backbone


text:
Lastly, to fully test the app, it must be able to connect to a server. For
this use case, Tekton supports the Kubernetes sidecar pattern and allows
developers to run another app, such as a mock server, alongside each step of
the task, which you will use in this section to run the tests.

`website/tutorials/katacoda/tasks/src/server` includes a Python server-side app that
listens at port 8080 and accepts connections from the client app. To run this
app as a sidecar in your task, edit `website/tutorials/katacoda/tasks/src/tekton-katacoda/tasks/taskTemplate.yaml`
for the last time:

```yaml
specs:
  steps:
  - name: ...
    image: ...
		script: |
		  #!/bin/bash
			...
    volumeMounts:
    ...
  # Ask the task to use the secret created earlier as a volume
  volumes:
  ...
  sidecars:
    # The name of the sidecar
  - name: example-server
    # The builder image to use
    image: python
    # The command to run with the builder image
		script: |
  		#!/bin/bash
      git clone https://github.com/tektoncd/website.git
			cd ./website/tutorials/katacoda/tasks/src/server
			pip install -r requirements.txt
			python main.py
```

With this setup, Tekton (Kubernetes) will run the step in the task and the
sidecar in the same pod, and they may communicate as if they are running side
by side on a local machine. The tests have been configured to use
`localhost:8080` as the address of the server.

Note that sidecars are started **before the task itself**; Tekton will stop
sidecars automatically after **all the steps in the task** have been completed.


text:
# Animations for QMK OLED displays

This repository contains some animations for [QMK](https://github.com/qmk/qmk_firmware)
keyboard firmware.

They are tested on my [Corne Keyboard](https://github.com/foostan/crkbd) build,
but should work just fine on any other with 128x32 OLED display (Lily58, Sofle, etc.).

You can preview all animations on [Demo page](demo.md)

# How to use

To use any of these you need to be building your firmware locally.
 Just put these in your `rules.mk`
file:

```
WPM_ENABLE = yes					# Enable word per minute counter
LTO_ENABLE = yes					# Makes hex file smaller
OLED_DRIVER_ENABLE = yes	# Enable OLEDs
```

`LTO_ENABLE` is not really required, but animations take a lot of space and it makes
firmware smaller. Otherwise you might not be able to flash your controller. Usually you
will need this if you're on ATMega/Pro Micro controllers. On STM chips theres plenty of
free flash memory, so you might just skip it.

## Setup OLED rotation

All animations assume you're using vertically mounted OLED (like in Corne). In the header of the animation
file there will be a suggested rotation option to set in your `keymap.c file`. It should be enough to just
put something like this at the beggining:

```c
#ifdef OLED_DRIVER_ENABLE
oled_rotation_t oled_init_user(oled_rotation_t rotation) {
  if (!is_master) {
    return OLED_ROTATION_180;
  }
  return rotation;
}
#endif
```

This will play animation only on secondary half of the keyboard. Adjust to your needs.

## Enable animation

Just copy all animation `.c` files to your keymap folder, include selected one at the top and use inside `keymap.c`:

```c
/**
 * Put this somewhere at the beginning of the file --
 * Make sure you import only one of animations at a time
 * They all have same function exported, so it won't compile if you
 * include more than one at a time. You can also configure some options
 * before including the animation. Not all animations support them, but some do :P.
 */
#define ANIM_INVERT false
#define ANIM_RENDER_WPM true
#define FAST_TYPE_WPM 45 //Switch to fast animation when over words per minute

#ifdef OLED_DRIVER_ENABLE
    #include "demon.c"
#endif

// -- Probably some other stuff and then --

#ifdef OLED_DRIVER_ENABLE
void oled_task_user(void) {
    if (!is_keyboard_master()) {
        oled_render_anim();
    }
}
#endif
```

Again, this assumes you have a split keyboard and want to display animation
on the secondary half. Adjust to your keyboard.

## Build and flash your firmware

For example:

```bash
make crkbd:marek:flash
```

# Troubleshooting

## My firmware is too big and won't flash

Animations take a lot of memory on the microcontroller. What you can do to still
make it work, is to disable backlight LED animations.

If you don't need them at all, just disable everything in `rules.mk`

```
RGBLIGHT_ENABLE = no
```

If you want to keep some simple LED backlight you can also try to disable most of them.
Here's what worked for me:

**Open `config.h` file in your keymap and:**

- Disable LED animations by commenting out `#define RGBLIGHT_ANIMATIONS`
- Remove all animation data from firmware by adding these:

```c
#    define DISABLE_RGB_MATRIX_ALPHAS_MODS
#    define DISABLE_RGB_MATRIX_GRADIENT_UP_DOWN
#    define DISABLE_RGB_MATRIX_BREATHING
#    define DISABLE_RGB_MATRIX_BAND_SAT
#    define DISABLE_RGB_MATRIX_BAND_VAL
#    define DISABLE_RGB_MATRIX_BAND_PINWHEEL_SAT
#    define DISABLE_RGB_MATRIX_BAND_PINWHEEL_VAL
#    define DISABLE_RGB_MATRIX_BAND_SPIRAL_SAT
#    define DISABLE_RGB_MATRIX_BAND_SPIRAL_VAL
#    define DISABLE_RGB_MATRIX_CYCLE_ALL
#    define DISABLE_RGB_MATRIX_CYCLE_LEFT_RIGHT
#    define DISABLE_RGB_MATRIX_CYCLE_UP_DOWN
#    define DISABLE_RGB_MATRIX_CYCLE_OUT_IN
#    define DISABLE_RGB_MATRIX_CYCLE_OUT_IN_DUAL
#    define DISABLE_RGB_MATRIX_RAINBOW_MOVING_CHEVRON
#    define DISABLE_RGB_MATRIX_DUAL_BEACON
#    define DISABLE_RGB_MATRIX_CYCLE_PINWHEEL
#    define DISABLE_RGB_MATRIX_CYCLE_SPIRAL
#    define DISABLE_RGB_MATRIX_RAINBOW_BEACON
#    define DISABLE_RGB_MATRIX_RAINBOW_PINWHEELS
#    define DISABLE_RGB_MATRIX_RAINDROPS
#    define DISABLE_RGB_MATRIX_JELLYBEAN_RAINDROPS
#    define DISABLE_RGB_MATRIX_TYPING_HEATMAP
#    define DISABLE_RGB_MATRIX_DIGITAL_RAIN
#    define DISABLE_RGB_MATRIX_SOLID_REACTIVE
#    define DISABLE_RGB_MATRIX_SOLID_REACTIVE_SIMPLE
#    define DISABLE_RGB_MATRIX_SOLID_REACTIVE_WIDE
#    define DISABLE_RGB_MATRIX_SOLID_REACTIVE_MULTIWIDE
#    define DISABLE_RGB_MATRIX_SOLID_REACTIVE_CROSS
#    define DISABLE_RGB_MATRIX_SOLID_REACTIVE_MULTICROSS
#    define DISABLE_RGB_MATRIX_SOLID_REACTIVE_NEXUS
#    define DISABLE_RGB_MATRIX_SOLID_REACTIVE_MULTINEXUS
#    define DISABLE_RGB_MATRIX_SPLASH
#    define DISABLE_RGB_MATRIX_MULTISPLASH
#    define DISABLE_RGB_MATRIX_SOLID_SPLASH
#    define DISABLE_RGB_MATRIX_SOLID_MULTISPLASH
```

This will still leave you few simple LED effects and free quite a lot of memory.

# Support

If you like this, maybe you'll also like some other stuff I'm working on:

- Ergonomic mechanical keyboards at [D1Keyboards](https://d1keyboards.com)
- JS Podcast (polish) ["Po Prostu JS"](https://poprostujs.pl)
- Or just drop me a line or check what's new at [@marekpiechut](https://twitter.com/marekpiechut)

repository: ilhsy/qmk-animations

repo_name: ilhsy/qmk-animations


text:
---
title: "hypre 2.17 Released"
categories: release
---

*hypre* is a library of high-performance preconditioners and solvers featuring multigrid methods for the solution of large, sparse linear systems of equations on massively parallel computers. [*hypre* version 2.17](https://github.com/hypre-space/hypre/releases/tag/v2.17.0) changes the license from GNU to [Apache 2.0](https://github.com/hypre-space/hypre/blob/master/LICENSE-APACHE)/[MIT](https://github.com/hypre-space/hypre/blob/master/LICENSE-MIT).

Learn more:

- [*hypre* GitHub repository](https://github.com/hypre-space/hypre)
- [HYPRE: Scalable Linear Solvers and Multigrid Methods](http://computing.llnl.gov/projects/hypre-scalable-linear-solvers-multigrid-methods/software)

gha_language: JavaScript


text:
# PdfWatermark

Add watermark to your pdf. two external gem will be used: combine_pdf and prawn.

## Installation

Add this line to your application's Gemfile:

```ruby
gem 'pdf_watermark'
```

And then execute:

    $ bundle

Or install it yourself as:

    $ gem install pdf_watermark

## Usage
```ruby
require 'pdf_watermark'

PdfWatermark.watermark("Private and Confidential", "content.pdf", "result.pdf", {:margin => 20,:angle=>:diagonal})
```
## Development

## Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/[USERNAME]/pdf_watermark. This project is intended to be a safe, welcoming space for collaboration, and contributors are expected to adhere to the [Contributor Covenant](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).


text:
m4_include(setup.m4)

# Interactive - 34 - explain

First you have to understand that different queries will work and perform in different
ways.  The biggest thing is the query hitting an index.  That is not the only thing.

```
m4_include(hw34_1.sql)
```

v.s.

```
m4_include(hw34_2.sql)
```

both produce the same results.  The first one will construct the set of data from the
join and then filter it for the user.  An index will not be used because of the `or` and
the `null`.

The 2nd one pre-filters the table `ct_homework_graded` for just the single user.  Since this is
an equal condition an index will be used and this smaller set of data then is then
used in the join.

First setup the tables and data for this  by running `hw34_5.sql`.

A better implementation of the 2nd form is (run file `hw34_3.sql`):

```
m4_include(hw34_3.sql)
```

This removes the now unnecessary query to check that it is a valid user id (on ct_login)
and uses a `with` to set up the per-user set of data.

The question is now how to figure out what the query planner is doing and what queries
need to be optimized.

#### Validate: SQL-Select,"select 'PASS' as x"

#### FilesToRun: hw34_5.sql
#### FilesToRun: hw34_3.sql

repository: andey-robins/school

repo_name: andey-robins/school


text:
# Contributing Guidelines

Thanks for contributing!
Any help is welcome, it can be on fix bug, add missing samples, code review, code improvement ...

## Issue
Ensure the bug was not already reported by searching on GitHub under [issues](https://github.com/JBonifay/irsdk_java/issues).
If you're unable to find an open issue addressing the bug, open a [new issue](https://github.com/JBonifay/irsdk_java/issues/new).

### Write detailed information
Detailed information is very helpful to understand an issue.

For example:
* How to reproduce the issue, step-by-step.
* The expected behavior (or what is wrong).
* The application version.
* The operating system.
* The sdk version

## Pull Requests
Ensure the Pull Request description clearly describes the changes you've made.
Branch should be named like the following:
- feat      Feature to add
- fix       Fix

## SDK Improvement
Actually three samples are working,
I'm not planning to rewrite all c++ samples,
if you want rewrite c++ sample to java it could be a great contribution !


text:
# AltitudeEstimation
A two-step Kalman/Complementary filter for Estimation of Vertical Position using an IMU-Barometer sytem.

**UPDATE**: I'm in the process of transforming this repository into an Arduino library. This readme will be updated accordingly. In the meantime, the original Python code can be found inside the `extras` folder.

**Note**: Although the core of the algorithm works, this project is still under development.

This work is an implementation of [this paper](http://www.koreascience.or.kr/article/ArticleFullRecord.jsp?cn=HSSHBT_2016_v25n3_202) written in 2016 by Jung Keun Lee. Although the original is in Korean you can find an English version of it [here](https://home.wlu.edu/~levys/TwoStepFilter.pdf) thanks to [Simon D. Levy](http://home.wlu.edu/~levys/).

This Python code is a prototype-implementation of the algorithm focused on its validation. The final goal is to implement it in [Hackflight](https://github.com/simondlevy/Hackflight), a simple C++ multirotor flight control firmware for Arduino and simulators. A first implementation of the algorithm already exists in Hackflight. Its current status of can be checked at the [branch](https://github.com/BonaDrone/Hackflight/tree/altitude-hold) `altitude-hold` of BonaDrone's Hackflight fork. Note that it is still under development.

## Requirements

* `numpy`
* `matplotlib` (only if you want to visualize results)
* `pyserial`

## Setup

### Hardware

The current setup used for testing consists in the [Butterfly STM32L433 Development Board](https://www.tindie.com/products/TleraCorp/butterfly-stm32l433-development-board/) plus the [MPU9250 Mini Add-On](https://www.tindie.com/products/onehorse/mpu9250-teensy-3x-add-on-shields/) connected through USB to the computer.

Yo can see it in the images below:

![Setup](https://i.imgur.com/XqFxrWS.png)

### Software

The Butterfly board is running [Hackflight](https://github.com/simondlevy/Hackflight). You can read how to work with it in [Hackflight's wiki](https://github.com/simondlevy/Hackflight/wiki). Since Hackflight is currently under development, to get this piece of software running you will have to follow a few additional steps.

First of all, you will need the [MS5637 Arduino library](https://github.com/BonaDrone/MS5637), originally developed by [Angus Gratton](https://github.com/projectgus), under your `Arduino/libraries` folder. Yo can simply open a terminal inside the directory and clone the repository.

Secondly, you should switch to BonaDrone's `proxy-data` [Hackflight's branch](https://github.com/BonaDrone/Hackflight/tree/proxy-data). This branch contains the code (under development) to read data from the baro and also proxy all the required values for the altitude estimation through the serial. To do so you can add BonaDrone's repo as a new remote and checkout the required branch. This can be done by opening a terminal session inside Hackflight's directory and typing:

`$ git remote add bonadrone https://github.com/BonaDrone/Hackflight.git`

`$ git checkout -b proxy-data bonadrone/proxy-data`

If you are working with different software, this program expects the data received through the serial to be in the format:

`ax, ay, az, gx, gy, gz, pressure, timestamp`

where `ax`, `ay` and `az` are measured in g-s, `gz`, `gy` and `gz` in radians per second and `pressure` in millibars.

Once this two things have been done it is time to load the firmware to the board and run this code.

**Important**: If using the above mentioned setup, the sensor calibration and bias computation is performed at startup. To get good results it is key to make sure that the board is properly orientated when powered up. The proper orientation is the one shown in the previous image (the one on the right).

## Usage

My current workflow to use this code, which is not as elegant as it could be is:

0. Check the port being used by the board and modify line 30 of `main.py` accordingly. Do the same with the baudrate (line 31) if you plan on using a different one.

1. Capture the terminal printed values into a log file:

		$ python main.py > log.txt

2. Wait a bit until the calibration is done and then perform the test. When done, force quit the program with `Ctr+C`

3. Open the logfile and remove the calibration rows (until the last column readings are `0.something`)

4. Run `plot_log.py` to get the plot of the data:

		$ python plot_log.py

## Parameter tunning

There are a few parameters that can be tuned to try to achieve higher accuracy. These paremeters are:

1. `DESIRED_DAMPLING`: Desired sampling period. If the real sampling period is bigger, the data will be oversampled by a linear interpolation of two real consecutive readings.
2. `sigma_accel`: standard deviation of the accelerometer
3. `sigma_gyro`: standard deviation of the gyroscope
4. `sigma_baro`: standard deviation of the barometer
5. `ca`:  constant value for the markov chain acceleration model: a(k) = ca * a(k-1) + e
6. `THRESHOLD`: vertical acceleration threshold. If 12 consecutive vertical acceleration values are below the threshold the vertical velocity will be set to 0.

## Results

Results are in  SI. All distance units are in meters and time units in seconds. This means that acceleration is measured in m/s^2, velocity is measured in m/s and height is measured in m.

### Test 1

This first results are from a test in which the board was lifted with the hand the whole length of the cable that connects it to the computer while being rotated 90 degress around the y-axis, then lowered to half the length of the cable while recovering its original orientation and finally lowered again to the ground.

![results](https://i.imgur.com/G41AnL9.png)

### Test 2

![results_2](https://i.imgur.com/nKng3K9.png)

### Test 3

![results_3](https://i.imgur.com/zbLWfzv.png)

### Test 4

Lift the board to the maximum length of the cable connecting it to the computer and lower it to the ground again 3 times. After that repeat the lift-lower procedure once but this time stopping at an altitude which is roughle the half of the cable before reaching the same altitude as before.

![results_4](https://i.imgur.com/cgBbNe5.png)

### Test 5

Lift the board to half the length of the cable. Wait and then go up the full length. Wait and go down to half the length of the cable. Go down to the ground. Wait. Lift to the full cable length and lower to the ground three times without stopping nor at the top or the bottom.

![results_5](https://i.imgur.com/UQJxBX7.png)

### Hackflight's test 1

A first and unpolished first version of the algorithm presented in the paper has been implemented in Hakflight. The code can be found at  the [`altitude-hold`](https://github.com/BonaDrone/Hackflight/tree/altitude-hold) branch of BonaDrone's fork. The results of a first test can be observed in the image below, which is a direct screenshot of Arduino's IDE Serial plotter. The color legend is as follows:

* **Blue**: Estimated vertical acceleration (m/s^2).
* **Red**: Estimated vertical velocity (m/s).
* **Green**: Estimated altitude from barometer pressure readings (m).
* **Yellow**: Two step Kalman/Complementary filter estimated altitude (m).

![real_drone_results](https://i.imgur.com/Dlwrvk2.png)


text:
# dataprocess

## Usage:
```mvn clean verify exec:java -Dexec.args=C:\SPY.csv```

### Results
- rundir \ ```future```  folder with iteration files
- ```past.json``` at rundir

### Example run
```[INFO] Scanning for projects...
   [INFO]
   [INFO] ------------------------------------------------------------------------
   [INFO] Building dataprocess LATEST
   [INFO] ------------------------------------------------------------------------
   [INFO]
   [INFO] --- maven-clean-plugin:2.5:clean (default-clean) @ dataprocess ---
   [INFO] Deleting C:\Users\Balint Csikos\IdeaProjects\dataprocess\target
   [INFO]
   [INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ dataprocess ---
   [WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
   [INFO] Copying 1 resource
   [INFO]
   [INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ dataprocess ---
   [INFO] Changes detected - recompiling the module!
   [WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
   [INFO] Compiling 1 source file to C:\Users\Balint Csikos\IdeaProjects\dataprocess\target\classes
   [INFO]
   [INFO] --- maven-resources-plugin:2.6:testResources (default-testResources) @ dataprocess ---
   [WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
   [INFO] Copying 0 resource
   [INFO]
   [INFO] --- maven-compiler-plugin:3.1:testCompile (default-testCompile) @ dataprocess ---
   [INFO] Changes detected - recompiling the module!
   [WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
   [INFO] Compiling 1 source file to C:\Users\Balint Csikos\IdeaProjects\dataprocess\target\test-classes
   [INFO]
   [INFO] --- maven-surefire-plugin:2.12.4:test (default-test) @ dataprocess ---
   [INFO] Surefire report directory: C:\Users\Balint Csikos\IdeaProjects\dataprocess\target\surefire-reports
   Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-junit4/2.12.4/surefire-junit4-2.12.4.pom
   Downloaded: https://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-junit4/2.12.4/surefire-junit4-2.12.4.pom (3 KB at 3.7 KB/sec)
   Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-providers/2.12.4/surefire-providers-2.12.4.pom
   Downloaded: https://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-providers/2.12.4/surefire-providers-2.12.4.pom (3 KB at 21.2 KB/sec)
   Downloading: https://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-junit4/2.12.4/surefire-junit4-2.12.4.jar
   37/37 KB   Downloaded: https://repo.maven.apache.org/maven2/org/apache/maven/surefire/surefire-junit4/2.12.4/surefire-junit4-2.12.4.jar (37 KB at 92.9 KB/sec)

   -------------------------------------------------------
    T E S T S
   -------------------------------------------------------
   Running com.fincance.dataprocess.EntrypointTest
   Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.101 sec

   Results :

   Tests run: 1, Failures: 0, Errors: 0, Skipped: 0

   [INFO]
   [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ dataprocess ---
   [INFO] Building jar: C:\Users\Balint Csikos\IdeaProjects\dataprocess\target\dataprocess-LATEST.jar
   [INFO]
   [INFO] >>> exec-maven-plugin:1.2.1:java (default-cli) > validate @ dataprocess >>>
   [INFO]
   [INFO] <<< exec-maven-plugin:1.2.1:java (default-cli) < validate @ dataprocess <<<
   [INFO]
   [INFO] --- exec-maven-plugin:1.2.1:java (default-cli) @ dataprocess ---
   127 ms for thread #27
   139 ms for thread #25
   124 ms for thread #30
   79 ms for thread #15
   <<output truncated for 10000 iteration>>
   11 ms for thread #18
   11 ms for thread #18
   10 ms for thread #18
   44894 ms
   [INFO] ------------------------------------------------------------------------
   [INFO] BUILD SUCCESS
   [INFO] ------------------------------------------------------------------------
   [INFO] Total time: 49.375 s
   [INFO] Finished at: 2017-05-26T01:01:03+02:00
   [INFO] Final Memory: 18M/292M
   [INFO] ------------------------------------------------------------------------
```

## Issues
- does not handles whitespaces in ```exec.args```. Workaround: use ```"``` , escape or avoid whitespaces in path

## Todo / Refactor
 - file write can be extracted
 - pool size could be optimalized
 - random UUID for output file could be reviewed

repository: csikosbalint/dataprocess

repo_name: csikosbalint/dataprocess


text:
# ExpJavaScriptMVC

At the time being, without plans to develop the C part ...

This is a framework for building Dynamic Web Applications using only Javascript code
(no server code!). The server should work fine with the super-powerful webserver
that is started with: `python -m SimpleHTTPServer`

Check a live working example at http://fabriceleal.github.io/ExpJavascriptMVC/index.html

Currently waiting for some time; I have to rewrite the mvc.js, as I need to have
access to the node and the data at once, and for now it is impossible :(

repository: fabriceleal/ExpJavascriptMVC

repo_name: fabriceleal/ExpJavascriptMVC


text:
---
type: TutorialStep
date: 2017-07-07
title: Debugging During Testing With NodeJS
technologies: [nodejs, jest]
topics: []
author: pwe
subtitle: Use the visual debugger in the IDE for smarter TDD.
thumbnail: ./thumbnail.png
longVideo:
  poster: ./poster_long.png
  url: https://www.youtube.com/watch?v=yVaTqKqWT20
---

In the [previous step](../testing/) we used testing as a way to
develop our component without switching to a browser.

Sometimes our code has problems that require investigation with a debugger.
For React, that usually means a trip to the browser to set a breakpoint and
use the Chrome developer tools. Let's show how the IDE's debugger, combined
with TDD, can make this investigation far more productive.

## Code

The finished code for this tutorial step is
[in the repository](https://github.com/JetBrains/jetbrains_guide/tree/master/sites/pycharm-guide/demos/tutorials/react_typescript_tdd/nodejs_debugging/).

## Cleanup

First, let's remove some unused code from our first test,
`renders without crashing`. Delete the last 3 lines and leave it as:

```typescript
it('renders without crashing', () => {
    const div = document.createElement('div');
    ReactDOM.render(<App/>, div);
    ReactDOM.unmountComponentAtNode(div);
});
```

## Hello Parameter

Let's use TDD to make our component's greeting a bit more
dynamic. Start in the side-by-side mode described in the previous section,
with both `App.tsx` and `App.test.tsx` open.

First, add a method to the `App` class, above the `render` method:

```jsx
label() {
    return 'Hello React';
}
```

The IDE gives us two warnings:

- The method can be static

- The method is unused

We'll ignore both of those, as development below will change both
warnings.

Then, in `render`, change the `<h1>` to use the output of this method,
using autocompletion for the method name:

```jsx
<h1>{this.label()}</h1>
```

We didn't write a test first. That's sort of ok: we didn't change the
rendering itself. But we also didn't test the method. Let's do that now by
adding a test in `App.test.tsx`:

```typescript
it('generates a label', () => {
    const a = new App({});
    expect(a.label()).toBe('Hello React');
});
```

In this test we don't need a component with TSX and a fake DOM etc. It's a
TypeScript method that returns a string. Nice! To conform to the
`React.Component` constructor signature, we pass in an empty object as
props. Note how the IDE gave us a placeholder reminder.

Let's make the method slightly dynamic by passing in a name for the label,
then converting that name to uppercase. First, change our tests to the
behavior we expect. The `generates a label` test needs its last line
changed to:

```typescript
expect(a.label('React')).toBe('Hello REACT');
```

While we're at it, change the `renders a heading` test to look for
`REACT` instead of `React`.

Our tests now fail, thus we need to implement this feature. Moreso,
the TypeScript compiler is helping us "fail faster", telling us we broke
the contract, even before the test runs. Nice squared!

The `<h1>`, like the test, needs to pass in a value:

```typescript
    <h1>{this.label('React')}</h1>
```

Now it's just a matter of changing the method to accept an argument, then
uppercasing the return value:

```typescript
label(name) {
    return `Hello ${name.toUpperCase()}`;
}
```

Note that the IDE has a quick fix, via `Alt-Enter`, to convert the string
to an ES6 template string (the backticks.)

With that, our tests pass, but the TypeScript compiler is angry: the `name`
argument doesn't have a supplied type. Let's fix that:

```typescript
label(name: string) {
    return `Hello ${name.toUpperCase()}`;
}
```

No surprise: the IDE has an `Alt-Enter` quick fix for this -- in this
case, `Infer parameter types from usage`.

## Stop at Breakpoint

Let's see debugging in action. Imagine we pass in a number and we can't
figure out why our method is failing.

Let's do so. In the last `generates a label` test, change the argument to
`a.label(42)`.

First, note that TypeScript told our test that the supplied value was not
assignable to a string. This is the *beauty* of TypeScript. Especially in
test-writing, it helps you "fail faster". Meaning, when paired with a smart
IDE, it moves the failure directly under your eyeballs, in the most immediate
location...the place where you typed it. Moreover, it provides very specific
error messages.

Let's go ahead and debug this. Click in the gutter beside that line to set
a breakpoint. Then right-click on the test in the tool window and run it
under the debugger. Execution stops on that line. We can then step into our
method call.

![Set Breakpoint](./screenshots/set_breakpoint.png)

Execution stops in our method. We can inspect the local values and see that
`name` is `42`.

![Stop At Breakpoint](./screenshots/stop_at_breakpoint.png)

We can now poke and prod our code interactively, in the execution context
where it fails.

![Evaluate Expression](./screenshots/evaluate_expression.png)

This is a very productive development cycle: write tests,
when stuck, use the debugger. No flailing around with `console.log` in a
browser's dev tools window.

Let's clean up:

- Click the red square to stop the debugger

- Close the Debugger tool tab window

- Click the red circle to clear the breakpoint

- Change the test's label argument from `42` back to `React`

- Re-open the Run Tool window

As a note, in this step, the only two files that changed were
`App.tsx` and `App.test.tsx`.


text:
# jobs - a Job scheduler for load regulation #

Copyright (c) 2014-2018 Ulf Wiger

__Version:__ 0.9.0

JOBS
====

Jobs is a job scheduler for load regulation of Erlang applications.
It provides a queueing framework where each queue can be configured
for throughput rate, credit pool and feedback compensation.
Queues can be added and modified at runtime, and customizable
"samplers" propagate load status across all nodes in the system.

Specifically, jobs provides three features:

* Job scheduling: A job is scheduled according to certain constraints.
For instance, you may want to define that no more than 9 jobs of a
certain type can execute simultaneously and the maximal rate at
which you can start such jobs are 300 per second.
* Job queueing: When load is higher than the scheduling limits
additional jobs are *queued* by the system to be run later when load
clears. Certain rules govern queues: are they dequeued in FIFO or
LIFO order? How many jobs can the queue take before it is full? Is
there a deadline after which jobs should be rejected. When we hit
the queue limits we reject the job. This provides a feedback
mechanism on the client of the queue so you can take action.
* Sampling and dampening: Periodic samples of the Erlang VM can
provide information about the health of the system in general. If we
have high CPU load or high memory usage, we apply dampening to the
scheduling rules: we may lower the concurrency count or the rate at
which we execute jobs. When the health problem clears, we remove the
dampener and run at full speed again.

Error recovery
--------------

The Jobs server is designed to not crash. However, in the unlikely event
that it should occur (and it has!) Jobs does not automatically restore changes
that have been effected through the API. This can be enabled, setting the
Jobs environment variable `auto_restore` to `true`, or calling the function
`jobs_server:auto_restore(true)`. This will tell the jobs_server to remember
every configuration change and replay them, in order, after a process restart.

Examples
--------

The following examples are fetched from the EUC 2013 presentation on Jobs.

#### Regulate incoming HTTP requests (e.g. JSON-RPC) ####

```erlang

%% @doc Handle a JSON-RPC request.
handler_session(Arg) ->
    jobs:run(
        rpc_from_web,
        fun() ->
               try
                  yaws_rpc:handler_session(
                    maybe_multipart(Arg),{?MODULE, web_rpc})
               catch
                   error:E ->
                       ...
               end
    end).

```

#### From Riak prototype, using explicit ask/done ####

```erlang

case jobs:ask(riak_kv_fsm) of
  {ok, JobId} ->
    try
      {ok, Pid} = riak_kv_get_fsm_sup:start_get_fsm(...),
      Timeout = recv_timeout(Options),
      wait_for_reqid(ReqId, Timeout)
    after
      jobs:done(JobId)  %% Only needed if process stays alive
    end;
  {error, rejected} ->  %% Overload!
    {error, timeout}
end

```

#### Shell demo - simple rate-limited queue ####

```erlang

2> jobs:add_queue(q, [{standard_rate,1}]).
ok
3> jobs:run(q, fun() -> io:fwrite("job: ~p~n", [time()]) end).
job: {14,37,7}
ok
4> jobs:run(q, fun() -> io:fwrite("job: ~p~n", [time()]) end).
job: {14,37,8}
ok
...
5> jobs:run(q, fun() -> io:fwrite("job: ~p~n", [time()]) end).
job: {14,37,10}
ok
6> jobs:run(q, fun() -> io:fwrite("job: ~p~n", [time()]) end).
job: {14,37,11}
ok

```

#### Shell demo - "stateful" queues ####

```erlang

Eshell V5.9.2 (abort with ^G)
1> application:start(jobs).
ok
2> jobs:add_queue(q,
     [{standard_rate,1},
      {stateful,fun(init,_) -> {0,5};
                   ({call,{size,Sz},_,_},_) -> {reply,ok,{0,Sz}};
                   ({N,Sz},_) -> {N, {(N+1) rem Sz,Sz}}
                end}]).
ok
3> jobs:run(q,fun(Opaque) -> jobs:job_info(Opaque) end).
0
4> jobs:run(q,fun(Opaque) -> jobs:job_info(Opaque) end).
1
5> jobs:run(q,fun(Opaque) -> jobs:job_info(Opaque) end).
2
6> jobs:run(q,fun(Opaque) -> jobs:job_info(Opaque) end).
3
7> jobs:run(q,fun(Opaque) -> jobs:job_info(Opaque) end).
4
8> jobs:run(q,fun(Opaque) -> jobs:job_info(Opaque) end).
0
9> jobs:run(q,fun(Opaque) -> jobs:job_info(Opaque) end).
1
%% Resize the 'pool'
10> jobs:ask_queue(q, {size,3}).
ok
11> jobs:run(q,fun(Opaque) -> jobs:job_info(Opaque) end).
0
12> jobs:run(q,fun(Opaque) -> jobs:job_info(Opaque) end).
1
13> jobs:run(q,fun(Opaque) -> jobs:job_info(Opaque) end).
2
14> jobs:run(q,fun(Opaque) -> jobs:job_info(Opaque) end).
0
...

```

#### Demo - producers ####

```erlang

Eshell V5.9.2 (abort with ^G)
1> application:start(jobs).
ok
2> jobs:add_queue(p,
  [{producer, fun() -> io:fwrite("job: ~p~n",[time()]) end},
   {standard_rate,1}]).
job: {14,33,51}
ok
3> job: {14,33,52}
job: {14,33,53}
job: {14,33,54}
job: {14,33,55}
...

```

#### Demo - passive queues ####

```erlang

2> jobs:add_queue(q,[passive]).
ok
3> Fun = fun() -> io:fwrite("~p starting...~n",[self()]),
3>                Res = jobs:dequeue(q, 3),
3>                io:fwrite("Res = ~p~n", [Res])
3>       end.
#Fun<erl_eval.20.82930912>
4> jobs:add_queue(p, [{standard_counter,3},{producer,Fun}]).
<0.47.0> starting...
<0.48.0> starting...
<0.49.0> starting...
ok
5> jobs:enqueue(q, job1).
Res = [{113214444910647,job1}]
ok
<0.54.0> starting...

```

#### Demo - linked queues ####

```erlang
3> Pid = spawn(fun() -> receive stop -> ok end end).
<0.131.0>
4> jobs:add_queue(q, [{standard_rate,1}, {link, Pid}]).
ok
5> jobs:run(q, fun() -> io:fwrite("job: ~p~n", [time()]) end).
job: {19,33,37}
ok
6> exit(Pid, kill).

=INFO REPORT==== 29-May-2020::19:33:45 ===
    jobs: removing_queue
    name: q
    reason: linked
true
7> jobs:run(q, fun() -> io:fwrite("job: ~p~n", [time()]) end).
** exception error: bad argument
     in function  jobs_server:call/3 (/home/uwiger/uw/jobs/src/jobs_server.erl, line 236)
     in call from jobs_server:run/2 (/home/uwiger/uw/jobs/src/jobs_server.erl, line 117)
8> jobs:queue_info(q).
undefined
```

#### Demo - queue status ####

```erlang

(a@uwair)1> jobs:queue_info(q).
{queue,[{name,q},
        {mod,jobs_queue},
        {type,fifo},
        {group,undefined},
        {regulators,[{rr,[{name,{rate,q,1}},
                          {rate,{rate,[{limit,1},
                          {preset_limit,1},
                          {interval,1.0e3},
                          {modifiers,
                           [{cpu,10},{memory,10}]},
                          {active_modifiers,[]}
                         ]}}]}]},
        {max_time,undefined},
        {max_size,undefined},
        {latest_dispatch,113216378663298},
        {approved,4},
        {queued,0},
        ...,
        {stateful,undefined},
        {st,{st,45079}}]}

```
---------

##Scenarios and Corresponding Configuration Examples

####EXAMPLE 1:
* Add counter regulated queue called ___heavy_crunches___ to limit your cpu intensive code executions to no more than 7 at a time

Configuration:

```erlang

{ jobs, [
    { queues, [
        { heavy_crunches, [ { regulators, [{ counter, [{ limit, 7 }] } ] }] }
      ]
    }
  ]
}

```

Anywhere in your code wrap cpu-intensive work in a call to jobs server and-- __voilà!__ --it is counter-regulated:

```erlang

jobs:run( heavy_crunches,fun()->my_cpu_intensive_calculation() end)

```

####EXAMPLE 2:
* Add rate regulated queue called ___http_requests___ to ensure that your http server gets no more than 1000 requests per second.
* Additionally, set the queue size to 10,000 (i.e. to control queue memory consumption)

Configuration:

```erlang

{ jobs, [
      { queues, [
            { http_requests, [ { max_size, 10000},  {regulators, [{ rate, [{limit, 1000}]}]}]}
        ]
      }
  ]
}

```

Wrap your request entry point in a call to jobs server and it will end up being rate-regulated.

```erlang

jobs:run(http_requests,fun()->handle_http_request() end)

```

NOTE: with the config above, once 10,000 requests accumulates in the queue any incoming requests are dropped on the floor.

####EXAMPLE 3:
* HTTP requests will always have a reasonable execution time.  No point in keeping them in the queue past the timeout.

* Let's create ___patient_user_requests___ queue that will keep requests in the queue for up to 10 seconds

```erlang

{ patient_user_requests, [
    { max_time, 10000},
    { regulators, [{rate, [ { limit, 1000 } ] }
  ]
}

```

* Let's create ___impatient_user_requests___ queue that will keep requests in the queue for up to 200 milliseconds.
Additionally, we'll make it a LIFO queue. Unfair, but if we assume that happy/unhappy is a boolean
we're likely to maximize the happy users!

```erlang

{ impatient_user_requests, [
    { max_time, 200},
    { type, lifo},
    { regulators, [{rate, [ { limit, 1000 } ] }
  ]
}

```

NOTE: In order to pace requests from both queues at 1000 per second, use __group_rate__ regulation (EXAMPLE 4)

####EXAMPLE 4:
* Rate regulate http requests from multiple queues

Create __group_rates__ regulator called ___http_request_rate___  and assign it to both _impatient_user_requests_ and _patient_user_requests_

```erlang

{ jobs, [
    { group_rates,[{ http_request_rate, [{limit,1000}] }] },
    { queues, [
        { impatient_user_requests,
            [ {max_time, 200},
              {type, lifo},
              {regulators,[{ group_rate, http_request_rate}]}
            ]
        },
        { patient_user_requests,
            [ {max_time, 10000},
              {regulators,[{ group_rate, http_request_rate}
            ]
        }
      ]
    }
  ]
}

```

####EXAMPLE 5:
* Can't afford to drop http requests on the floor once max_size is reached?
* Implement and use your own queue to persist those unfortunate http requests and serve them eventually

```erlang

 -module(my_persistent_queue).
 -behaviour(jobs_queue).
 -export([  new/2,
            delete/1,
            in/3,
            out/2,
            peek/1,
            info/2,
            all/1]).

 ## implementation
 ...

```

Configuration:

```erlang

{ jobs, [
    { queues, [
        { http_requests, [
            { mod, my_persistent_queue},
            { max_size, 10000 },
            { regulators, [ { rate, [ { limit, 1000 } ] } ] }
          ]
        }
      ]
    }
  ]
}

```

###The use of sampler framework
1. Get a sampler running and sending feedback to the jobs server.
2. Apply its feedback to a regulator limit.

####EXAMPLE 6:
* Adjust rate regulator limit on the fly based on the feedback from __jobs_sampler_cpu__ named ___cpu_feedback___

```erlang

{ jobs, [
    { samplers, [{ cpu_feedback, jobs_sampler_cpu, [] } ] },
    { queues, [
        { http_requests, [
            { regulators,   [ { rate, [ { limit,1000 } ]  },
            { modifiers,    [ { cpu_feedback,  10} ] } %% 10 = % increment by which to modify the limit
          ]
        }
      ]
    }
  ]
}

```

Prerequisites
-------------
This application requires 'exprecs'.
The 'exprecs' module is part of http://github.com/uwiger/parse_trans

Contribute
----------
For issues, comments or feedback please [create an issue!] [1]

[1]: http://github.com/uwiger/jobs/issues "jobs issues"

## Modules ##

jobs

jobs_app

jobs_info

jobs_lib

jobs_prod_simple

jobs_queue

jobs_queue_list

jobs_sampler

jobs_sampler_cpu

jobs_sampler_history

jobs_sampler_mnesia

jobs_stateful_simple

repository: uwiger/jobs

gha_language: Erlang

repo_name: uwiger/jobs


text:
---
layout: post
title: Counts Vowels Permutation
subtitle: Leetcode Daily Challenge
date: 2021-07-04
author: Haoran
header-img: img/post-bg-2015.jpg
catalog: true
tags:
  - Leetcode
  - Algorithm
  - Daily Challenge
---

## Problem

Given an integer n, your task is to count how many strings of length n can be formed under the following rules:

Each character is a lower case vowel ('a', 'e', 'i', 'o', 'u')
Each vowel 'a' may only be followed by an 'e'.
Each vowel 'e' may only be followed by an 'a' or an 'i'.
Each vowel 'i' may not be followed by another 'i'.
Each vowel 'o' may only be followed by an 'i' or a 'u'.
Each vowel 'u' may only be followed by an 'a'.
Since the answer may be too large, return it modulo 10^9 + 7.

1 <= n <= 2 \* 10^4

## Thinking

- Use a state machine, backtracking all possible ways

- Second thought after reading the hints: dynamic programming. arr[i][j] equals to the number of ways length i ends with vowel j

- Relations:

  - dp[i+1][a] = dp[i]['e'] + dp[i]['i'] + dp[i]['u']
  - dp[i+1][e] = dp[i]['a'] + dp[i]['i']
  - dp[i+1][i] = dp[i]['e'] + dp[i]['o']
  - dp[i+1][o] = dp[i]['i']
  - dp[i+1][u] = dp[i]['o'] + dp[i]['i']

- Map:
  - 'a' : 0
  - 'e' : 1
  - 'i' : 2
  - 'o' : 3
  - 'u' : 4

```python
from typing import List

def countVowelPermutation(n: int) -> int:
    dp = [[0 for j in range(5)] for i in range(n + 1)]
    moduler = 1e9 + 7
    for j in range(5):
        dp[1][j] = 1

    for i in range(2, n + 1):
        dp[i][0] = (dp[i-1][1] + dp[i-1][4] + dp[i-1][2]) % moduler
        dp[i][1] = (dp[i-1][0] + dp[i-1][2]) % moduler
        dp[i][2] = (dp[i-1][1] + dp[i-1][3]) % moduler
        dp[i][3] = dp[i-1][2] % moduler
        dp[i][4] = (dp[i-1][3] + dp[i-1][2]) % moduler

    return int(sum(dp[n]) % moduler)

if __name__ == "__main__":
    print(countVowelPermutation(5))
```


text:
# solax

Solax inverter to MQTT daemon

## Command Line Options

```cmdline
Usage of ./solax:
  -cfg string
        Configuration file to parse for database settings (default "configuration.yaml")
  -daemon
        Run as daemon? [default false]
```

When run without the -daemon flag the app will simply read all available values and print them to stdout.

## Configuration

Configuration is done via a YAML file with a default name of configuration.yaml.

## HomeAssistant Discovery

When run in daemon mode, configuration will be published for HA to automatically configure the available sensors.

This has been running well for me for a while now and should be stable. Suggestions and improvements always welcome.

license: Unlicense


text:
---
layout: post
title: Sequence to Sequence
subtitle: Deep Learning Course Note (Part 7)
date: 2019-02-27
published: True
mathjax: True
catalog: true
tags:
  - deep learning
  - machine learning
  - 学习笔记-course note
  - 公开课-MOOC
---
# TOC
1. Introduction
{:toc}

# Introduction
This is the course notes of deep learning specialization.

The sequence to sequence (seq2seq) model is based on encoder-decoder architecture to generate a sequence output from a sequence input. It's mainly applied in machine translation, speech recognition and so on. When predicting, it utilizes beam search to improve the performance.

# Encoder-decoder Architecture

Encoder-decoder is a neural network design pattern which consists of encoder and decoder. The encoder's role is to encode the state into state. Then the decoder can utilize the state to generate the output. It can be used in machine translation, image captions and so on.

# Seq2seq

## Model Training

Below the training process for machine translation task:

## Prediction with Beam Search

The conditional probability of generating a sequence based on the input is: $\prod_{t=1}^{T_y}P(y^{\<t\>}\|x,y^{\<1\>}...y^{\<t-1\>})$. In order to get a optimal sequence, we should apply search methods to maximize this probability.

For **greedy search** method, we search for the word that with the highest probability at this timestep. However, the optimal sequence can not be guaranteed. By examing all the possible sequences, the **exhaustive search** method can output the sequence with highest conditional probability. However, it can be slow. **Beach search** is an improved algorithms based on greedy search. At each timestep, we select k(beam size) word that with the highest probalities. We'll take the sequence with the highest score which can be calculated by: $\frac{1}{T_y^{\alpha}}\sum_{t=1}^{T_y}P(y^{\<t\>}\|x,y^{\<1\>}...y^{\<t-1\>})$. Here, $T_y$ is the length of final candidate sequence and the selection of $\alpha$ is general 0.75.

# Reference
1. [Dive Into Deep Learning Chapter 9: Modern Recurrent Neural Network](https://d2l.ai/)