text:
[![Build Status](https://travis-ci.org/pushpop-project/pushpop.svg)](https://travis-ci.org/pushpop-project/pushpop)

### A framework for scheduled integrations between popular services

## Overview

Use Pushpop to schedule and run ongoing integrations between your favorite services. With Pushpop you can easily say "send data from Service A to Service B every 5 minutes". The services and the interval are entirely configurable, and you can have as many steps as you like.

Pushpop began as a way to send notifications and reports based on events captured with [Keen IO](https://keen.io).

See the [Plugins](#plugins) section of this README for more services.

Pushpop is packaged as a Ruby gem. It can be added to existing Ruby projects or used in new ones.

#### Ideas for using Pushpop

##### Alerts

+ Send an email when your site has been busier than usual in the last hour
+ Send an SMS if the performance of your signup funnel dramatically changes

##### Recurring reports

+ Send a sales report to your inbox every day at noon
+ Send analytics reports to your customers every week

##### Monitoring

+ Track the performance of web services and APIs
+ Read sensor values for analysis and alerting

#### Example Pushpop job

Pushpop organizes work into jobs. Here's a Pushpop job that uses the `keen` and `sendgrid` plugins to send a nightly email. The email contains the day's number of pageviews:

``` ruby
require 'pushpop-keen'
require 'pushpop-sendgrid'

job do

  every 24.hours, at: '00:00'

  keen do
    event_collection  'pageviews'
    analysis_type     'count'
    timeframe         'last_24_hours'
  end

  sendgrid do |response, _|
    to<EMAIL_ADDRESS>    from<EMAIL_ADDRESS>    subject   'Pushpop Daily Pageviews Report'
    body      "There were #{response} pageviews today!"
  end

end
```

Keen IO provides the analytics data behind the report. The email is sent by [Sendgrid](https://sendgrid.com) via the [sendgrid](https://github.com/pushpop-project/pushpop-sendgrid) Pushpop plugin.

Pushpop syntax is short and sweet, but because Pushpop is pure Ruby it's also quite powerful.

## Quickstart

Install Pushpop as a Ruby gem:

```
$ gem install pushpop
```

You should now have a `pushpop` command available in your shell. Try it out with no arguments to see a list of possible commands:

```
$ pushpop
Commands:
  pushpop help [COMMAND]  # Describe available commands or one specific command
  pushpop jobs:describe   # Describe jobs
  pushpop jobs:run        # Run jobs ongoing
  pushpop jobs:run_once   # Run jobs once
  pushpop version         # Print the Pushpop version
```

##### Create a simple job

Copy the code below into a file called `example_job.rb`. This job simply prints output to the console:

``` ruby
require 'pushpop'

job do

  every 1.seconds

  step do
    puts 'Hello World!'
  end

end
```

Run this job once via using the `jobs:run_once` command:

``` shell
$ pushpop jobs:run_once --file example_job.rb
```

You should see the following output:

``` html
Hello World!
```

That's all there is to it. To run the job repeatedly at the times specified by `every` just change `run_once` to `run`:

``` shell
$ pushpop jobs:run --file example_job.rb
```

Make sure to leave the process running in your terminal, or [send it to the background](http://stackoverflow.com/questions/625409/how-do-i-put-an-already-running-process-under-nohup), so that it keeps running.

##### Next steps

+ Write and test more jobs. See the [Pushpop API Documentation](#pushpop-api-documentation) below for more examples of what you can do.
+ See the [pushpop-project](https://github.com/pushpop-project) Github organization to find plugins and reusable code.

## Pushpop Commands

Pushpop comes with commands to describe and run jobs.

All `jobs:*` commands optionally take a filename or directory as a `--file` or `-f` parameter. The file/directory is meant to contain one or more Pushpop jobs.

Specifying a specific file looks like this:

``` shell
$ pushpop jobs:run --file jobs/just_this_job.rb
```

Here's a list of the available commands:

+ `jobs:describe` - Print out the names of jobs in the jobs folder.
+ `jobs:run_once` - Run each job once, right now.
+ `jobs:run` - Run jobs as scheduled in a long-running process. This is the command you should use for a deployed Pushpop.

All `jobs:*` tasks also use [dotenv](https://github.com/bkeepers/dotenv) to load environment variables, often contained in a `.env` file.

## Pushpop API Documentation

Steps and jobs are the heart of the Pushpop workflow. Job files are written in pure Ruby and contain one or more jobs. Each job consists of one or more steps.

#### Jobs

Jobs have the following attributes:

+ `name`: (optional) something that describe the job, useful in logs
+ `period`: how frequently to run the job; the first param to `every`
+ `every_options` (optional): options related to when the job runs; the second param to `every`
+ `steps`: an ordered list of steps to run

These attributes are easily specified using the DSL's block syntax. Here's an example:

``` ruby
job 'print job' do
  every 5.minutes
  step do
    puts "5 minutes later..."
  end
end
```

The name of this job is 'print job'. It runs every 5 minutes and it has 1 step.

Inside of a `job` configuration block, steps are added by using the `step` method. They can also be
added by using a method registered by a plugin, like `keen` or `twilio`. For more informatio on plugins see [Plugins](#plugins).

The period of the job's execution is set via the `every` method. This is a passthrough to the [Clockwork](https://github.com/tomykaira/clockwork) long-running process scheduler. Clockwork gives you a great deal of flexibility when it comes specifiying when jobs should run. Here are some examples:

``` ruby
every 5.seconds
every 24.hours, at: '12:00'
every 24.hours, at: ['00:00', '12:00']
every 24.hours, at: '**:05'
every 24.hours, at: '00:00', tz: 'UTC'
every 5.seconds, at: '10:**'
every 1.week, at: 'Monday 12:30'
```

See the full range of possibilities on the [Clockwork README](https://github.com/tomykaira/clockwork#event-parameters).

##### Webhooks

Jobs can also be triggered via a webhook, instead of scheduling via `every`. Simply use `webhook` instead of `every`, and pass in a path that should trigger that job. `webhook` also accepts a block, which becomes the first step of the job.

``` ruby
webhook '/trigger' do
  if params[:secret] == '12345'
    params[:name]
  else
    false # Returning false cancels the job
  end
end
```

The webhooks are simply a [Sinatra](http://www.sinatrarb.com) app under the hood, so you can reuse a lot of the features that are built-in to Sinatra. Their [routing features](http://www.sinatrarb.com/intro.html#Routes) work out of the box. The webhook block that gets called for every request is also run in the [Sinatra request scope](http://www.sinatrarb.com/intro.html#Request/Instance%20Scope), so you can access the full app (via `settings`), and request params via `params`.

The return value of the webhook block will be passed in as `response` for the first step, and will be stored under `step_responses['webhook']` for all future steps.

*You may want to read about running a [custom HTTP server](#custom-http-server-for-webhooks) if you're going to be using webhooks in production.*

##### Job workflow

When a job kicks off, steps are run serially in the order they are specified. Each step is invoked with 2
arguments - the response of the step immediately preceding it, and a map of all responses so far.
The map is keyed by step name, which defaults to a plugin name if a plugin was used but a step name not specified.

Here's an example that shows how the response chain works:

``` ruby
require 'pushpop'

job do
  every 5.minutes
  step 'one' do
    1
  end
  step 'two' do |response|
    5 + response
  end
  step 'add previous steps' do |response, step_responses|
    puts response # prints 6
    puts step_responses['one'] + step_responses['two'] # prints 7
  end
end
```

If a `step` returns false, subsequent steps **are not run**. Here's a simple example that illustrates this:

``` ruby
require 'pushpop'

job 'lame job' do
  every 5.minutes
  step 'one' do
    false
  end
  step 'two' do
    # never called!
  end
end
```

This behavior is designed to make *conditional* alerting easy. Here's an example of a job that only sends an alert
for certain query responses:

``` ruby
require 'pushpop'

job do

  every 1.minute

  keen do
    event_collection 'errors'
    analysis_type 'count'
    timeframe 'last_1_minute'
  end

  step 'notify only if there are errors' do |response|
    response > 0
  end

  twilio do |step_responses|
    to '+18005555555'
    body "There were #{step_responses['keen']} errors in the last minute!"
  end
end
```

In this example, the `twilio` step will only be ran if the `keen` step returned a count greater than 0.

#### Steps

Steps have the following attributes:

+ `name`: (optional) something that describes the step. Useful in logs, and is the key in the `step_responses` hash. Defaults to plugin name if a plugin is used. If you use the same plugin more than twice, you'll need to give steps individual names.
+ `plugin`: (optional) if the step is backed by a plugin, it's the name of the plugin
+ `block`: A block that runs to configure the step (when a plugin is used) or run it

Steps can be pure Ruby code or use a DSL provided by a plugin. Plugins are just fancy abstractions for creating steps.

Steps have built-in support for ERB templating. This is useful for generating more complex emails and reports.

Here's an example that uses a template:

``` ruby
sendgrid do |response, step_responses|
  to<EMAIL_ADDRESS>  from<EMAIL_ADDRESS>  subject       'Pingpong Daily Response Time Report'
  body template 'pingpong_report.html.erb', response, step_responses
end
```

`template` is a function that renders a template in context of the `response` and `step_responses` and returns a string.
The first argument is a template file name, located in the `templates` directory by default. The second and third arguments are the `response` and `step_responses` respectively. An optional fourth parameter can be used to change the path templates are looked up in.

Here's a very simple template that uses the `response` variable in context:

``` erb
<h1>Daily Report</h1>
<p>We got <%= response %> new users today!</p>
```

## Custom HTTP Server for Webhooks

If you're running Pushpop locally, you can continue to use the CLI for running jobs - `jobs:run` will start the Sinatra app internally if you have any webhooks configured. However, running the app with the CLI in a production environment may not scale well. If your webhooks are going to be hit rapidly in production, you may want to use a beefier HTTP server than the default [WEBrick](http://ruby-doc.org/stdlib-1.9.3/libdoc/webrick/rdoc/WEBrick.html) built in to Ruby.

Here's an example of getting Pushpop running on [Unicorn](http://unicorn.bogomips.org/)

**unicorn.rb**

``` ruby
require 'pushpop'

# Set this to whatever you want.
worker_processes 2

# This loads all of the job files in /jobs
Pushpop.load_jobs

# This configures Clockwork for any scheduled jobs you have.
# You can omit this if all you are using is Webhooks
Pushpop.schedule

# This tells Clockwork to actually start running jobs
# You can omit this if all you are using is Webhooks
Pushpop.start_clock
```

**config.ru**
``` ruby
# This tells Unicorn what to run whenever it starts up a worker..  which is the Pushpop web app
run Pushpop.web.app
```

And then to run it, just do:
``` bash
unicorn -c unicorn.rb
```

## Recipes

The community-driven [pushpop-recipes](https://github.com/pushpop-project/pushpop-recipes) repository contains jobs and templates
for doing common things with Pushpop. Check it out for some inspiration!

## Plugins

There are a number of existing plugins for additional services, both from the Pushpop team and from 3rd parties:

* pushpop-file: [github](https://github.com/pushpop-project/pushpop-file), [rubygems](https://rubygems.org/gems/pushpop-file)
* pushpop-github: [github](https://github.com/pushpop-project/pushpop-github), [rubygems](https://rubygems.org/gems/pushpop-github)
* pushpop-github-status: [github](https://github.com/willbarrett/pushpop-github-status), [rubygems](https://rubygems.org/gems/pushpop-github-status)
* pushpop-keen: [github](https://github.com/pushpop-project/pushpop-keen), [rubygems](https://rubygems.org/gems/pushpop-keen)
* pushpop-mixpanel: [github](https://github.com/pushpop-project/pushpop-mixpanel), [rubygems](https://rubygems.org/gems/pushpop-mixpanel)
* pushpop-product-hunt: [github](https://github.com/pushpop-project/pushpop-product-hunt), [rubygems](https://rubygems.org/gems/pushpop-product-hunt)
* pushpop-pusher: [github](https://github.com/pushpop-project/pushpop-pusher), [rubygems](https://rubygems.org/gems/pushpop-pusher)
* pushpop-sendgrid: [github](https://github.com/pushpop-project/pushpop-sendgrid), [rubygems](https://rubygems.org/gems/pushpop-sendgrid)
* pushpop-slack: [github](https://github.com/pushpop-project/pushpop-slack), [rubygems](https://rubygems.org/gems/pushpop-slack)
* pushpop-twilio: [github](https://github.com/pushpop-project/pushpop-twilio), [rubygems](https://rubygems.org/gems/pushpop-twilio)
* pushpop-twitter: [github](https://github.com/pushpop-project/pushpop-twitter), [rubygems](https://rubygems.org/gems/pushpop-twitter)

### Creating plugins

Plugins are just subclasses of `Pushpop::Step`. Plugins should implement a `run` method and register themselves. Here's a simple plugin that stops job execution if the input into the step is 0:

``` ruby
require 'pushpop'

module Pushpop
  class StopIfZero < Step
    PLUGIN_NAME = 'stop_if_zero'
    def run(last_response=nil, step_responses=nil)
      last_response == 0
    end
  end

  Pushpop::Job.register_plugin(StopIfZero::PLUGIN_NAME, StopIfZero)
end

# now in your job you can use the stop_if_zero step

job do
  step do [0, 1].shuffle.first end
  stop_if_zero
  step do puts 'made it through!' end
end
```

See [pushpop-plugin](https://github.com/pushpop-project/pushpop-plugin) for a repository that you can clone to make creating and packaging plugins easier.

## Contributing

Issues and pull requests are very welcome. One of the goals of the pushpop-project is to get as many unique contributors as possible. Beginners welcome too!

##### Wishlist

+ Add plugins for more data collection and email/SMS/notification services
+ Add a web interface that shows job names, previous job results, and countdowns to the next run
+ Add a web interface for previewing emails in the browser
+ Add beautiful email templates with support for typical Keen IO query responses (groups, series, etc)

##### Testing

Please make sure the specs pass before you submit your pull request. Pushpop has a full set of specs (including plugins). Run them like this:

``` shell
$ bundle exec rake spec
```

repository: pushpop-project/pushpop

gha_language: Ruby

repo_name: pushpop-project/pushpop


text:
# Contributing to XDM

The Experience Data Model (XDM) project is developed as an Open Standard driven by Adobe. We welcome contributions from everyone who is interested in advancing digital experiences.

## Public GitHub Ground Rules

We are in the process of increasing the visibility of XDM to partners and to invite them to contribute and give feedback.
For this purpose, we will move the XDM repository to [https://github.com/adobe/xdm](https://github.com/adobe/xdm).
For Adobe employees, following ground rules apply:

* Like everyone, follow the [Code of Conduct](CODE_OF_CONDUCT.md)
* Like everyone, follow these [Contributing](CONTRIBUTING.md) guides
* Like always, don't share credentials, API keys, or other secrets in issues or in code
* Focus on standardizing the category, not your specific product

## Things to Keep in Mind

XDM uses a **review then commit** process, which means that no changes are being made without an *editor* approving the change.

## Before you Contribute

XDM is driven by Adobe, but it is not specific to Adobe products.
This means that models should capture the universal concepts of digital experiences, not specific implementations, no matter if they are part of an Adobe product or not.
If you need to express a concept that is specific to an Adobe (or other) product, that is not universal, it should be formulated in an XDM extension instead.

## How to Contribute

1. Go to the [list of open issues](https://git.corp.adobe.com/AdobeCloudPlatform/xdm/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc) and pick an issue you want to work on. If you don't see the appropriate issue, [create a new issue in GitHub](https://git.corp.adobe.com/AdobeCloudPlatform/xdm/issues/new)
2. If you haven't done so yet, [fork the XDM repository into your private GitHub organization](https://git.corp.adobe.com/AdobeCloudPlatform/xdm/fork). If your fork exists, merge the latest updates from `AdobeCloudPlatform/xdm` into `yourname/xdm`, so that you don't start from an outdated code tree
3. In `yourname/xdm` create a new branch from `master`. Your branch name should either refer the issue number like `bug-42` or `feature-23` or have a descriptive name like `fix-layer-group-references`
4. Make add edits that apply to the given feature or bug against this new branch. Commit and push in frequent intervals
5. If you are working on the branch for more than a day, make sure to occasionally (at least once per day) to merge the latest updates from `AdobeCloudPlatform/xdm#master` into your branch, so that you won't get surprised when it's time to merge the pull request. Resolve any conflicts to make life easier for the XDM editors
6. Once you are done, create a pull request from your branch against `AdobeCloudPlatform/xdm#master`.

Every pull request should specify:

* What the change intends to do
* If there are breaking changes
* Link to the Github issue in the format `#42`

For every update to the schema, make sure

* `npm test` validates all example files
* There are `schemas/*/*.example.*.json` files for each newly created schema

Furthermore, a pull request that modifies the schema must also include accompanying documentation. Pull requests with missing documentation will be rejected.

Each commit message that is not part of a pull request:

* Should contain the issue ID like `#42`
* Can contain the tag `[trivial]` for trivial changes that don't relate to an issue

## Design Guidelines

The target consumers of the data model are developers building applications using services from Adobe, our partners, and their customers. These design guidelines help:

*  **Longevity**: consuming applications rarely need to be changed.
*  **Clarity**: concepts are self-explanatory.
*  **Continuity**: existing knowledge can be re-applied.
*  **Compatibility**: implementations can easily cross between products.
*  **Consumability**: systems based on the data model are easy to build, understand, and use.

### Design for Longevity

Our goal is to establish a universal standard for the experience business. As such, this standard's lifetime will be comparable to standards like PDF (24 years old), EXIF (22 years old), or HTML (24 years old).

The design decisions made today will impact future developers, who will have only limited understanding, patience, or sympathy for constraints dictated by current Adobe implementations. While future requirements cannot be predicted in detail, it is important to accomodate requirements and industry trends.

### Design for Clarity

XDM will be consumed and implemented by many highly different applications, which in turn will be used by digital experience professionals such as marketers, designers, advertisers, or digital analysts, which will be exposed to names and concepts introduced and solidified in XDM.

When names can refer to a business concept or a lower-level technical concept, save the shorter, simpler name for the high-level business concept.

For example, for a marketer, an *event* is something that happens or takes place, or a planned public or social occasion. For a developer, an *event* in event-driven programming is a low level user- or system action. As the term event is highly relevant to experiences in the more general sense, the shorter, unqualified term shall be used for the business concept.

### Design for Continuity

XDM is not an isolated standard, but incorporates and builds on standards. Whenever possible, use existing standards, or "borrow" concepts from existing standards. See (and update!) [Standards Used by XDM](docs/standards.md).

### Design for Compatibility

Interoperability with [Microsoft's Common Data Model (CDM)](https://docs.microsoft.com/en-us/common-data-service/entity-reference/common-data-model)is a top priority. This means that definitions that are present in CDM should be used or extended, where appropriate, by XDM. XDM should not attempt to duplicate definitions that are present in CDM.

Where appropriate, we can 'lead' CDM, extend it to meet other requirements.
Another good source of data model elements is [schema.org](http://schema.org).

### Design for Consumability

While there will be almost certainly multiple implementations of parts of XDM across Adobe (sometimes sequentially, sometimes in parallel), the number of internal implementations (producers) will be massively outstripped by the number of external, consuming implementations of XDM.

Additional aspects of standard design that aid with consumability are:

* principle of least astonishment: don't surprise the consumer
* avoid unnecessary complexity: don't introduce indirections that are not needed
* the principle of minimal verbosity: make keep things as short as possible, but not shorter

### Design for the Cloud

The experience business is a global business, therefore XDM needs to meet the needs of consumers and creators world-wide.
Desktop and Enterprise applications are often built to be localized, adapted to the customer environment.
But XDM will form the "glue" that puts together widely distributed components which may have different internal data models.
In general we want to avoid the necessity of converters, with some exceptions:

Some values require context to interpret – for example, a phone number without a county code. Include the context in XDM.
However, for values that need no context to convert, put off conversion by allowing alternatives: writing XDM data will require no conversion, while consuming XDM data only requires conversion in cases where conversion is necessary.

Avoid non-semantic limits – don’t put current resource limits in the data model. Limits (number ranges, choices, string length) should be based on business constraints or expressed independently.

## Coding Styleguides

* file names for schema files should be lower case and end with `.schema.json`
* include an `"$id"` with a value like `"https://ns.adobe.com/xdm/assets/image"` in the schema (but leave out the `.schema.json`)
* when referencing schemas, use the absolute `$id`, don't use relative references like `../content/content.schema.json`
* don't nest schemas too deeply. Break inline type definitions into separate `*.schema.json` files if they have properties with object types themselves.
* ensure that there is a `meta:license` at the top of the schema
* use JSON Schema `draft-6`
* provide a `description` and `title` for each schema and each property
* have the `title` at the top of the schema, so that it can be found without scrolling
* make sure you have an example for every schema
* run `npm test` before you make a pull request
* convention is that property names are snake_case, when they appear in JSON
* don't invent your own `_id` attributes, use the `@id` convention
* don't invent your own `type` attributes, use the `@type` convention

## Writing Styleguides

For all writing, please follow the [Adobe I/O style guide](https://www.adobe.io/about/contributing/doc-style_master.html).

## How Contributions get Reviewed

The XDM project differentiates between major and minor contributions.

* Minor contributions: contributions that do not change the meaning of the standard, such as corrections to typos, word order or formatting. Contributions to the project's `README.md` or `CONTRIBUTING.md` are also minor contributions.
* Major contributions: all other contributions.

### Minor Contributions

One of the editors will look at the pull request within one week and flag it as `minor`. The editor will then either merge or reject the pull request. If you haven't heard back from the editors within a week, it is not impolite to send a reminder to [Grp-XDM-API-WGs](mailto:Grp-XDM-API-WGs@adobe.com).

Feedback on the pull request will be given in writing, in GitHub.

### Major Contributions

One of the editors will look at the pull request within one week and flag it as `major`. The editor will then provide feedback on the pull request in GitHub.

Every week, during the XDM working group meeting, all open pull requests will be reviewed and discussed. All feedback given in the meeting will be logged in GitHub. This real-time discussion will make sure all open pull requests will get attention.

When the editors agree on the pull request, the pull request will either be merged or rejected. Until this is the case, the pull request will remain open. Editors are operating under the assumption of agreement, so that a single editor can authorize a merge.

repository: francoisledroff/xdm

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: francoisledroff/xdm


text:
# BottomNavigationBarXF

A Bottom Navigation Bar implementation for Xamarin Forms.
It's using the [Bottom Navigation Bar](https://github.com/pocheshire/BottomNavigationBar) project to render the Navigation Bar on Android. It will render a standard TabbedPage on iOS.

# NuGet

Find it [here](https://www.nuget.org/packages/ThriveGmbH.BottomNavigationBar.XF/).

## License

```
BottomNavigationBar for Xamarin Forms
Copyright (c) 2016 Thrive GmbH and others (http://github.com/thrive-now).

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

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

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

repository: berlamont/BottomNavigationBarXF

gha_language: C#

repo_name: berlamont/BottomNavigationBarXF


text:
# Stuff for free

*or*

## What I've learned about Swagger

---

# What is it?

> Swagger is a language-agnostic open specification to describe REST APIs.

Format is largely based on JSON Schema.

---

## Swagger is

...an open standard based on open standards.

...is a data structure to describe data structures.

...is a specification that specifies specifications.

---

![](img/yertle-turtle.jpg)

...turtles all the way down.

---

## RESTful

Covers most things important to an API consumer.

* host
* HTTP paths, + verbs
* parameters
* ACL/permissions
* security schemes
* response schemas

---

## Versioned

timeline

* _1.0_ - published 2011-08-10
* _1.1_ - published 2011-08-10
* _1.2_ - published 2014-03-14
* __2.0__ - published 2014-09-08
* _3.0_ - in progress

---

![](img/raging-hellfish.jpg)

_JS Platform supports v2.0_

---

## Spec formats

* `.json` (JSON Schema)
* `.yaml`

Convention is to name a swagger spec `swagger.json` (or `.yaml`)

---

## Now for some vocab

Let's all speak the same language

---

## Spec

_Swagger_ is a specification, not a library.

---v

Some libraries we use with swagger:
* `swagger-tools` - for Carbon API
* `swagger-ui` - for api documentation
* `swagger-client` - for `api-clients`

Note:
Often hear people talking about "Swagger". It can be very confusing to refer to
anything related to swagger as "in swagger" or "using swagger".

---

## "paths object"

This is where your routes, verbs, and parameters go.

Params shared across operations can be declared at the path level

---

## "operation":

_combination of an HTTP path + verb_

---v

`operationId` is used to uniquely identify path/verb combinations when
generating client clients

---

## "schema":

_a format for data_

---v

Lifted directly from JSON Schema and extended many places in swagger specs:

* data types
* parameters
* response objects

Note:
Similar to a model

---

## "parameters"

_data used by an operation_

---v

Describes data in:

* query params
* path via template matching
* headers
* body
* files

---

## "definitions"

_reusable bits of a spec_

---v

* definitions (abstract definitions)
* parameter definitions
* responses defintions
* security definitions

Improves readability, saves typing, and can even be reused across multiple specs!

---v

```
"Tag": {
    "type": "object",
    "properties": {
      "id": {
        "type": "integer",
        "format": "int64"
      },
      "name": {
        "type": "string"
      }
    }
  }
```

---

## "reference object"

_a link to a reusable definition_

Use these!

---v

Same file: `"$ref": "#/definition/searchTerm"`

Another file: `"$ref": "Search.json"`

A definition in another file: `"$ref": "Search.json#/definition/searchTerm"`

---

![](img/more-you-know.jpg)

---

## Some other useful stuff I learned...

---

Online editor is SUPER useful

editor.swagger.io

---

## Descriptions are not optional

---

![](img/dont-panic.jpg)

* often the only required field
* can be markdown

---

## Swagger specification can be extended

Many parts of the spec support vendor-specific extension and customization.

`x-` is the vendor-specific prefix.

---

## Authentication

Special headers. Defined with SecurityDefinitions, not parameters.

---

## Supported auth strategies

* oauth2
* security token
* user/pass

---

Requires both a security definition **and** a security object.

The names should match:

```
// top level
"securityDefinitions": {
  "contributor": { /* ... */ }
},

// in an operation or path
"security": [
  {
    "contributor": [
      "user.view" // no ACL? this can be empty
    ]
  }
],
```

---

## A well written spec?

* uses references
* has good text descriptions
* factors out common structures
* reuses definitions

---

## So why use it?

---

## Better documentation

Most developers first encounter swagger spec by interacting with a Swagger UI site.

But the swagger specification is so much more than that.

It gives us a way to stop repeating ourselves.

---

## Way more than just docs

Other tooling and libraries available for:

* application routing
* security + ACL middleware
* route parameter validation
* auto-generated API clients
* database model generation
* automated api testing
* type definitions
* application frameworks (hi carbon!)

---

## Why is it important?

---

## Garden of the commons

At its core, the swagger spec carves out a common ground for both computers
and humans to understand REST APIs. With these common terms, we can write and
reuse tools and libraries across multiple APIs.

When used to map routes to controllers and validate parameters, a swagger spec
becomes *the* canonical representation of an API.

Note:

Just like a REST API establishes a contract for interacting with an application,
a Swagger spec establishes a contract for interacting with APIs in general.

Within this common ground, anyone can craft and share tools and libraries that
work together, regardless of platform, language

---

## OpenAPI is the new Swagger

On January 1st, 2016 Swagger was been donated to the [Open API Initiative](https://openapis.org)
and renamed OpenAPI Specification.

---v

## In good company

The Open API Initiative is a Linux Foundation Collaboration project (just like Node!)

Some members you may have heard of:

* Google
* IBM
* Microsoft
* Atlassian
* CapitalOne
* Apiary
* and more...

---

Find internal specs at your friendly api, or on our github https://github.shuttercorp.net/web-platform/swagger-specs/

license: MIT

repository: jvivs/swagger-stuff-for-free

gha_language: JavaScript

gha_license_id: MIT

repo_name: jvivs/swagger-stuff-for-free


text:
# Booting Kubernetes Using Minikube

This guide will walk you through the process of installing a small development
Kubernetes cluster on your local machine using [minikube](https://github.com/kubernetes/minikube).

## Pre-requisites

* OS X
    * [xhyve driver](https://github.com/kubernetes/minikube/blob/master/DRIVERS.md#xhyve-driver), [VirtualBox](https://www.virtualbox.org/wiki/Downloads) or [VMware Fusion](https://www.vmware.com/products/fusion) installation
* Linux
    * [VirtualBox](https://www.virtualbox.org/wiki/Downloads) or [KVM](http://www.linux-kvm.org/) installation
* Windows
    * [Hyper-V](https://github.com/kubernetes/minikube/blob/master/DRIVERS.md#hyperv-driver)
* VT-x/AMD-v virtualization must be enabled in BIOS
* The most recent version of `kubectl`. You can install kubectl following
  [these steps](https://kubernetes.io/docs/user-guide/prereqs/).
* Internet connection
    * You will need a decent internet connection running `minikube start` for the first time for
    Minikube to pull its Docker images. It might take Minikube some time to start.

## Download and Unpack Minikube

See the installation instructions for the
[latest release of minikube](https://github.com/kubernetes/minikube/releases).

## Set your VM driver (optional)

You can set your preferred driver (virtualbox - default, vmwarefusion, kvm, xhyve) using the following command:

```
minikube config set vm-driver virtualbox
```

## Boot Your First Cluster

We are now ready to boot our first Kubernetes cluster using Minikube!

```
$ minikube start --disk-size=60g --memory=4096
Starting local Kubernetes cluster...
Kubectl is now configured to use the cluster.
```

Now that the cluster is up and ready, `minikube` automatically configures `kubectl` on your machine
with the appropriate authentication and endpoint information.

```
$ kubectl cluster-info
Kubernetes master is running at https://<IP_ADDRESS>:8443
KubeDNS is running at https://<IP_ADDRESS>:8443/api/v1/proxy/namespaces/kube-system/services/kube-dns
kubernetes-dashboard is running at https://<IP_ADDRESS>:8443/api/v1/proxy/namespaces/kube-system/services/kubernetes-dashboard

To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
```

You are now ready to [install Deis Workflow](install-minikube.md)


text:
# Odontia subalbicans (Pers.) Bres., 1903 SPECIES

#### Status
SYNONYM

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

#### Published in
Annls mycol. 1(1/2): 8 (1903)

#### Original name
Thelephora granulosa var. subalbicans Pers., 1801

### Remarks
null

repository: mdoering/backbone

path: /life/Fungi/Basidiomycota/Agaricomycetes/Trechisporales/Hydnodontaceae/Sistotremastrum/Sistotremastrum niveocremeum/ Syn. Odontia subalbicans/README.md

repo_name: mdoering/backbone


text:
project_path: /web/tools/_project.yaml
book_path: /web/tools/_book.yaml
description: Learn about all the ways you can pause your code in Chrome DevTools.

{# wf_updated_on: 2017-06-22 #}
{# wf_published_on: 2017-02-03 #}

{% include "web/tools/chrome-devtools/_shared/styles.html" %}

# Pause Your Code With Breakpoints {: .page-title }

{% include "web/_shared/contributors/kaycebasques.html" %}

Use breakpoints to pause your JavaScript code. This guide explains each type
of breakpoint that's available in DevTools, as well as when to use and how to
set each type. For a hands-on tutorial of the debugging process, see [Get
Started with Debugging JavaScript in Chrome
DevTools](/web/tools/chrome-devtools/javascript/).

## Overview of when to use each breakpoint type {: #overview }

The most well-known type of breakpoint is line-of-code. But line-of-code
breakpoints can be inefficient to set, especially if you don't know exactly
where to look, or if you are working with a large codebase. You can save
yourself time when debugging by knowing how and when to use the other types
of breakpoints.

Breakpoint Type	Use This When You Want To Pause...

    Line-of-code

      On an exact region of code.

    Conditional line-of-code

      On an exact region of code, but only when some other condition is true.

    DOM

      On the code that changes or removes a specific DOM
      node, or its children.

    XHR

      When an XHR URL contains a string pattern.

    Event listener

      On the code that runs after an event, such as
      click, is fired.

    Exception

      On the line of code that is throwing a caught or
      uncaught exception.

    Function

      Whenever a specific function is called.

## Line-of-code breakpoints {: #loc }

Use a line-of-code breakpoint when you know the exact region of code that you
need to investigate. DevTools *always* pauses before this line of code is
executed.

To set a line-of-code breakpoint in DevTools:

1. Click the **Sources** tab.
1. Open the file containing the line of code you want to break on.
1. Go the line of code.
1. To the left of the line of code is the line number column. Click on it. A
   blue icon appears on top of the line number column.

  <img src="imgs/loc-breakpoint.png"
       alt="A line-of-code breakpoint."

    Figure 1: A line-of-code breakpoint set on line 29

### Line-of-code breakpoints in your code {: #debugger }

Call `debugger` from your code to pause on that line. This is equivalent to
a [line-of-code breakpoint](#loc), except that the breakpoint is set in your
code, not in the DevTools UI.

    console.log('a');
    console.log('b');
    debugger;
    console.log('c');

### Conditional line-of-code breakpoints {: #conditional-loc }

Use a conditional line-of-code breakpoint when you know the exact region of
code that you need to investigate, but you want to pause only when some
other condition is true.

To set a conditional line-of-code breakpoint:

1. Click the **Sources** tab.
1. Open the file containing the line of code you want to break on.
1. Go the line of code.
1. To the left of the line of code is the line number column. Right-click it.
1. Select **Add conditional breakpoint**. A dialog displays underneath the
   line of code.
1. Enter your condition in the dialog.
1. Press Enter to activate the breakpoint. An orange icon appears
   on top of the line number column.

  <img src="imgs/conditional-loc-breakpoint.png"
       alt="A conditional line-of-code breakpoint."

    Figure 2: A conditional line-of-code breakpoint set on line
    32

### Manage line-of-code breakpoints {: #manage-loc }

Use the **Breakpoints** pane to disable or remove line-of-code breakpoints from
a single location.

  <img src="imgs/breakpoints-pane.png"
       alt="The Breakpoints pane."

    Figure 3: The Breakpoints pane showing two line-of-code
    breakpoints: one on line 15 of get-started.js, another on
    line 32

* Check the checkbox next to an entry to disable that breakpoint.
* Right-click an entry to remove that breakpoint.
* Right-click anywhere in the **Breakpoints** pane to deactivate all
  breakpoints, disable all breakpoints, or remove all breakpoints. Disabling
  all breakpoints is equivalent to unchecking each one. Deactivating all
  breakpoints instructs DevTools to ignore all line-of-code breakpoints, but to
  also maintain preserve their enabled state so that they are in the same
  state as before when you reactivate them.

  <img src="imgs/deactivated-breakpoints.png"
       alt="Deactivated breakpoints in the Breakpoints pane."

    Figure 4: Deactivated breakpoints in the Breakpoints pane
    are disabled and transparent

## DOM change breakpoints {: #dom }

Use a DOM change breakpoint when you want to pause on the code that changes
a DOM node or its children.

To set a DOM change breakpoint:

1. Click the **Elements** tab.
1. Go the element that you want to set the breakpoint on.
1. Right-click the element.
1. Hover over **Break on** then select **Subtree modifications**, **Attribute
  modifications**, or **Node removal**.

  <img src="imgs/dom-change-breakpoint.png"
       alt="The context menu for creating a DOM change breakpoint."

    Figure 5: The context menu for creating a DOM change breakpoint

### Types of DOM change breakpoints {: #dom-types }

* **Subtree modifications**. Triggered when a child of the currently-selected
  node is removed or added, or the contents of a child are changed. Not
  triggered on child node attribute changes, or on any changes to the
  currently-selected node.

* **Attributes modifications**: Triggered when an attribute is added or removed
  on the currently-selected node, or when an attribute value changes.

* **Node Removal**: Triggered when the currently-selected node is removed.

## XHR breakpoints {: #xhr }

Use an XHR breakpoint when you want to break when the request URL of an XHR
contains a specified string. DevTools pauses on the line of code where the
XHR calls `send()`.

Note: This feature also works with [Fetch][Fetch] requests.

To set an XHR breakpoint:

1. Click the **Sources** tab.
1. Expand the **XHR Breakpoints** pane.
1. Click **Add breakpoint**.
1. Enter the string which you want to break on. DevTools pauses when this
   string is present anywhere in an XHR's request URL.
1. Press Enter to confirm.

  <img src="imgs/xhr-breakpoint.png"
       alt="Creating an XHR breakpoint."

    Figure 6: Creating an XHR breakpoint in the XHR Breakpoints
    for any request that contains org in the URL

[Fetch]: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

## Event listener breakpoints {: #event-listeners }

Use event listener breakpoints when you want to pause on the event listener
code that runs after an event is fired. You can select specific events, such
as `click`, or categories of events, such as all mouse events.

1. Click the **Sources** tab.
1. Expand the **Event Listener Breakpoints** pane. DevTools shows a list
   of event categories, such as **Animation**.
1. Check one of these categories to pause whenever any event from that category
   is fired, or expand the category and check a specific event.

  <img src="imgs/event-listener-breakpoint.png"
       alt="Creating an event listener breakpoint."

    Figure 7: Creating an event listener breakpoint for
    deviceorientation

## Exception breakpoints {: #exceptions }

Use exception breakpoints when you want to pause on the line of code that's
throwing a caught or uncaught exception.

1. Click the **Sources** tab.
1. Click **Pause on exceptions** ![Pause on
   exceptions](imgs/pause-on-exceptions.png){:.devtools-inline}. It turns blue
   when enabled.
1. (Optional) Check the **Pause On Caught Exceptions** checkbox if you also
   want to pause on caught exceptions, in addition to uncaught ones.

  <img src="imgs/uncaught-exception.png"
       alt="Paused on an uncaught exception."

    Figure 7: Paused on an uncaught exception

## Function breakpoints {: #function }

Call `debug(functionName)`, where `functionName` is the function you want to
debug, when you want to pause whenever a specific function is called. You can
insert `debug()` into your code (like a `console.log()` statement) or call it
from the DevTools Console. `debug()` is equivalent to setting a
[line-of-code breakpoint](#loc) on the first line of the function.

    function sum(a, b) {
      let result = a + b; // DevTools pauses on this line.
      return result;
    }
    debug(sum); // Pass the function object, not a string.
    sum();

### Make sure the target function is in scope {: #scope }

DevTools throws a `ReferenceError` if the function you want to debug is not
in scope.

    (function () {
      function hey() {
        console.log('hey');
      }
      function yo() {
        console.log('yo');
      }
      debug(yo); // This works.
      yo();
    })();
    debug(hey); // This doesn't work. hey() is out of scope.

Ensuring the target function is in scope can be tricky if you're
calling `debug()` from the DevTools Console. Here's one strategy:

1. Set a [line-of-code breakpoint](#loc) somewhere where the function is
   scope.
1. Trigger the breakpoint.
1. Call `debug()` in the DevTools Console while the code is still paused
   on your line-of-code breakpoint.

repository: shanselman/WebFundamentals

repo_name: shanselman/WebFundamentals


text:
# Configration Format
**NOTE** The format is unstable, it may be changed in the future version.
The `config.toml` is the runtime configuration for rsync-os (both daemon/server and client). Similiar to `rsyncd.conf`, it can control authentication, access, logging, available modules and which storage backend rsync-os uses(local file storage, s3 object storage).

A storage backend begins with the name of the baackend in the square brackets and continues until the next square brackets.

* To configure a s3 object storage:
```toml
[minio]
  endpoint = "<IP_ADDRESS>:9000"  # Require
  keyAccess = "minioadmin"          # Require
  keySecret = "minioadmin"          # Require
  mods = []   # Unlike rsync, all module will specify in the storage backend.
````

repository: joelrebel/rsync-os

repo_name: joelrebel/rsync-os


text:
# tech-radar
Personal tech-radar to keep track of my technology choices / decisions.

Inspired by http://thoughtworks.com/radar/
https://www.thoughtworks.com/radar/faq

## quadrants examples
thoughtworks:
- tools
- techniques
- platforms
- languages & frameworks

zalando:
- Frameworks
- Infrastructure
- Data Management
- Languages

## My quadrants
- Languages
- Frameworks / libraries
- Infrastructure / Tools / platforms
- techniques
- Data Management
- communication / project management

## ring draft classification

Adapted:
- Languages
    - golang
    - JavaScript (ES5, ES6, ES2016, ES2017, ES2018)
    - elm
- Frameworks / libraries
    - reactjs / react-native
    - redux
    - Express.JS
    - nightwatch.js
    - styled-components
- Infrastructure / Tools / platforms
    - kubernetes
        - kubeadm
        - ingress
        - registry
        - tilt
        - kubed
    - docker
    - Gitlab
    - Prometheus
    - ansible
    - digitalocean / hetzner
    - vagrant
    - nginx / HAProxy
    - selenium / grid
    - nodejs
    - Yarn / npm
    - jest
    - create-react-app / create-react-native-app (boilerplate tooling ???)
    - GatsbyJS
- techniques
    - cloud-native development
    - configuration as code
    - pipeline as code
    - API driven
    - event driven
    - JAMStack / static sites
- communication / project management
    - slack
    - jira
    - trello
    - whiteboard
    - talking
- Data Management
    - mongodb
    - MySQL
    - Postgres

Trial:
- Terraform
- HashiCorp Vault
- OpenTracing
- Pyhton 3
- pytorch
- rabbitmq
- Consumer-Driven Contracts
- Gatsby.js / react-static
- TensorFlow

ASSESS:
- rust
- TypeScript
- Elixir
- gocd
- RxJS
- ReasonML
- Phoenix
- serverless (functions)
- Enzyme
- graphql
- GoogleChrome/puppeteer
- headless xyz (CMS)
- webtask.io
- AWS Lambda
- Nodemailer
- Keycloak
- auth0.com
- Koa
- LoopBack
- serverless architectures
- Electron

examine:
- gitops
- argocd
- Spinnaker
- concourse-ci
- Kafka / Kafka Streams
- Keras
- pa11y (!)
- Consul
- micro frontend
- ElasticSearch vs Solr
- tailor.js
- next.js
- Scikit-learn
- Serverless Framework
- Talisman
- Android-x86
- bottledwater-pg
- claudiajs
- Amazon API Gateway
- Ember.js
- ReactiveX
- caffe.berkeleyvision.org
- Kong (getkong.org)
- mesos.apache.org
- goss / serverspec
- rocket.chat
- openstack

Hold:
- metalsmith
- php
    - symfony
    - Laravel
    - Lumen

Avoid:
- magento 1

## ToDo:
- from draft to final first version
- arraging this as volums like thoughtworks ?!
- maybe introduce "watch/observe" ring
- experiement templates ??!!

repository: pandorasNox/tech-radar

repo_name: pandorasNox/tech-radar


text:
# About this sample
This sample extracts HTTP request features and adds them as context feature to a Rank requests that are sent to an Azure Personalizer instance.

This is a [ASP.NET Core MVC 2.1](https://docs.microsoft.com/en-us/aspnet/core/mvc/overview?view=aspnetcore-2.1) solution. When run, it displays a single page with a **Send Request** button on the top bar. When clicked, a Rank request is sent to your Personalizer instance with HTTP information gathered from the featurizer as part of the context features. The entire Rank request body is displayed, as well as the response returned by the instance.

# To try this sample

## Prerequisites

- [.NET Core 2.1](https://dotnet.microsoft.com/download/dotnet-core/2.1)
- [Visual Studio 2019](https://visualstudio.microsoft.com/vs/), or [.NET Core CLI](https://docs.microsoft.com/en-us/dotnet/core/tools/)

## Set up the sample
- Clone the Azure Personalizer Samples repo.

    ```bash
    git clone https://github.com/Azure-Samples/cognitive-services-personalizer-samples.git
    ```

- Navigate to _samples/HttpRequestFeatures_.

- Open `HttpRequestFeatures.sln`.

## Set up Azure Personalizer Service

- Create a Personalizer instance in the Azure portal.

- In the Azure portal, find the `ServiceEndpoint` and `PersonalizerApiKey` in the Quick start tab.
  Fill in the `ServiceEndoint` in appsettings.json.
  Configure the `PersonalizerApiKey` as an [app secrets](https://docs.microsoft.com/en-us/aspnet/core/security/app-secrets) in one of the following ways:

    > If you are using the .NET Core CLI, you can use the `dotnet user-secrets set "PersonalizerApiKey" "<API Key>"` command.
    > If you are using Visual Studio, you can right-click the project and select the **Manage User Secrets** menu option to configure the Personalizer keys. By doing this, Visual Studio will open a `secrets.json` file where you can add the keys as follows:

```JSON
{
  "PersonalizerApiKey": "<your personalizer key here>",
}
```

## Run the sample

Build and run HttpRequestFeaturesExample. Press **F5** if using Visual Studio, or `dotnet build` then `dotnet run` if using .NET Core CLI. Through the UI, you will be able to send a Rank request and see the http request features extracted from your environment, as well as the response.


text:
# Account Storage

This system is used to store account details(emails,passwords...) locally on your machine

## How It Works

#### [Auth.data](https://github.com/mkermy/Password_Storage/blob/master/auth/auth.data)
Firstly, the auth.data file is used to store the main master password that is used to use the program
The password (The Default Password is 1, this can be changed by registering) which is chosen by user is written to the file then checked everytime the user logs in...

#### [Key.key](https://github.com/mkermy/Password_Storage/blob/master/auth/key.key)
You Might See a key.key File Which is used to store encryption keys (however this is **not** hard coded the encryption key changes when you password (stored in Auth.data) changes)
Everytime the user trys to read their data it goes back to this file decrypt the data.

#### [Accounts.data](https://github.com/mkermy/Password_Storage/blob/master/accounts/accounts.data)
This File holds all the user data but this data is encrypted and decrypted using the Key.key file.

## License
This Project is covered under the [MIT license](https://github.com/mkermy/Password_Storage/blob/master/LICENSE).


text:
# liri-node-app

##Commands

### node liri spotify-this-song + <search term>
- limited 5 results from the api
- default searches using the term random song

### node liri movie-this + <search term>
-default search is for terminator

### node liri concert-this + <search term>
-default search is for yaeji

### node liri do-what-it-says
-reads from random.txt and searches spotify with for queries in that file

##### see here ->
![Gif of the app](https://media.giphy.com/media/8BlD2Xgn7n1q42uJT0/giphy.gif)

repository: ralphluring/liri-node-app

repo_name: ralphluring/liri-node-app


text:
### Evaluate the correctness of a synthesized prolog query

#### Requirements
1. Setup a Prolog execution environment, e.g., the **swi-prolog** (https://www.swi-prolog.org/)

#### Execution
1. Enter a prolog terminal by command ``swipl''
2. Load the facts and rules defined in GeoQuery with command ```?- [geoquery].```
2. Get the execution result of a prolog query `P` with command ```?- P.```.

For example, for the question, "Give me the cities in Virginia.",
```prolog
?- answer(A,(city(A),loc(A,B),const(B,stateid(virginia)))).
```
which will output
```
[alexandria,arlington,chesapeake,hampton,lynchburg,'newport news',norfolk,portsmouth,richmond,roanoke,'virginia beach']
```

repository: JasperGuo/Unimer

gha_language: Python

repo_name: JasperGuo/Unimer


text:
Frequently Asked Questions (FAQs)
======
This page is dedicated to summarizing some frequently asked questions about ThunderSVM.

## FAQs of users
* How can I use the source code?
  Please refere to [How To](how-to.md) page.

* What is the format of the input file?
  The file format is the same as the format of files in LibSVM site.

* Does this version support the Windows OS?
  No. However, the code should work on Windows OS, although we haven't tested it on Windows.

* I got "error while loading shared libraries: libcudart.so.6.0: wrong ELF class: ELFCLASS32", when I run the executable file "thundersvm".
  Running the command ```sudo ldconfig /usr/local/cuda/lib64``` should resolve the problem..

* Can ThunderSVM run on CPUs?
  No. The current version of ThunderSVM must run on GPUs, but we strive to make ThunderSVM run purely on CPUs in parallel.

## FAQs of developers
* Why not use shrinking?
  Shrinking is used in ThunderSVM, and is implemented by the working set size. We don't provide the shrinking option to users, because the traditional way of shrinking is inefficient on GPUs.

repository: mindis/thundersvm

repo_name: mindis/thundersvm


text:
# Authentication OAth2.0 Errors

## 400 Errors: StatusBadRequest

Error Code | Description
---------- | -------
INVALID_CLIENT | Client authorization failed due to invalid or missing client ID provided
UNAUTHORIZED_CLIENT | The client is not authorized to use this grant type
INVALID_REQUEST | A request is missing a request parameter like, code, redirect_uri, refresh_token
INVALID_GRANT | The provided authorization grant or refresh token is invalid, expired, revoked, or does not match the redirect URL
UNSUPPORTED_GRANT_TYPE | The authorization grant_type provided in the request is not supported by the authorization server
INSUFFICIENT_SCOPE |  The request required higher privileges than provided by the access token
503 | Service Unavailable -- We're temporarily unavailable to serve your request. Please try again later.

## 401 Errors: StatusUnauthorized

Error Code | Description
---------- | -------
INVALID_TOKEN | The access token provided in the authorization header is not valid

## 403 Errors: StatusForBidden

Error Code | Description
---------- | -------
INSUFFICIENT_SCOPE | The request required higher privileges than provided by the access token

repository: thumbtack/slate

gha_license_id: NOASSERTION

repo_name: thumbtack/slate


text:
# externa-vue-example

## Explanation
This is a rough proof-of-concept example app showing _very_ basic usage of externa. It will likely not live long in the repo, as I plan for example apps to reside in a separate + dedicated repo.

After installing dependencies, etc., run `npm run serve` in this directory and then load [http://localhost:8081/](http://localhost:8081/) in your browser. Watch the browser console for log messages (optional: you can also enable logging via the debug module by setting the `debug` flag in `localStorage` to `externa*`).

## Project setup
```
npm install
```

### Compiles and hot-reloads for development
```
npm run serve
```

### Compiles and minifies for production
```
npm run build
```

### Lints and fixes files
```
npm run lint
```

### Customize configuration
See [Configuration Reference](https://cli.vuejs.org/config/).

repository: ifandelse/externa

repo_name: ifandelse/externa


text:
# PageRank: Runtime vs. Number of Edges

[PR Runtime vs. Number of Edges](https://raw.githubusercontent.com/gunrock/io/master/plots/gunrock_primitives_pr_edges_table.html ':include :type=markdown')

repository: gunrock/docs

branch_name: refs/heads/develop

repo_name: gunrock/docs


text:
# Mind the Gap, Measuring Periodicity in Sparsely Sampled Time Series Data

## Schedule

 * 08:00 AM - 09:00 AM  o  Registration
 * 09:00 AM - 09:30 AM  o  Introduction of the new instructors
 * 09:30 AM - 10:30 AM  o  Important Signals in Astronomical Time Series; A. Miller [:octocat:](https://github.com/adamamiller)
 * 10:30 AM - 11:00 AM  o  Break
 * 11:00 AM - 12:00 PM  o  Periodic Signals and the Lomb Scargle Periodogram; A. Miller [:octocat:](https://github.com/adamamiller)
 * 12:00 PM - 01:30 PM  o  LUNCH
 * 01:30 PM - 02:15 PM  o  The Neverending Search for Periodicity: Techniques Beyond Lomb-Scargle; A. Miller [:octocat:](https://github.com/adamamiller)
 * 02:15 PM - 03:30 PM  o  Problem –– Using Conditional Entropy; A. Miller [:octocat:](https://github.com/adamamiller)
 * 03:30 PM - 04:00 PM  o  Break
 * 04:00 PM - 04:45 PM  o  An Introduction to Gaussian Process Regression; R. Luger [:octocat:](https://github.com/rodluger)
 * 04:45 PM - 06:00 PM  o  Problem –– Building a GP Model; R. Luger [:octocat:](https://github.com/rodluger)

repository: LSSTC-DSFP/LSSTC-DSFP-Sessions

branch_name: refs/heads/main

gha_language: Jupyter Notebook

repo_name: LSSTC-DSFP/LSSTC-DSFP-Sessions


text:
---
layout:         bill
category:       bills
title:          Teacher Computers Resolution
year:           2010-2011
summary:
sponsors:       LHS Student-Faculty Senate
passed:         November 17, 2010
tags:
visualworkflow: true
---

Resolved: The Student-Faculty Senate encourages teachers to allow students to use their computers during free blocks or study halls.

Rationale:
1. Opening up classroom computers would reduce traffic and occupancy in the library.
2. Teachers can have greater control over their students' use of free blocks/studies because they can choose to monitor them in their own classroom.
3. Students will have greater work efficiency with easier access to computers.
4. It should be made clear that there are no security risks associated with student use of computers. Grades, tests, etc. will remain on the teacher's account, and the student must use their own in order to access the computer.

repository: vitaedev/lhssenate

extension: markdown

repo_name: vitaedev/lhssenate


text:
# Emoji data

PicMo uses data provided by the [Emojibase](https://emojibase.dev/) project. To keep the bundle size down, the emoji data is not bundled with the main library.

The data can be sourced in two ways:

## Downloaded from CDN

If no static emoji data is provided to the picker, it will use a CDN to download the data. This is the default behavior.

### Keeping up to date

When the picker is initialized, a `HEAD` request is made to the CDN to check if the data has changed (by comparing the [ETags](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag) with ones previously stored in the database). If there is new data available, the picker will download the new data and replace the old data with it.

## Provided static data

If you do not want to connect to an external CDN to download the data, you can provide the data in your bundle. To do this you will need to install the [emojibase-data](https://www.npmjs.com/package/emojibase-data) package.

Simply import the data for the desired locale into your project. The picker needs the emoji data itself as well as the category names.

```javascript
import emojiData from 'emojibase-data/<locale>/data.json';
import messages from 'emojibase-data/<locale>/messages.json';

const picker = createPicker({
  emojiData,
  message
});
```

## Emoji database

By default, PicMo uses a local IndexedDB database to store the emoji data. This is the preferred method, and is the default if no data store factory is specified.

Once the data is available, whether provided in the bundle or downloaded from the CDN, it is used to populate the database of the emoji data.

The database is automatically created when the picker is first initialized if it one does not already exist. However, you can also pre-create the database ahead of time by calling [`createDatabase`](../api/picmo/functions/create-database).

All picker instances share the same database.

### IndexedDB data store

By default, PicMo uses a local IndexedDB database to store the emoji data. This is the preferred method, and is the default if no data store factory is specified. Databases are locale-specific - a new database is created per locale used by the picker.

The IndexedDB store is the default, but it can also be manually specified by setting the `dataStore` picker option to [`IndexedDBStoreFactory`](../api/picmo/functions/indexed-db-store-factory).

### In-memory data store

If you are deploying PicMo in a high security environment where IndexedDB is not available, you can use a simple in-memory data store implementation. This will have a performance cost as all emojis and categories will be kept in memory. The in-memory store is also not persisted across sessions.

If using the in-memory data store, it's recommended that you install the [`emojibase-data`](https://www.npmjs.com/package/emojibase-data) package to provide the emoji data. Using the CDN method will result in the data being downloaded on every page load.

To use the in-memory store, set the `dataStore` picker option to [`InMemoryStoreFactory`](../api/picmo/functions/in-memory-store-factory).

### Checking for updates

When data is initially downloaded from a CDN, the ETag values for each bundle is stored in the database. For every subsequent picker initialization, a `HEAD` request is made and the ETags are compared to determine if new data needs to be downloaded.

For locally provided data, the ETag values are not available, so PicMo will compute a hash of the current emoji data to check if the emoji data has changed, at which time it will repopulate the database.

### Error recovery

If there are any errors encountered while initializing or accessing the database, an error message is shown with a retry button. Clicking the retry button will delete the (possibly corrupt) database and re-initialize it with fresh data.

## Recent emoji data

The picker remembers recently used emojis. This data is stored in the browser's `localStorage` instead of the database.

url: https://raw.githubusercontent.com/jmlee2k/emoji-button/3525583e049cdea34e2ce48b9516983b9f02e209/docs/docs/02 - usage/06 - emoji-data.md

filename: 06 - emoji-data.md


text:
---
layout: post
title:  "[Scala] Coursera - Lecture 4.6 - Pattern Matching"
date:   2016-06-26 07:00:00
categories: programming
author: Rachel Park
comments: true
tags: [programming]
permalink: programming/022
---

I will summerize the lectures (Functional Programming Principles in Scala of Coursera) to study Scala.

* The full video lectures : https://class.coursera.org/progfun-005/lecture

* The lecture of this posting : Lecture 4.6 - Pattern Matching

Summary

-
Case Classes

  - definition is similar to a normal class definition, except that it is preceded by the modifier case

{% highlight text %}
trait Expr
case class Number(n: Int) extends Expr
case class Sum(e1: Expr, e2: Expr) extends Expr
{% endhighlight %}

-
Pattern Matching

  - a generalization of switch from C/Java to class hierarchies

{% highlight text %}
def eval(e: Expr): Int = e match {
  case Number(n) => n
  case Sum(e1, e2) => eval(e1) + eval(e2)
}
{% endhighlight %}

-
Match Syntax

  - match is followed by a sequence of cases, pat => expr

  - each case associates an expression expr with a pattern pat

  - a MatchError exception is thrown if no pattern matches the value of the selector

-
Forms of Patterns

  - variables always begin with a lowercase letter

  - the same variable name can only appear once in a pattern. So, Sum(x, x) is not a legal pattern

  - names of constants begin with a capital letter, with the exception of the reserved words null, true, false

    - constructors, e.g. Number, Sum

    - variables, e.g. n, e1, e2

    - wildcard patterns _

    - constants, e.g. 1, true

-
Evaluating Match Expressions

  - an expression of the form matches the value of the selector e with the patterns p1, ..., pn in the order in which they are written

  - the whole match expression is rewritten to the right-hand side of the first case where the pattern matches the selector e

  - references to pattern variables are replaced by the corresponding parts in the selector

{% highlight text %}
e match { case p1 => e1 ... case pn => en }
{% endhighlight %}

-
What Do Patterns Match?

  - a constructor pattern C(p1, ..., pn) matches all the values of type C (or a subtype) that have been constructed with arguments matching the patterns p1, ..., pn

  - a variable pattern x matches any value, and binds the name of the variable to this value

  - a constant pattern c matches values that are equal to c (in the sense of ==)

-
Example

{% highlight text %}
eval(Sum(Number(1), Number(2)))

→

Sum(Number(1), Number(2)) match {
  case Number(n) => n
  case Sum(e1, e2) => eval(e1) + eval(e2)
}

→

eval(Number(1)) + eval(Number(2))

→

Number(1) match {
  case Number(n) => n
  case Sum(e1, e2) => eval(e1) + eval(e2)
} + eval(Number(2))

→

1 + eval(Number(2))

→→

3
{% endhighlight %}


text:
# The nhsx.io theme

**nhsx.io** is a Jekyll theme for GitHub Pages. You can [preview the theme](https://nhsx.github.io/nhsx-io-theme/) to see what it looks like

## Usage

To use the nhsx.io theme:

1. Add the following to your site's `_config.yml`:

    ```yml
    remote_theme: nhsx/nhsx-io-theme
    ```

## Customizing

### Configuration variables

nhsx.io will respect the following variables, if set in your site's `_config.yml`:

```yml
description: [A short description of your site's purpose]
```

Additionally, you may choose to set the following optional variables:

```yml
show_downloads: ["true" or "false" to indicate whether to provide a download URL]
google_analytics: [Your Google Analytics tracking ID]
```

### Stylesheet

If you'd like to add your own custom styles:

1. Create a file called `/assets/css/style.scss` in your site
2. Add the following content to the top of the file, exactly as shown:
    ```scss
    ---
    ---

    @import "{{ site.theme }}";
    ```
3. Add any custom CSS (or Sass, including imports) you'd like immediately after the `@import` line

### Layouts

If you'd like to change the theme's HTML layout:

1. [Copy the original template](https://github.com/nhsx/nhsx-io-theme/blob/master/_layouts/default.html) from the theme's repository<br />(*Pro-tip: click "raw" to make copying easier*)
2. Create a file called `/_layouts/default.html` in your site
3. Paste the default layout content copied in the first step
4. Customize the layout as you'd like

## Contributing

Interested in contributing to nhsx.io? See [the CONTRIBUTING file](docs/CONTRIBUTING.md) for instructions on how to contribute.


text:
IP Engineering Rescue Disk: Overview
====================================

This is a multi Linux distro rescue Disk.  This image contains base files to
boot into various utilities and installers. Unless booted from a USB device,
this image is read-only.  To learn more, press one of the function keys
listed below to view a topic or navigate using the documentation menu:

   * <F1> - Overview
   * <F2> - Serial Console

repository: syzdek/iperd

repo_name: syzdek/iperd


text:
## Working Group Registry

### Product WG

Builds products to support the mission of the Aragon Network.

* (Initial suggestion for members - Brett, Luis, Pierre, Daniel, Gorka, Delfi, Adri, Paty, Olivier, Xavier, Deam, Billy, Yalda, Arthur, Kevin, Otto, Radek, Chad, Javier, Jordan, Luke, Gabi...)
* First facilitator role ensured by Luis Cuende and Javier Alavez
* https://aragon.chat/channel/wg-product

### Documentation WG

Documents the history and the products produced by the Aragon Network.

* (Initial suggestion for members - John, Gabi, Daniel, Brett...)
* First facilitator role ensured by John Light

### Communications WG

Raises awareness about the activities and mission of the Aragon Network within strategic audiences

* (Initial suggestion for members - John, Nolwenn, Thibault...)
* First facilitator role ensured by John Light

### Community WG

Supports the community of Aragon Network contributors, including facilitation of the Aragon Network governance process.

* (Initial suggestion for members - John, Luke, Daniel, Daniel Constantin...)
* First facilitator role ensured by John Light

### Strategy WG

This WG focuses on strategic initiatives to sustain and grow the Aragon Network, the Flock and Nest programs as well as the broader Aragon community. In the Strategy WG, items are discussed from an interdisciplinary perspective and should be assessed as part of the global Aragon landscape.

Examples of use-cases for the WG:

* Coordination on topics and projects involving two or more network entities or disciplines,
* Assessement of the current Network strategy,
* Discussions on Aragon Network Votes and Proposals,
* Addressing issues related to the governance of the Aragon Network and grant programs

**Calls** happen every two weeks on Fridays [here](https://meet.google.com/bye-ztbk-bfh?authuser=1) and are run according to an open agenda. They are not recorded at this time.

**Notes** taken during these calls can be found in the [Aragon Wiki](https://wiki.aragon.org/working-groups/meeting-notes/strategy-wg/Strategycall20190705/)

The **Strategy-WG [chat](https://aragon.chat/channel/wg-product)** is best used to advance discussions and update the group in between calls

### Research WG

Works on experimental mechanisms and technologies that support the mission of the Aragon Network; this work may or may not be productized.

* (Initial suggestion for members - Jorge, Bingen, Facu, Alexandre...)
* Frist facilitator role still open

### "Your working group”

“The purpose of your working group”

* “The first facilitator(s) who will implement your Working Group in its first few days”

repository: vporton/aragon-wiki

repo_name: vporton/aragon-wiki


text:
# Orchestra

## Overview

Orchestra is an autonomous scheduling solution for TSCH, where nodes maintain
their own schedule solely based on their local RPL state. There is no centralized
scheduler nor negociatoin with neighbors, i.e. no traffic overhead. The default
Orchestra rules can be used out-of-box in any RPL network, reducing contention
to a low level. Orchestra is described and evaluated in
[*Orchestra: Robust Mesh Networks Through Autonomously Scheduled TSCH*](http://www.simonduquennoy.net/papers/duquennoy15orchestra.pdf), ACM SenSys'15.

## Requirements

Orchestra requires a system running TSCH and RPL.

## Getting Started

To include Orchestra in your application, all you need to do is to include its module, by adding the following line to your makefile:
```
MODULES += os/services/orchestra
```

## Configuration

Orchestra comes with a number of pre-installed rules, `orchestra-rule-*.c`.
You can define your own by using any of these as a template.
A default Orchestra configuration is described in `orchestra-conf.h`, define your own
`ORCHESTRA_CONF_*` macros to override modify the rule set and change rules configuration.

repository: contiki-ng/contiki-ng

gha_language: C

repo_name: contiki-ng/contiki-ng


text:
# GitHub Trending (2021-01-05)

![](https://img.shields.io/badge/Python-New%20834-green?style=flat-square&logo=appveyor)
- [ChinaVolvocars/jd_maotai_seckill](https://github.com/ChinaVolvocars/jd_maotai_seckill): 优化版本的京东茅台抢购神器

![](https://img.shields.io/badge/Java-New%20125-green?style=flat-square&logo=appveyor)
- [TheAlgorithms/Java](https://github.com/TheAlgorithms/Java): All Algorithms implemented in Java

![](https://img.shields.io/badge/Java-New%20137-green?style=flat-square&logo=appveyor)
- [qiurunze123/miaosha](https://github.com/qiurunze123/miaosha): ⭐⭐⭐⭐秒杀系统设计与实现.互联网工程师进阶与分析🙋🐓

![](https://img.shields.io/badge/none-New%20237-green?style=flat-square&logo=appveyor)
- [ashishpatel26/500-AI-Machine-learning-Deep-learning-Computer-vision-NLP-Projects-with-code](https://github.com/ashishpatel26/500-AI-Machine-learning-Deep-learning-Computer-vision-NLP-Projects-with-code): 500 AI Machine learning Deep learning Computer vision NLP Projects with code

![](https://img.shields.io/badge/Go-New%20322-green?style=flat-square&logo=appveyor)
- [photoprism/photoprism](https://github.com/photoprism/photoprism): Personal Photo Management powered by Go and Google TensorFlow

![](https://img.shields.io/badge/Go-New%2082-green?style=flat-square&logo=appveyor)
- [ztino/jd_seckill](https://github.com/ztino/jd_seckill): go版本jd_seckill，京东茅台抢购，降低使用门栏。

![](https://img.shields.io/badge/C%2B%2B-New%20369-green?style=flat-square&logo=appveyor)
- [WerWolv/ImHex](https://github.com/WerWolv/ImHex): A Hex Editor for Reverse Engineers, Programmers and people that value their eye sight when working at 3 AM.

![](https://img.shields.io/badge/HTML-New%2078-green?style=flat-square&logo=appveyor)
- [gh0stkey/Web-Fuzzing-Box](https://github.com/gh0stkey/Web-Fuzzing-Box): Web Fuzzing Box - Web 模糊测试字典与一些Payloads，主要包含：弱口令暴力破解、目录以及文件枚举、Web漏洞...字典运用于实战案例：https://gh0st.cn/archives/2019-11-11/1

![](https://img.shields.io/badge/Jupyter%20Notebook-New%2073-green?style=flat-square&logo=appveyor)
- [ihebski/DefaultCreds-cheat-sheet](https://github.com/ihebski/DefaultCreds-cheat-sheet): One place for all the default credentials to assist the Blue/Red teamers activities on finding devices with default password 🛡

![](https://img.shields.io/badge/Java-New%2017-green?style=flat-square&logo=appveyor)
- [devsuperior/jdbc-postgres](https://github.com/devsuperior/jdbc-postgres):

![](https://img.shields.io/badge/none-New%20304-green?style=flat-square&logo=appveyor)
- [firstcontributions/first-contributions](https://github.com/firstcontributions/first-contributions): 🚀✨ Help beginners to contribute to open source projects

![](https://img.shields.io/badge/TypeScript-New%20103-green?style=flat-square&logo=appveyor)
- [vitejs/vite](https://github.com/vitejs/vite): Next generation frontend tooling. It's fast.

![](https://img.shields.io/badge/Rust-New%20270-green?style=flat-square&logo=appveyor)
- [996icu/996.ICU](https://github.com/996icu/996.ICU): Repo for counting stars and contributing. Press F to pay respect to glorious developers.

![](https://img.shields.io/badge/none-New%20324-green?style=flat-square&logo=appveyor)
- [dair-ai/ml-visuals](https://github.com/dair-ai/ml-visuals): 🎨 ML Visuals contains figures and templates which you can reuse and customize to improve your scientific writing.

![](https://img.shields.io/badge/none-New%2091-green?style=flat-square&logo=appveyor)
- [karan/Projects](https://github.com/karan/Projects): 📃 A list of practical projects that anyone can solve in any programming language.

![](https://img.shields.io/badge/Assembly-New%2049-green?style=flat-square&logo=appveyor)
- [jthuraisamy/SysWhispers2](https://github.com/jthuraisamy/SysWhispers2): AV/EDR evasion via direct system calls.

![](https://img.shields.io/badge/Python-New%20271-green?style=flat-square&logo=appveyor)
- [sherlock-project/sherlock](https://github.com/sherlock-project/sherlock): 🔎 Hunt down social media accounts by username across social networks

![](https://img.shields.io/badge/JavaScript-New%20358-green?style=flat-square&logo=appveyor)
- [osnr/TabFS](https://github.com/osnr/TabFS): 🗄 Mount your browser tabs as a filesystem.

![](https://img.shields.io/badge/Java-New%2046-green?style=flat-square&logo=appveyor)
- [alibaba/COLA](https://github.com/alibaba/COLA): Clean Object-oriented & Layered Architecture

![](https://img.shields.io/badge/Dart-New%2085-green?style=flat-square&logo=appveyor)
- [flutter/flutter](https://github.com/flutter/flutter): Flutter makes it easy and fast to build beautiful apps for mobile and beyond.

![](https://img.shields.io/badge/Python-New%2078-green?style=flat-square&logo=appveyor)
- [vipstone/faceai](https://github.com/vipstone/faceai): 一款入门级的人脸、视频、文字检测以及识别的项目.

![](https://img.shields.io/badge/JavaScript-New%20244-green?style=flat-square&logo=appveyor)
- [trekhleb/javascript-algorithms](https://github.com/trekhleb/javascript-algorithms): 📝 Algorithms and data structures implemented in JavaScript with explanations and links to further readings

![](https://img.shields.io/badge/none-New%2068-green?style=flat-square&logo=appveyor)
- [MichaelKoczwara/Awesome-CobaltStrike-Defence](https://github.com/MichaelKoczwara/Awesome-CobaltStrike-Defence): Defences against Cobalt Strike

![](https://img.shields.io/badge/TypeScript-New%20112-green?style=flat-square&logo=appveyor)
- [Redocly/redoc](https://github.com/Redocly/redoc): 📘 OpenAPI/Swagger-generated API Reference Documentation

![](https://img.shields.io/badge/Python-New%2034-green?style=flat-square&logo=appveyor)
- [loseys/Oblivion](https://github.com/loseys/Oblivion): Data leak checker & OSINT Tool

repository: Hsins/Daily-GitHub-Trending

repo_name: Hsins/Daily-GitHub-Trending


text:
url-monitor
===========

Simple tool (I mean really, really simple) written in bash. It continuously check response code of given url and display it to the output with fancy colors. It was created for the purposes of debug deploying scripts.

#Instalation

    # curl https://raw.githubusercontent.com/dorians/url-monitor/master/url-monitor.sh > /usr/bin/url-monitor
    # chmod +x /usr/bin/url-monitor

#Usage

    url-monitor http://github.com

repository: dorians/url-monitor

repo_name: dorians/url-monitor


text:
# Web Components

- [d3 - visualization copmponents](d3/)
- [halo - halo and halo items are special tools](halo/)
- [tools - a component that is usually opened in a window and can be used to work](tools/)
- [widgets - components that are the build blocks of other components and tools](widgets/)
- [demo - example components for demonstration](demo/)
- [draft - experimental, unfinished components ](draft/)

branch_name: refs/heads/gh-pages


text:
# Changelog

All notable changes to the **FlexColorPicker** package will be documented in this file.

## [1.1.3] - December 22, 2020
* Fixed the faulty documentation and comment for showPickerDialog parameter insetPadding.
* Fixed the faulty default value for showPickerDialog parameter insetPadding, the new default
  value is the same as Flutter and Material default
  `EdgeInsets.symmetric(horizontal: 40.0, vertical: 24.0)`, as it should have been.
* Minor documentation style correction.

## [1.1.2] - December 5, 2020
* Temporary: The Wrap implementation for showing the color code and integer value was changed to a Row due to a regression in Flutter SDK causing a crash issue on channels dev and master when showing the ColorPicker in a Dialog. For more info see here: https://github.com/flutter/flutter/issues/71687
When the issue is resolved, the implementation will be reverted back to a Wrap. Using a Wrap has the added benefit of breaking the color code display+input field, and the rarely used int value, into two rows in case a large font is used in a narrow view when they are both configured to be shown. The Row may overflow in some rare cases. If you do not plan to use the ColorPicker with channels and versions affected by the issue, you can still use the previous version 1.1.1 to keep using the Wrap implementation if you need it. With normal styling it is typically not needed.
* Fixed that the provided `TextStyle` via property `colorCodeTextStyle` was not also applied to the shown color integer value when `showColorValue` was set to `true`, as stated in API doc and intended.

## [1.1.1] - November 11, 2020
* Updated the example app and documentation. The update includes updated screen shots and updated animated gifs.
* Unit tests for ColorTools added, widget tests still pending for later updates.

## [1.1.0] - November 6, 2020
* New API: Added `showColorValue` to optionally display the int value of the selected color. This can be used to assist developers when they need to see or copy selected color values as int numbers.
* New APIs: Exposed previously missing static color names in the API for all the accent and B&W color names in `ColorTools`. All the color name values default to English color names, but can now be changed to translated strings to provide Material color names in other languages as well.
* Updated the live Web demo to demonstrate the `showColorValue` property.
* Example and documentation updated.

## [1.0.0] - November 5, 2020
* First official release.
* Example and documentation updated.
* Updated the live Web demo version to use the released package.
* New API: Added `shouldUpdate` to the color wheel picker, as a fix for an issue where black selection changed hue to red. This is a lower level API that is not needed unless you make your own picker from scratch, and you want to use the wheel picker in your own picker.
* Final API name tweaks before version 1.0.0 release:
* Renamed: API `createPrimaryColor` -> `createPrimarySwatch`
* Renamed: API `createAccentColor` -> `createAccentSwatch`
* Renamed: API `colorNameAndHexCode` -> `materialNameAndCode`
* Renamed: API `colorName` -> `materialName`
* Renamed: API `colorHexCode` -> `colorCode`

## [1.0.0-dev.5] - November 5, 2020

* Added a feature on the wheel color picker that enables entry of a hex RGB value to select a color.
* API changes to support separate display of Material color name `showMaterialName` and selected color code `showColorCode`, plus defining their text styles `materialNameTextStyle` and `colorCodeTextStyle`.
* New API `showColorName` to display an English color name for any selected color, not just the Material color names or custom named color swatches. It has text style that can be defined as well `colorNameTextStyle`.
* New API `colorCodeIcon` that exposes the color code copy icon, so it can be customized.
* New API `enableTooltips` to enable current and future tooltips used in the picker. Currently, only the copy color code button has a tooltip.
* A new method introduced in ColorTools called `nameThatColor(Color color)`. It returns a name for any color passed to it. Only supports English names. Based on a Dart port of http://chir.ag/projects/ntc, it contains 1566 colors and their names. It matches the given color to the closest similar color in the list and returns its name.
* Example and documentation updated.

## [1.0.0-dev.4] - November 2, 2020

* Update to try to get the images to show up on pub.dev.
* Minor documentation corrections.

## [1.0.0-dev.3] - November 2, 2020

* Significant API name changes and cleanup. Decided to implement previously planned changes before the official release, even if it will also impact our own usage of the package when we move to using the published version.

## [1.0.0-dev.2] - October 30, 2020

* First development pre-release on pub.dev.

---

## To do list and planned feature updates

- [x] Review and update the API.
- [x] Review and correct documentation mistakes and typos, first pass anyway.
- [x] Fix doc images that show up OK in Github readme.md, but not on pub.dev.
- [x] For the color wheel picker, add text input to get a given color based on entered HEX code.
- [x] Add "name that color" function that can give a name to "any" color in English.
- [x] Release version 1.0.0.
- [x] Publish version 1.0.0 on pub.dev.
- [x] Version 1.1.1: Add first set of tests for the ColorPicker, so far only unit tests for ColorTools, more tests will be added later. ColorTools has 4694 tests.
- [ ] Version 1.1.4: Add more tests.
- [ ] Version 1.1.x: Finalize tests.
- [ ] Version 2.0.0-nullsafety.1: Add null safe version.
- [ ] Maybe version 2.1.x: Add more color picker types.
- [ ] Maybe version 2.x.x: Add a color selected with the wheel color selector to the custom colors section.
- [ ] Maybe version 2.x.x: Store colors added to the custom colors section.


text:
---
layout: post
title:  "Modern Programming: SOLI[D] (6 of 6)"
date:   2017-03-27 17:33:00 -0700
categories: modern-programming solid dip engineering-excellence
---
D - Dependency Inversion Principle (DIP)

The preceding chapter (Part 4) of this series can be found [here](https://bradleygibson.github.io/modern-programming/solid/srp/engineering-excellence/2017/03/27/modern-programming-solid-isp-5-of-6.html).

DIP is probably the least-well understood (and the most misunderstood) of the SOLID principles.

If you are unfamiliar with the concept of dependency injection, then you can safely ignore the rest of this paragraph for now.  For everyone else, it is important to call out that dependency inversion != dependency injection. While adhering to DIP may indeed lead you to employ some flavor of dependency injection (eg. Constructor, Service Locator, Inversion of Control or other pattern), it is important to call out that dependency inversion and injection are not synonymous. (The distinction is perhaps worthy of a future article.)  For now, understand that Dependency Injection is but one means of achieving DIP.

[Robert Martin (aka “Uncle Bob”)](https://en.wikipedia.org/wiki/Robert_Cecil_Martin) coined the SOLID mnemonic. He (somewhat academically) defines DIP as follows:

> High-level modules should not depend on low-level modules. Both should depend on abstractions.

> Abstractions should not depend on details. Details should depend on abstractions.

Let’s parse this to make it easier to digest (and more importantly, at least speaking for myself, to retain).

Uncle Bob uses both the terms *“low-level modules”* and *“details”* interchangeably to refer to a dependency--think of an interface that some class needs in order to do its job.  And if that *dependency* is to depend on an interface (as the latter quote above says it should), typically, we would think of this "detail" a concrete class--instantiation or an implementation of an interface.

He uses the term *“abstractions”* to encompass both of what are commonly referred to as interfaces as well as abstract classes--interfaces which cannot be instantiated.

And finally, to “high-level modules".  These are units of code (classes, modules, etc.) that are concerned with behavior (think business rules), but not implementation details. Uncle Bob writes they are *“the truths that do not vary when the details are changed”*. For example, the purpose of a `Button` class might be to turn something else on or off. Should the `Button` class be concerned with what the something else is? Nope--that would violate several SOLID principles, including DIP. Should the `Button` class care whether it represents a physical, mechanical button, or a graphical button on a touch-screen? Nope--same reasons as above. So the `Button` class represents a high-level module, and what it turns on or off is a “low-level module” (an implementation) that it should not care about.

So, to simplify, in our world:

All implementations should depend on interfaces (or abstract classes).

Let's see if this clarification satisfies Uncle Bob’s original tenets:

> “High-level modules should not depend on low-level modules”.

Check.  No high-level concrete or abstract classes depend on low-level concrete classes.  Instead, these modules depend on interfaces (what he refers to as "abstractions").

> “[High-level and low-level modules] should depend on abstractions”.

Check. As per above, all dependencies will be created against interfaces.

> “Abstractions should not depend on details”.

Check. Since Interfaces do not contain any implementation, by definition, no dependencies can be created there. If either an interface or abstract class inherits from another class, or an abstract class’ implementation has a dependency, recall again that all dependencies will be created against interfaces.

> “Details should depend on abstractions”.

Check. All depend… Never mind--you get the idea. ;)

There is one subtle difference between my simplification above, and the original guideline. To cut to the chase, it is that the interfaces that are created are not *owned* by the low-level implementation. One can think of ownership in this case as the ability to compile: with a dependency on an interface, rather than a concrete class, a high-level module should be able to compile without a low-level implementation available.

Now this may seem odd, that an implementation (eg. Foo) does not “own” (is not packaged with) its own interface (eg. IFoo). The interface can be packaged with the high-level interface (ie. the implementation that depends on it) or all on its own, depending on the needs of the project, just as long as it’s not packaged with its own implementation. This important distinction makes our shorthand definition complete.

So to summarize in our own words, DIP recommends:

* All implementations should depend on interfaces (or abstract classes).

* Implementations should not own the interfaces they implement.  (Here, the term "own" means *"to be packaged with"* or *"drive changes into"*).
(More on what "drive changes into" means below).

Whew! Ok, so now we have a straightforward, comprehensible guideline for how to create dependencies. So what's the benefit of doing this?

Let’s look at an example in code to see it in practice, and perhaps discover why we might want to do DIP in the first place:

{%highlight c# linenos%}
//Non-DIP implementation
public class Switch
{
    private Lamp lamp = new Lamp();
    void On()
    {
        lamp.TurnOn();
    }
}

public class Lamp
{
    public void TurnOn()
    {
        //Lamp implementation details
    }
}
{%endhighlight%}

We can see that `Switch` clearly has a dependency on `Lamp`. If `Lamp` needs to change, it’s entirely possible that those changes will ripple through to its interface, which would mean potential changes to any and all classes that depend on it. By now, you have seen that SOLID principles are all about compartmentalizing change--ensuring that, as much as possible, change happens in specific, focused areas so that uncertainty caused by change is localized.

You’ll also recall that SOLID also promises a longer useful life for our code. Here is an example of how this is accomplished: In the above example, `Switch` is clearly not reusable--it can’t turn on a `Heater` or a `Motor` or a `VacuumCleaner` because it has a `Lamp` baked right in.

Let's make some changes:

{%highlight c# linenos%}
public interface ISwitchableDevice
{
    void TurnOn();
}

public class Switch
{
    private ISwitchableDevice device;

    Switch(ISwitchableDevice device) //Constructor dependency injection
    {
        this.device = device;
    }

    public void On()
    {
        device.TurnOn();
    }
}

public class Lamp : ISwitchableDevice
{
    public void TurnOn()
    {
        //Lamp implementation details
    }
}
{%endhighlight%}

Now `Switch` takes any object with implements the ISwitchableDevice interface in its constructor, and stores that instance in a private variable for later use.  This form of DIP is known as **Constructor [Dependency Injection](https://en.wikipedia.org/wiki/Dependency_injection)**. For now, let's just agree that "something else" not shown here (eg. Factory, initialization routine, config file, etc.) decides what `ISwitchableDevice` should be created and passes an instance to `Switch`’s constructor. It’s not important for this article what the “something else” is (and it could be a whole set of blog posts unto itself).

Now any class willing to implement the `ISwitchableDevice` interface can be controlled by our `Switch`. It’s very clear how `Heater`, `Motor` and `VacuumCleaner` can be plugged into this system without changing any code in `Switch` at all. That is extensibility, reliability and reusability being delivered, right there.

The inversion (I in DIP) comes from the fact that `Lamp` (a low-level module) now depends on `ISwitchableDevice`, whereas originally it was `Switch` (a high-level module) which depended on `Lamp` (a low-level module).

Earlier, I promised I’d revisit the concept of “ownership” and "driving changes" into something.  We can see that a `Lamp` with a fancy dimming feature shouldn't change the `SwitchableDevice` interface.  If it did, then nothing would have changed from a code stability point of view.  Changes to `Lamp`'s interface would drive change in `ISwitchableDevice`'s interface, all its other implementations, and all users of the `ISwitchableDevice` API.  But it (should be) fairly clear that `Lamp` shouldn't be impacting `ISwitchableDevice`'s interface like that--if only by the interface's name.  Note that is is not so obvious (or even counterintuitive) if `Lamp` is its own interface (or implements a trivial abstraction like, say `ILamp`).

Instead, consider packaging the abstracted interface with the high-level modules that depend on it. This makes it clearer that the interface does not “belong” to the implementations. Any changes to the interface should be driven by the needs of the interface's clients (high-level module(s)).

If multiple high-level modules are making use of the same interface, then the interface should be packaged on its own (no single “owner”). Either strategy preserves the concept that the implementation shouldn’t own its interface.