text:
Manage Safe Members permission is required.

## PARAMETERS

    -SafeName <String>
        The name of the safe to which the safe member belong

        Required?                    true
        Position?                    named
        Default value
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -MemberName <String>
        Vault or Domain User, or Group, safe member to update.

        Required?                    true
        Position?                    named
        Default value
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -MembershipExpirationDate <DateTime>
        Defines when the member's Safe membership expires.

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -UseAccounts <Boolean>
        Boolean value defining if UseAccounts permission will be granted to
        safe member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -RetrieveAccounts <Boolean>
        Boolean value defining if RetrieveAccounts permission will be granted
        to safe member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -ListAccounts <Boolean>
        Boolean value defining if ListAccounts permission will be granted to
        safe member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -AddAccounts <Boolean>
        Boolean value defining if permission will be granted to safe member
        on safe.
        Includes UpdateAccountProperties (when adding or removing permission).

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -UpdateAccountContent <Boolean>
        Boolean value defining if AddAccounts permission will be granted to safe
        member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -UpdateAccountProperties <Boolean>
        Boolean value defining if UpdateAccountProperties permission will be granted
        to safe member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -InitiateCPMAccountManagementOperations <Boolean>
        Boolean value defining if InitiateCPMAccountManagementOperations permission
        will be granted to safe member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -SpecifyNextAccountContent <Boolean>
        Boolean value defining if SpecifyNextAccountContent permission will be granted
        to safe member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -RenameAccounts <Boolean>
        Boolean value defining if RenameAccounts permission will be granted to safe
        member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -DeleteAccounts <Boolean>
        Boolean value defining if DeleteAccounts permission will be granted to safe
        member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -UnlockAccounts <Boolean>
        Boolean value defining if UnlockAccounts permission will be granted to safe
        member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -ManageSafe <Boolean>
        Boolean value defining if ManageSafe permission will be granted to safe member
        on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -ManageSafeMembers <Boolean>
        Boolean value defining if ManageSafeMembers permission will be granted to safe
        member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -BackupSafe <Boolean>
        Boolean value defining if BackupSafe permission will be granted to safe member
        on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -ViewAuditLog <Boolean>
        Boolean value defining if ViewAuditLog permission will be granted to safe member
        on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -ViewSafeMembers <Boolean>
        Boolean value defining if ViewSafeMembers permission will be granted to safe member
        on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -RequestsAuthorizationLevel <Int32>
        Integer value defining level assigned to RequestsAuthorizationLevel for safe member.
        Valid Values: 0, 1 or 2

        Required?                    false
        Position?                    named
        Default value                0
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -AccessWithoutConfirmation <Boolean>
        Boolean value defining if AccessWithoutConfirmation permission will be granted to
        safe member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -CreateFolders <Boolean>
        Boolean value defining if CreateFolders permission will be granted to safe member
        on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -DeleteFolders <Boolean>
        Boolean value defining if DeleteFolders permission will be granted to safe member
        on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -MoveAccountsAndFolders <Boolean>
        Boolean value defining if MoveAccountsAndFolders permission will be granted to safe
        member on safe.

        Required?                    false
        Position?                    named
        Default value                False
        Accept pipeline input?       true (ByPropertyName)
        Accept wildcard characters?  false

    -WhatIf [<SwitchParameter>]

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?       false
        Accept wildcard characters?  false

    -Confirm [<SwitchParameter>]

        Required?                    false
        Position?                    named
        Default value
        Accept pipeline input?       false
        Accept wildcard characters?  false

    <CommonParameters>
        This cmdlet supports the common parameters: Verbose, Debug,
        ErrorAction, ErrorVariable, WarningAction, WarningVariable,
        OutBuffer, PipelineVariable, and OutVariable. For more information, see
        about_CommonParameters (https:/go.microsoft.com/fwlink/?LinkID=113216).

## EXAMPLES

    -------------------------- EXAMPLE 1 --------------------------

    PS C:\>Set-PASSafeMember -SafeName TargetSafe -MemberName TargetUser -AddAccounts $true

    Updates TargetUser's permissions as safe member on TargetSafe to include "Add Accounts"


text:
# logsinks

[![pub package](https://img.shields.io/pub/v/logsinks.svg)](https://pub.dartlang.org/packages/logsinks)

Provides output targets (sinks) for log messages create by the dart [logging](https://pub.dartlang.org/packages/logging) package.

Currently supported sinks:

* ConsoleLogSink: Writes the logger messages to the console. Different log levels are printed in different colors.

## Getting Started

Add `logsinks` and `logging` to your `pubspec.yaml` dependencies:
```yaml
...
dependencies:
  flutter:
    sdk: flutter

  logsinks: <current version>
  logging: <current version>
...
```

## Usage
```dart
// Import the packages.
import 'package:logging/logging.dart';
import 'package:logsinks/log_sinks.dart';

void main() {
  // Configure the logger
  Logger.root.level = Level.INFO;

  // Configure log sink to output the logger messages to the console.
  final messageSink = ConsoleLogSink();
  messageSink.attachToLogger(Logger.root);

  // Create a named logger ...
  final logger = Logger("myLogger");
  // and print "Hello World" at Level.INFO in to the console.
  logger.log(Level.INFO, "Hello World");
  // same as:
  logger.info("Hello World");

  // When you are done, dispose the sink.
  messageSink.dispose();
}

```

license: MIT

repository: soernt/logsinks

branch_name: refs/heads/master

extension: md

license_type: permissive

repo_name: soernt/logsinks


text:
With the release of SLX Mobile 2.0 there have been many major changes in how the application works. This was done not only to align with SLX Web
but to also bring faster performance, newer features and a more customize-able environment. These changes include:

* AMD script loading;
* Removed the Ext framework and replaced it with Dojo 1.7.1;
* Minor folder restructuring;
* Properties and Functions renamed to be more descriptive; and
* Additional properties and functions to enhance customizing.

## Steps to Convert

1. Change all modules (files) to use AMD loading.
1. Change all Ext calls to Dojo equivalents.
1. Verify that all modules names are fixed to reflect the new folder structure.
1. Verify that any property name changes do not effect your views or customization's.
1. Verify that the changed function names/removal do not effect your views or customization's.
1. Consider the newly added properties and methods to enhance existing customization's.

## AMD Script Loading
AMD stands for Asynchronous Module Definition which means that instead of declaring globals in every script file you use
the `define()` function to setup a module. In the definition you also declare what dependencies (requires) that module needs.
The AMD loader will load all files asynch, then define each module in the correct order passing in references to each dependency.

What this means for upgrading is that you go from:

#### Ext:
    Ext.namespace("Mobile.SalesLogix.Calendar");
    (function() {
        Mobile.SalesLogix.Calendar.MonthView = Ext.extend(Sage.Platform.Mobile.List, {
            // define view
        });
    });

#### To Dojo AMD:
```javascript
    define('Mobile/SalesLogix/Views/Calendar/MonthView', [
        'dojo/_base/declare',
        'dojo/_base/array',
        'dojo/string',
        'dojo/query',
        'dojo/dom-attr',
        'dojo/dom-class',
        'dojo/dom-construct',
        'Mobile/SalesLogix/Format',
        'Sage/Platform/Mobile/ErrorManager',
        'Sage/Platform/Mobile/Convert',
        'Sage/Platform/Mobile/List'
    ], function(
        declare,
        array,
        string,
        query,
        domAttr,
        domClass,
        domConstruct,
        format,
        ErrorManager,
        convert,
        List
    ) {

        return declare('crm.Views.Calendar.MonthView', [List], {
            // define view
        });
    });
```
While this does seem to be a lot of extra code the gains far outweigh the additional keystrokes. We now can see what other modules the `MonthView` requires, we also know the path name and no longer have to memorize global variable names.

To break down the define statement we have:
```javascript
    define('Path/To/My/Script',
        [dependencies],
    function(references), {

        /*private space*/

        return declare('My.Module.Name', [Inheritances], {
            /* definition */
        });
    });
```
##### Path/To/My/Script
This is the path to the script minus the extension. In the `index` file you can setup shortcuts (namespaces) and in this case `Mobile/SalesLogix` links to `argos-saleslogix/src`, so the final path for Month View is:
`argos-saleslogix/src/Views/Calendar/MonthView.js`, which translates to: `crm.Views.Calendar.MonthView`.

##### [dependencies]
This is an array of other script paths that this module needs to run, again using the shortcuts defined in the `index` file.

##### function(references)
This function will recieve an instance of each dependency required. The reason each dependency and reference is on its own line in the code
above is to quickly make sure there is a one-for-one match as it needs to go in the same order.

##### /*private space/*
The code inside here will only be ran once when defined, the returned object will be what actually defines the module meaning anything before the return space is private unless exposed in your returned object.

##### declare()
This is the dojo equivalent of Ext's `Ext.extend`, as it sets up a constructor (factory) to be later used with the new keyword to create instances.

##### 'My.Module.Name'
The name of the module, for our purposes this will match the path used to eliminate confusion.

##### [Inheritances]
An array of objects that this new module should inherit from - in Dojo terms these are called `mixins`.

### Notes
As seen in the first example you will no longer reference global variables as you have a local variable instance as a reference. Notice in the old Ext code we had:

`argos.List`

and now we pull it in as a dependency: `argos/List`, get passed a reference: `function(,,, List)` and then use the List variable:

`declare('crm.Views.Calendar.MonthView', [List], ...`

This happens for all globals like `crm.Format` or `argos.Convert` - you will see them pulled in and used in code as `format` and `convert`.

Naming the references is completely up to the person creating the module but the standard used by SLX Mobile, and in general Dojo, is that constructors (factories) are initial case and everything else is lowercase.

When viewing the Dojo documentation you will want to look for the `Dojo 1.7+` example which will show you the path to add as a dependency and the suggested reference name.

## Ext to Dojo Functions
Ext has been removed completely, all references to `Ext.*` and any of it's extended functions such as String.format will need to be replaced with Dojo 1.7.1 equivalents. The following is a short list of typical Ext code used in SLX Mobile and it's Dojo translation:

Ext: `Ext.namespace('my.object')`
Dojo: No longer required when defining views. For singletons, require "dojo/_base/lang" and use `lang.setObject('my.object', {})`

Ext: `Ext.extend()`
Dojo: Require "dojo/_base/declare" and use `declare()`

Ext: `Object.superclass.function.apply(this, arguments)`
Dojo: `this.inherited(arguments)`. Where `this` is in the "child" of the inherited object context.

Ext: `Ext.override(object, {})`
Dojo: Require "dojo/_base/lang" and use `lang.extend(object, {})`

Ext: `String.format('format', arg1, arg2)`. Where `{0}` = arg1
Dojo: Require "dojo/string" and use `string.substitute('format', [arg1, arg2])`. Where `${0}` = arg1

Ext: `function.createDelegate(scope, [arg1, arg2], bool appendArgs)`
Dojo: `function.bindDelegate(scope, arg1, arg2)`

Ext: `Object.on('event', handler, scope)`
Dojo: `this.connect(object, 'event', handler)`. Where `this` is in a View context

Ext: `Ext.each(myArray, function(item){}, scope)`
Dojo: Require "dojo/_base/array" and use `array.forEach(myArray, function(item){}, scope)`

Ext: `this.el`. Where `this` is in a View context
Dojo: `this.domNode`. Where `this` is in a View context

Ext: `attachmentPoints: { name : selector }`
Dojo: In the actual HTML markup add the attribute: `data-dojo-attach-point="name"`.

## Folder Re-structure
With the move to AMD the folder structure has been re-organized and since all module names are based off their physical path the object names themselves have changed.

Folder Name Changes:
`argos-sdk/src/Controls` to `argos-sdk/src/Fields`
`argos-saleslogix/src/views` to `argos-saleslogix/src/Views`

What this means for your code is if you are referencing `Account.Detail` like so:
`crm.Accout.Detail`
it is now:
`crm.Views.Account.Detail`

The same goes for Controls which are now Fields:
`Sage.Platform.Mobile.Controls.BooleanField`
to:
`argos.Fields.BooleanField`

The following modules have been moved from `argos-sdk/src/Controls` to `argos-saleslogix/src/Fields`:

* AddressField
* NameField
* PicklistField

With their name change correspondingly:
`SalesLogix.Platform.Mobile.Controls.AddressField`
to:
`crm.Fields.AddressField`

## Properties Renamed
To better describe several properties they have been renamed to a more intuitive name.

1.2: View.viewTemplate
2.0: View.widgetTemplate
Notes: Simple rename now that all Views are Dojo Dijits

1.2: List.itemTemplate
2.0: List.rowTemplate
Notes: This is the `<li>` markup for describing the rows structure, not normally changed.

1.2: List.contentTemplate
2.0: List.itemTemplate
Notes: This template sets up the markup for an item within a row (within rowTemplate). This template is overriden every view to be tailored to its entity.

1.2: Detail/Edit createLayout children fields. `name` is used for SData binding
2.0: Detail/Edit createLayout children fields. `name` is now the unique identifer, `property` is for SData binding
Notes: This is backward compatible, if `property` does not exist it will use `name` for identification and SData binding

## Function Changes

1.2: View.setTitle(value)
2.0: View.set('title', value)
Notes: The function has been removed and replaced with normal get/set.

1.2: View.isActive()
2.0: App.isViewActive(view)
Notes: Views no longer have the function it is globally available in the App namespace.

1.2: App.getActiveView()
2.0: App.getPrimaryActiveView()
Notes: Renamed

## Additional Properties

### Detail/Edit createLayout
All objects within layout now have a `name` property as a unique identifier. This includes sections, quick actions, fields, controls and related views.
The purpose of this so in `registerCustomization` the `at: function(row)` part can now use `row.name` to target any piece of the layout.

### Hash Tag Customization
Hash Tags now use the same customization engine as detail/edit views, enabling ease of modifying, inserting or removing hash tags.

    this.registerCustomization('list/hashTagQueries', 'opportunity_list', {
        at: true, // insert anywhere (hash tag queries are not ordered)
        type: 'insert',
        value: {
            tag: 'g500k',
            query: 'SalesPotential gt "500000"'
        }
    });

    this.registerCustomization('list/hashTagQueries', 'history_list', {
        // hashes are identified by their key property
        at: function(hash) { return hash['key'] === 'phonecall'; },
        type: 'modify',
        value: {
            query: 'Type eq "atMobileCall"'
        }
    });

### Toolbar Customization
Toolbars now use the same customization engine as detail/edit views (and hash tags). No longer need to override `createToolLayout()`.

    this.registerCustomization('detail/tools', 'account_detail', {
    at: function(tool){ return tool.id === 'edit'; },
    type: 'insert',
    where: 'after',
    value: {
        id: 'customButton',
        icon: 'content/images/icons/Hello_World_24.png',
        action: 'showHelloWorld'
    }
    });

### Multiple Insert Customizations
Before the registerCustomization engine would only insert one value at a time, causing multiple calls to insert items at the same place. Now you
may pass an array for the `value` key and it will insert each object sequentially at that point. Note this only works when `type` is `insert`.

    this.registerCustomization('detail/tools', 'account_detail', {
        at: function(tool){ return tool.id === 'edit'; },
        type: 'insert',
        where: 'after',
        value: [{
            id: 'b1',
            icon: 'content/images/icons/b1.png',
            action: 'b1Function'
        }, {
            id: 'b2',
            icon: 'content/images/icons/b2.png',
            action: 'b2Function'
        }]
    });
    // results in a toolbar with: [Edit][B1][B2]

### View Security
Now that secured actions is available via SData in SalesLogix 8.0+ each individual view now has a `security` property that can be set to a string defining the secured action required.

When a user logs in the security is stored in:

`App.context.userSecurity`

as a hash table with each key as the action and the value as true. If a key does not exist in that list it is assumed the user does not have the security permissions to access that view.

#### Example:
Ticket List may be defined as:

    define('...Ticket.List', [], function() { return declare('...Ticket.List', [], {
        security: 'Entities/Ticket/View'
    }); });

Say, a user named Lee has the following actions:

    App.context.userSecurity = {
        Entities/Account/View: true,
        Entities/Contact/View: true,
        Entities/Opportunity/View: true
    }

while user called Barb has these:

    App.context.userSecurity = {
        Entities/Account/View: true,
        Entities/Ticket/View: true,
        Entities/Opportunity/View: true
    }

When Lee logs in, his Home page will NOT have Tickets and he will not be able to navigate to Tickets in anyway. Even if Account Detail has a "related Tickets" shortcut it will not function.
Whereas Barb will have it on her Home page (but not Contacts).

For SalesLogix 7.5.4 and below since it does not reply with a users secured actions it will set the `userSecurity` to `null` and grant full access just as
before.

repository: Saleslogix/argos-saleslogix

branch_name: refs/heads/develop

gha_language: JavaScript

repo_name: Saleslogix/argos-saleslogix


text:
# Skypecon

A library enabling the [Skypecon](http://demoive.github.io/skypecon) catalog site to showcase all the Skype icons in their full, native quality. The usage is web-friendly and leverages all the webby things we love like CSS for animations, retina support, etc.

<!--
## Roadmap
The roadmap can be seen in [Trello](https://trello.com/b/E80u7hbd/skypecon).

## Features

- Retina support
- Different animation speeds
- Animated and non-animated versions
- Efficient bandwidth and GPU usage with CSS sprites
-->

## Usage

You're better off [playing around with the different options](http://demoive.github.io/skypecon/). But if you want some documentation, here ya go: define an HTML `<i>` tag with a class of `sc` and _one_ `sc-[icon]` type. Then alter its behavior with _at most one_ option from each set:

- **Animation**
  - `sc-hover` - only animate on hover
  - `sc-still` - prevents the animation (will override `sc-hover`)

- **Animation speed**
  - `sc-slow` - Reduces to ~20fps
  - `sc-fast` - Increases to ~40fps

- **Size**
  - `sc-2x` - Shows the icon at twice the size (40px). Has no effect on retina screens.
  - `sc-4x` - Coming soon

## Notice

This library was created with the utmost respect for the people responsible for the icons at Skype and exists to properly showcase their work (while allowing some flexibility in its demonstration as well).

There are many sites around the web that also catalog the emoticons and flags that are available in Skype, (especially for the popular hidden ones), however, none show the icons in their best potential quality (both in resolution and smoothness in the animation) of how they are shown within the Skype application. Not to mention they aren't driven by the community and don't appear easy to maintain or to scale well.

## Skype plug

The Skype team really hits a sweet spot in the set of icons they offer, achieving all of the following:

1. accurate expression/emotion captured ([avoids miscommojication](http://grouplens.org/blog/investigating-the-potential-for-miscommunication-using-emoji/))
2. sufficient variety
3. appropriate animations
4. correct level of "cuteness"

I think other emoticons available today fail in at least one of these criteria. The [Emoji](http://www.emoji-cheat-sheet.com/) set is popular but doesn't offer animation and has an over-whelming number of options. For example, I feel the following emotions don't warrant different icons:

- **tongue**: :stuck_out_tongue_closed_eyes: :stuck_out_tongue: :stuck_out_tongue_winking_eye:
- **kiss**: :kissing: :kissing_smiling_eyes: :kissing_closed_eyes: :kissing_heart:
- **smile**: :smile: :smiley: :grinning: :relieved: :grimacing: :grin:
- **laughing**: :laughing: :satisfied:
- **worried**: :worried: :persevere:
- **surprised**: :anguished: :frowning: :dizzy_face: :open_mouth: :hushed:
- **indifferent**: :neutral_face: :expressionless: :confused:
- **cry**: :sob: :cry: :sweat: :tired_face: :confounded: :weary: :cold_sweat: :disappointed_relieved: :sleepy:
- **sad**: :pensive: :disappointed:

<!--
The [Phantom Open Emoji](https://github.com/Genshin/PhantomOpenEmoji) is promising. This library offers a great framework for using their work on the web.
-->

## License

The icons were not made by me - they are the property of [Skype](http://www.skype.com/) and should be used according to their [license and usage terms](http://www.skype.com/en/legal/brand-guidelines/). All the other code is my own work and is licensed under the [MIT License](https://github.com/demoive/skypecon/blob/master/LICENSE).

## Changelog

### v1.4.10
- Added special limited edition emoticons from the Captain America movie promotion (`blackwidow`, `bucky`, `captain`, `nickfury`, `shielddeflect`)

### v1.4.9
- Added the `tauri` hidden icon

### v1.4.8
- Added hidden icons which had been available on Windows but not Mac until v6.15 (`bike`, `cat`, `dog`, `idea`, `sheep`, `skype`, `talktothehand`)
- Image files processed with imagemin
- Catalog of all emoticons in a YAML datastore

### v1.4.6
- Bumped versioning up to catch up with more accurate representation of features available (a lot of the features were added in the proof of concept)

### v0.5.3
- Fixed "playing too fast" bug on retina screens
- Fixed "white content" bug on retina screens
- Using sprite for when the non-animated images are shown (`.sc-still` & `.sc-hover`)
- Other improvements for better management of Less files

### v0.5.2
- Fixed hover bug on for non-retina hover
- Reduced output CSS file by ~20%

### v0.5.1
- Added necessary vendor prefixes

### v0.5.0
- POC already supported the following features:
  - Change animation speeds with `.sc-slow` & `.sc-fast`
  - Only animate on hover with `.sc-hover`
  - Enlarge to twice the size (40px) with `.sc-2x`
  - Prevent animation altogether with `.sc-still`

repository: Tryweirder/skypecon

repo_name: Tryweirder/skypecon


text:
# queenstown-open-data-spike
Investigations into usage of Queenstown Open Data using Ember.js

## The Plans
This project represents a technology and usefulness investigation into the current open GIS data made available by Queenstown Lakes District Council.

Immediate next steps are:
* Be able to turn some layers on and off
* See if I can find layers with any useful data

## To Install locally

1. Clone this repo
2. `npm install && bower install`
3. `ember s`
4. Browse to `http://localhost:4200`

## Contribution
The project is not specifically looking for contributors, but if you have a cool idea of something you'd like to see or if something isn't working for you, please log an issue.

repository: JonForest/queenstown-open-data-spike

repo_name: JonForest/queenstown-open-data-spike


text:
(executor-yaml-spec)=
# {octicon}`file-code` YAML specification

This page outlines the Executor YAML file specification. These configurations can be used in a {class}`~jina.Deployment` with `Deployment(uses='exec.yml)`, in a {class}`~jina.Flow` with `Flow().add(uses='exec.yml)` or loaded directly via `Executor.load_config('exec.yml')`.

Note that Executor YAML configuration always refers back to an Executor defined in a Python file.

## Example

The following is an example {class}`~jina.Executor` configuration:

```yaml
jtype: MyExecutor
with:
  match_args: {}
py_modules:
  - executor.py
metas:
  name: Indexer
  description: Indexes all Documents
  url: https://github.com/janedoe/indexer
  keywords: ['indexer', 'executor']
```

## Keywords

### `jtype`
String specifying the Executor's Python type. Used to locate the correct class in the Python files given by `py_modules`.

(executor-with-keyword)=
### `with`
Collection containing keyword arguments passed to the Executor's `__init__()` method. Valid values depend on the Executor.

### `py_modules`
List of strings defining the Executor's Python dependencies. Most notably this must include the Python file containing the Executor definition itself, as well as any other files it imports.

### `metas`
Collection containing meta-information about the Executor.

Your Executor is annotated with this information when publishing to {ref}`Executor Hub <jina-hub>`. To get better appeal on Executor Hub, set the `metas` fields to the correct values:

- **`name`**: Human-readable name of the Executor.
- **`description`**: Human-readable description of the Executor.
- **`url`**: URL of where to find more information about the Executor, normally a GitHub repo URL.
- **`keywords`**: A list of strings to help users filter and locate your package.

repository: jina-ai/jina

gha_language: Python

repo_name: jina-ai/jina


text:
# Planning with ChatScript

> Copyright Bruce Wilcox<EMAIL_ADDRESS>

> Revision 7/3/2015 CS 5.5

##  Overview
Want your chatbot to control a physical body in either a real or a virtual world. Want it to perform tasks
on your command beyond the immediately simple? You need a planner.
ChatScript comes with a preexisting one you can try out called STOCKPILE.
See the Bot Stockpile - planner doc for details.

Exploring alternatives is the domain of tree search, a mechanism which explicitly supports exploring
hypothetical situations and backtracks when they fail. There are two kinds of tree search mechanisms.

First, there is the "alpha-beta" tree search, like those used for chess. It assumes an adversary and you
take turns with him modifying the world to play a game.
Imagine planning to go buy food at the grocery store. You will go down to your car, drive to the store,
pick up the food and drive home.

But in a hostile world, you have to ask what happens if when you go to your car a criminal
has broken into it and is about to drive off. That will be bad.
But if you had a bat you could beat him and that would be OK.
But if he had his gang with him you would be outnumbered and that would be bad.
But if you had a cop with you that would be OK.
But … Clearly that branch of the tree has a lot of issues and if you can't explore them all,
maybe you should take a taxi.

Fortunately the world is rarely actively hostile to you and your plans can be simpler. You can use a
planner.
It usually assumes there is no opponent and tries to find a sequence of actions to accomplish a goal.

Planners come in three flavors— _forward chaining_, _backward chaining_, and HTN (_hierarchical task
network_).

A _forward chaining planner_ is given an explicit appearance of what the initial world looks like (a set of
facts currently true) and what the goal world looks like (a set of facts that need to become true), and it
must search forward by legal operators (actions which change facts) trying to find a way to make the
goal come true. This is more restrictive than a chess-like search because in chess we don’t know what
the board position for a win looks like (there is no one specific board image).

Forward chaining works well when there are few things you can do at any moment and you know what
the answer looks like exactly. Knowing only the primitive actions that can be taken, the current state,
and the goal state, forward planners can "discover" their way to the result with no further guidance by
randomly choosing actions and backtracking to an alternative when things don't work out. But this will
not be efficient and generally forward-chaining planners need good heuristics to avoid wasting time
researching bad moves.

A _backward chaining planner_ is also given an explicit appearance of what initial and final worlds look
like, but works backward trying to find what predecessor operator would have created the end state,
searching its way back to the beginning.

Backward chaining has a strong goal-oriented behavior so it tends to involve less search than a
forward-chainer. It, too, can work only knowing the start and end states. And it, too, may be inefficient
without any heuristics to help it choose among multiple ways backward. And because it is working
backward, backward chaining has no connection to data in the current world yet, so cannot make use of
information there. This is a serious problem in any time-dependent planning task.

HTN (_Hierarchical Task Network_) planners are given templates of how to accomplish things, exactly
like little scripts, and search by progressively refining high-level scripts into sequences of low-level
scripts. Add in backtracking, and you provide the means to try out alternative scripts to see which one
will really work in your current situation.

On one hand, having these HTN scripts makes for a very goal-oriented behavioral mechanism which
can be counted on to efficiently find reasonable plans. On the other hand, scripters bear the
responsibility for writing complete scripts. The planner cannot function by merely knowing the starting
and ending states. If the planner comes to a step where it needs a sub plan to continue, there must be at
least one usable sub plan already written.

HTN planners come in two flavors, _partial order_ and _total order_.

The _partial order HTN planner_ is somewhat like a backward chainer, in that it refines a plan by
progressively reducing higher level plans to the next lower level. This allows it to do a broad-brush
look at the solution, but leaves it isolated from current reality again, so that it can only discover critical
details are missing when it finally reaches a bottom level.

A _total order HTN planner_ is somewhat like a forward chainer, refining a plan by taking the first step in
the top-level plan, and refining it all the way down to the current world, then taking the next piece in
line at the deepest level, and refining it. That way the planner is progressively working on a plan in
which it always knows what the current or modified world actually looks like.
ChatScript uses a total order HTN planner.

## Planner Script Basics

To support planning, ChatScript adds a new top-level element type, the `plan:`.
It is a mutant hybrid of the outputmacro and the topic and looks like this:
```
plan: ^move (^from ^to)
    u: () $$distance = ^distance(^to ^from)
    u:() $$choice = horse
    u:() query(direct_sv $$choice range ?)
    u:() $$range = @0object
    u:() if ($$range >= $$distance) {end(PLAN)}
```

You declare a plan using a function name and a list of function arguments, just as you would an
outputmacro. But the body of the plan is a series of rules, just like it was a topic. The rules are all `u:`
responders because you don't want your plan to depend on what kind of sentence the user wrote and the
topic will be invoked in responder mode.

Unlike a topic, which is looking for output to the user and will execute rules until that happens, a plan
is looking for a declaration of success `^end(plan)` and will execute rules until that happens. Unlike the
topic, which is not labeled a failure if it runs out of rules, a plan that runs through the last rule without
success is a failure and so reports back to its caller.

If the plan above succeeds, the variable `$$choice` will be set to _horse_
(and incidentally `$$distance` and `$$range` will also be set).

If a plan does fail, then the world reverts to a state where the plan was apparently never called. That is,
any facts that were created are erased. Any variables that were changed are set back to their original
state. Any facts that were deleted are restored. Any output generated by the plan will be discarded. So
if the above plan fails (the horse can't go the needed distance) then the variable `$$choice` will be
undefined.

Similarly when any rule fails, changes made by that rule are reverted as though the rule had not been
tried. A call to plan looks like an ordinary function call, e.g.:
```
topic: ~test (test)
u: (test) ^move(Finland Russia)
```
Mostly plans should call plans and functions and manipulate facts and variables. And while you are in
the midst of these calls, there are some things you cannot do. You cannot call `^gambit`. No rejoinders
will be set on any rule that generates output. Plans never erase their rules (they are like a topic declared
`SYSTEM` or `KEEP`). They never become an interesting topic. You cannot do a reset on a user, or an
enable or a disable on a rule. You cannot call any print routines from within a plan.
There are a host of other functions you SHOULDN'T call because they cannot be undone if the plan fails,
but they are not explicitly blocked either.

Because a plan is a function, it returns to the caller whatever output it tries to generate, rather than
putting that output directly to the user as a topic rule would. If multiple rules generate output, it will
concatenate them together, separated by a space. The caller can thus print the output (default) or save it
to a variable.

So far there is only minimal excitement to having a plan. If it fails, it doesn't change anything
significant. But there's more.

## Backtracking Plans

You can declare multiple copies of the same plan name. If the first copy of the plan fails, the system
will find the next copy and try that, and so on. Plans are tried in the order they are compiled.
```
plan: ^move (^from ^to)

u: () $$distance = ^distance(^to ^from)
    $$choice = car
    query(direct_sv $$choice range ?)
    $$range = @0object
    if ($$range >= $$distance) {end(PLAN)}
```

The above plan is similar to the first, except I wrote the code differently (not significant) and I use a
choice of car instead of horse. So if the horse can't go the distance, maybe a car can. So we can end up
with two different forms of transport, depending on how far apart the endpoints of travel are.
But there's more. Writing multiple copies of a plan just to change the resource to be used is
redundant. Instead, you want an iterator with automatic backtracking within a plan.

## Automatic backtracking

Trying different plans automatically is all very well and good for picking different actions, but what
really makes a plan work is picking among a choice of resources (objects) to use without having to
make separate plans to do it. So, here's how we do that in ChatScript.

A rule that fails does not just erase its changes and stop immediately. It sees if it can backtrack and try
again. Perhaps this rule is known by the system to have gotten one of many possible values and so it
could try to get a different value. With a new value in hand, it can try again.
There are two kinds of backtracking operations, static and dynamic.

## Simple Iterator

The first backtracking operator involves a new engine function `^iterator()` which takes three arguments,
representing the subject, verb, and object of some series of facts. It's like a simple `^query()` function.
You will name the verb to use, and either the subject or the object to base the set on. The remaining
field will be `?`, meaning you are interested with results of that value.
```
concept: ~list0( car horse ~list1 carriage jumper)
concept: ~list1 (bird bee ~list2)
concept: ~list2 (animal vegetable)

plan: ^pickitem ()
    u: () $$tmp = ^Iterator(? member ~list0) Log(OUTPUT_ECHO $$tmp ^" " ) fail(rule)
````
Above is a hierarchically nested set of concepts and a plan to pick something from `~list0`. The rule here
is a simple example of backtracking an iterator. The iterator says to return the subject of facts whose
verb is member and whose object is `~list0`.
Such facts, are the members of that concept, and this is
exactly how the system stores concept members internally, as facts. The value from the iterator is
returned and stored on `$$tmp`.
The iterator will also have stored backtracking information. The rule
then echos that value and a space into the log file (and onto the user's console in stand-alone mode).
And then the rule fails. That's where it gets interesting.

When the rule fails, the plan will find the backtrack point of the iterator. It ignores the pattern
component and merely re-executes the output side of the rule. After which it would continue normally
with the rules after it (but there aren't any in this example). So what this iterator will do is walk the
concept set and display all the members until it fails to find any more. The iterator is exhausted. What
you would see is:
```
car horse ~list1 carriage jumper
```
It is called a _static backtrack_ because all the data needed to move on to the next value is built into the
system, you have nothing you have to maintain on your own. This is a very efficient operation with no
chance for scripting errors.

## Recursive Iterator

The iterator can also recursively walk the concept hierarchy, if you replace the ? value with ??. This
tells it to go into any concept it sees rather than just retrieving the concept name.
```
plan: ^pickitem ()
    u: () $$tmp = ^Iterator(?? member ~list0) Log(OUTPUT_ECHO $$tmp ^" " ) fail(rule)
```
This plan would print out:
```
car horse bird bee animal vegetable carriage jumper
```
before failing.

Note: A loop blocks an iterator from backtracking in a rule. However it also establishes its own
iteration context, so you can always use an iterator within a loop, even if a prior part of a rule has
established a backtracking context.

## Backtracking with fact-sets

The second backtracking collection happens with fact-sets. If you grab a fact out of a factset, there
might have been other choices to grab. So the system will automatically back up to that rule and try the
next fact from the set. So using `^pick`, `^first`, and `^last` will create automatic backtrack points.
This will work correctly only if you don't go overwrite that factset in something called from that rule.
And you want to be careful not to initialize the factset in the output part of the same rule as you use it.
So a good plan might look like this:
```
plan: ^move(^from ^to)
    u: () $$distance = ^distance(^to ^from)

    u: (query(direct_sv ^from available ? -1 ? @1))
        $$currentVehicle = ^pick(@1)
        query(direct_sv $$currentVehicle range ?)
        $$range = @0object
        if ($$range < $$distance) {^fail(rule)} else {END(PLAN)}
```
The above plan selects from transport available at ^from that has the range (fuel presumably) to reach
the goal. It does this by

1. computing the distance to the goal-oriented
2. acquiring in factset 1 all vehicles at the starting point and picking one at random
3. Getting the range of said vehicle and if it does not have the appropriate range, failing.

Failure will return to the automatic fail point of ^pick. It will re-execute the output of that rule
(avoiding re-querying the available vehicles into set 1) and pick another vehicle. If that fails, the rule
fails and it will move on to another rule.

If you can use an `^iterator()` instead of a fact-set you are better off. It will be more efficient and you
can't make any logical scripting mistakes. For particularly large sets of facts, you don't really want to
get them all into a factset at once. But if your facts are being dynamically located, fact-set backtracking
may be your only choice.

## Only One Backtrack point per Rule

Since the definition of backtracking is to return to the rule's output side and reexecute it from the start,
do not try to have more than one backtrackable thing in a rule. It won't know how to handle it. In fact, it
will declare it a runtime error when it happens.

**When a rule is done, it's done. No backtracking from outside it.**

When a rule is done, any choices it might have remaining are ignored. No failure of a later rule will
trigger a backtrack into an earlier rule.

## How to think about planning

To perform planning, the chatbot has to have a mental model of the world. This means creating facts. If
you were building a Command and Conquer style game, you'd represent locations of resources like:
```
(city1 silver 5) - city1 has 5 units of silver
(city1 gold 1)
```
and costs of production like this:
```
(jewelry gold 1) - jewelry costs 1 unit of gold
(jewelry silver 1)
```
Your plan will be hunting for availability of resources and aiming to convert them into objects, such
that when it completes its plan, it might have
```
(city1 jewelry 1)
```
You'd write scripts that handle conversion of resources into jewelry (all resources have to be in the
same place) and scripts that can move resources from one location to another (maybe picking a vehicle
and where to bring the resource from and where it is going to).

During the plan you'd be constantly representing the results of actions by killing off some facts and
creating new ones. There is even a new function `^createAttribute()` to help you simultaneously do for
some things. E.g., `(city1 gold 1)` means there is 1 unit of gold in city1.
You can't simultaneously have 2 other units of gold there if we are treating this as the sum of all gold.
So if you want to change to having 2 units of gold there as a result of dropping off another gold there,
you have to kill off the old fact and create `(city1 gold 2)`.
This is managed automatically by `^createattribute (city1 gold 2)`.

Nominally the execution of a plan will take time. Things are likely to change. So generating a plan that
lists all the micro details is often a mistake. Consider, for example, a plan to go shopping at the grocery
store. At a high level, there is how you get there, what you buy, and how you get home.
How you get there will consider the current weather, do you have car, do you have the money for a bus or taxi, etc.
Once you decide there is at least one way to get there, you can move on to other parts of the plan. Your
plan might simply be: go to the store, buy what's on the list, return home. This plan already
confirmed you had a car, so you expected to use the car.

When you come to executing the plan, you might flesh out that you have to get the car keys, enter and
start the car, and drive to the store. And while executing that sub-plan you discover the car won't start.

Since your original plan step was go to the store, you might have to substitute take a taxi. Then conduct
the rest of the plan. So how you represent your overall plan becomes an important issue. If you plan
had originally included all the steps of getting the car working, then when that fails, you may no longer
understand your plan, because it was all too detailed. Yes, you need to check that likely you can fill in
the details of some step, but that doesn't mean those details have to go in the master plan yet.

## Fact Creation
When facts are created within a plan, they are all created TRANSIENT. They will disappear at the end
of the volley unless you do something explicit to keep them.

### Loops
Backtracking is a kind of loop. So, if you do something inside a loop that would mark a backtracking
point, it will not do so. For example:
```
plan: ^acquire(^place ^resource ^quantity)

u: (^query(direct_vo ? member '~places -1 ? @4)) # find all places
loop()
    {
    $$place = ^first(@4subject) # get place
    if ($$place != ^place AND ^Has_some_resource($$place ^resource))
        {
        ^Transfer($$place ^resource ^place)
        ^End(PLAN)
        }
    }
```
Normally `^first` would be considered a backtrack point, but since it occurs within a loop, it does not set
one up. If you wanted to do backtracking, the way to write this code is:
```
plan: ^acquire(^place ^resource ^quantity)

u: (^query(direct_vo ? member '~places -1 ? @4)) # find all places

$$place = first(@4subject) # get place
if ($$place != ^place AND ^Has_some_resource($$place ^resource))
    {
    ^Transfer($$place ^resource ^place)
    ^End(PLAN)
    }
```

## Styles of Plans

There are a variety of styles of plans you can write. You can write a multiple plans as multiple solution
ideas, like to acquire a resource you can have a plan to mine it, a plan to steal it, a plan to scrap
something else to reuse a resource, etc. Or you can write a single plan that encompasses all the ways
one might accomplish the goal.

Within a plan you can make each rule test conditions and select a particular method to solve the plan.
Naturally you order these rules by the "best" first according to some criterion. Or rules of a plan might
be progressive. Rules do some of the work and if the task is incomplete, later rules do more of the
work. Or earlier rules might merely initialize data that later rules will depend upon, like selecting a
vehicle that will be used by later rules to transport material from place to place.

**Passing knowledge from a failed plan**

The planner is designed for efficiency, leaving it to you to write plans that try things in some best order.
But I could imagine a situation where you wanted to try out a bunch of plans, rate them, and then pick
the best one on some criterion. Of course to try out a plan, at the end of it you have to fail it to let the
world return to a state where you can try out the next plan.

Failing means you lose facts and variablesnyou might have used to store value information about the plan.
So what can you do?

There is a cheat. The system does not restore changes to the _ match variables. So you can pass
information around in them, concatenating text strings or whatever and then at the end decoding your
message. A match var is only good for holding about 1500 bytes of data, so you do have limits, but
match variables above 5 are rarely ever used by pattern matching, so they are free to be used by you
during a volley any way you wish.

repository: ChatScript/ChatScript

gha_license_id: MIT

repo_name: ChatScript/ChatScript


text:
# YAJL Framework

The YAJL framework is an Objective-C framework for the [YAJL](http://lloyd.github.com/yajl/) SAX-style JSON parser.

## Features

- Stream parsing, comments in JSON, better error messages.
- Parse directly from NSString or NSData.
- Generate JSON from default or custom types.
- Properly handles large numeric types.
- Document style parser.
- Error by exception or out error.

## Links

- The online [API documentation](http://gabriel.github.com/yajl-objc/).

## Install (Mac OS X)

### Installing in your project (Recommended)

- Copy `YAJL.framework` to your project directory (maybe in MyProject/Frameworks/.)
- Add the `YAJL.framekwork` files (from MyProject/Frameworks/) to your target. It should be visible as a `Linked Framework` in the target.
- Under Build Settings, add<EMAIL_ADDRESS>to `Runpath Search Paths`
- Add `New Build Phase` | `New Copy Files Build Phase`.
	- Change the Destination to `Frameworks`.
	- Drag `YAJL.framework` into the the build phase
	- Make sure the copy phase appears before any `Run Script` phases

### Installing in /Library/Frameworks

- Copy `YAJL.framework` to `/Library/Frameworks/`
- In the target Info window, General tab:
	- Add a linked library, under `Mac OS X 10.5 SDK` section, select `YAJL.framework`

## Install (iOS)

- Add `YAJLiOS.framework` to your project.
- Add the frameworks to `Linked Libraries`:
  - `YAJLiOS.framework`
  - `CoreGraphics.framework`
  - `Foundation.framework`
  - `UIKit.framework`
- Under `Framework Search Paths` make sure the (parent) directory to `YAJLiOS.framework` is listed.
- Under `Other Linker Flags` in your target, add `-ObjC` and `-all_load`

## Apps

YAJL framework is used by:

- [Yelp for iPhone/iPad](http://itunes.apple.com/us/app/yelp/id284910350?mt=8)
- Add your app here!

## Docset

Download and copy the YAJL.docset to `~/Library/Developer/Shared/Documentation/DocSets/YAJL.docset`

(You may need to restart XCode after copying the file.)

The documentation will appear within XCode:

![YAJL-Docset](http://rel.me.s3.amazonaws.com/yajl/images/docset.png)

gha_language: Objective-C

gha_license_id: NOASSERTION


text:
# ckan-aws-templates

Author<EMAIL_ADDRESS>
**Full one click deployment of Datashared AWS OpsWorks Stack via Ansible**

This stands up the www.data.qld.gov.au and www.publications.qld.gov.au aws stacks using:
* SSM
* RDS
* Redis Cluster
* OpsWorks
* Cloudfront with Lambda@Edge
* and may more features

**Features:**

* Single click Enterprise grade CKAN deployment
* User selectable VPC.
* HA DB and Web nodes.
* AWS RDS for Postgres
* User selectable instance and data volume sizes

**Cloudfront Lambda @ Edge controls**

For the system to work with updates to the lambda function, you must;
* first add a new version to cloudfront-lambdaAtEdge.cfn.yml which references the changed lambda function (there is no need for a new lambda function)
* export the new version from said cloudformation template
* update the cloudfront.yml ansible script to load the new version property name.
* you can delete previous versions after a successful real, do note that cloudfront will hold onto a lambda function and versions until its 'replication' finishes.

**QOL 2019 update**

The Datashades-OpsWorks-EFS-CKAN-Stack template has been split, with RDS and EFS setup moving to separate templates including a new VPC template. These multiple templates are handled by 'build.sh', which runs them via Ansible playbooks.

The RDS setup expects the master credentials to already exist in the Systems Manager Parameter Store at '/config/CKAN/[DEV|TRAINING|STAGING|PROD]/db/master_user' and '/config/CKAN/[DEV|TRAINING|STAGING|PROD]/db/master_password'.

var/shared-${service-name} has the basic facts for the n number of environments

**2017 Update**

We've switched back to our more traditional NFS Solr stack for a number of reasons:

GFS has some serious performance issues within larger installs. The read performance on small files is somewhat poor, and write performance is a major issue. NFS is fast, stable and far easier to set up.

SolrCloud didn't deliver the failover capability we'd hoped so we've switched back to single node Solr. With Route53 failover and rsync however, we believe a HA configuration is possible. The scripts support Route53 failover provisioning, but some work remains to actually put this functionality into practise.

The overall setup of the NFS stack is way easier. Here's the nutshell version:

* Create an instance called services1 in the NFS OpsWorks layer. Add this instance to the Solr and Redis layers before starting it.
* Start the services instance you just added to the layers in step one. Wait for it to finish setting up.
* Create an instance in the Web layer. Start it up and add it to an ELB, or set up a DNS record directly to its IP.

Common issues during set up are as follows:

* yum-cron package doesn't install sometimes due to issues with mirrors. Go to Deployments and repeat setup. This will usually see a clear run through.
* repo issues: Usually related to bad private keys or repo URLs
* Application sources: Check ckan and Solr sources. Solr in particular changes frequently.

**Assumptions:**

It's assumed that you:

* have a pretty good working knowledge of AWS, CloudFormation, OpsWorks, and CKAN and its requirements such as Solr and Postgres. Those will be necessary to troubleshoot builds when you haven't provided the correct parameters or some other obstacle gets in your way.
* have built, installed and successfully run CKAN manually on some kind of single node configuration. If not, this stack isn't designed to be something to cut your teeth on. It's been designed to be relatively foolproof, but not completely so.
* know your way around the Linux command line reasonably well and know how to deal with error logs, dependency conflicts etc.

Installation
------------
Ensure you set ssm params:
* /config/CKAN/GaIdNonProduction
* /config/CKAN/GaIdProduction
* /config/CKAN/GtmIdNonProduction
* /config/CKAN/GtmIdProduction
* /config/CKAN/cicdIpA
* /config/CKAN/cicdIpB
* /config/CKAN/cicdSecurityGroup
* /config/CKAN/ec2KeyPair
* /config/CKAN/opsVpcAccount
* /config/CKAN/opsVpcCidr
* /config/CKAN/opsVpcId
* /config/CKAN/opsVpcRole
* /config/CKAN/s3LogsBucket
Then per environment (DEV/TRAINING/STAGING/PROD)
* /config/CKAN/DEV/app/ckantest/admin_email
* /config/CKAN/DEV/app/ckantest/admin_password
* /config/CKAN/DEV/app/ckantest/beaker_secret
* /config/CKAN/DEV/app/opendata/admin_email
* /config/CKAN/DEV/app/opendata/admin_password
* /config/CKAN/DEV/app/opendata/beaker_secret
* /config/CKAN/DEV/app/publications/admin_email
* /config/CKAN/DEV/app/publications/admin_password
* /config/CKAN/DEV/app/publications/beaker_secret
* /config/CKAN/DEV/db/ckantest_password
* /config/CKAN/DEV/db/ckantest_user
* /config/CKAN/DEV/db/master_password
* /config/CKAN/DEV/db/master_user
* /config/CKAN/DEV/db/opendata_password
* /config/CKAN/DEV/db/opendata_user
* /config/CKAN/DEV/db/publications_password
* /config/CKAN/DEV/db/publications_user
* /config/CKAN/DEV/smtpRelay/region
* /config/CKAN/DEV/smtpRelay/smtpHost
* /config/CKAN/DEV/smtpRelay/smtpOverride
* /config/CKAN/DEV/smtpRelay/smtpPassword
* /config/CKAN/DEV/smtpRelay/smtpPort
* /config/CKAN/DEV/smtpRelay/smtpUsername

Final Notes
-----------

The Datashades stack as provided by Link Digital has been transformed by Qld Online team and forms the foundations for suppling an open data platform. As such it is very well maintained as its in active use.

I've personally seen a lot of "CKAN in a box" releases using Docker and other approaches. On the whole, these are fantastic for getting your
feet wet without drowning in the deep end. Datashades isn't an attempt to complete or replace any of these approachs. Rather, Datashades is
more of a high availability, "enterprise" stack built to best practise, with independantly scalable layers, easily adpated to CI work flows
and automated system maintenance.

Our hope and expectation is that it benefits the wider Public Data community and progresses the Open Data ideal.

Current AWS costs for 2 CKAN applications by 4 envirionments is just shy of 3k USD a month.

## TODO ##
Make requirements-dev look up vars/shared-${app}.var.yml and test all environment plugins
Make cicd pipe line do publications and data testing

repository: qld-gov-au/ckan-qld-infrastructure

gha_language: Gherkin

repo_name: qld-gov-au/ckan-qld-infrastructure


text:
# switch_user

[![Build Status](https://secure.travis-ci.org/flyerhzm/switch_user.png)](http://travis-ci.org/flyerhzm/switch_user)

Inspired from [hobo][0], switch_user provides a convenient way to switch current user without needing to log out and log in manually.

## Use Case

switch_user is very useful in such use cases

1. switch current users in development so that you don't waste your time to logout, login and input email (login) or password any more.

2. reproduce the user specified error on production. Sometimes the error is only raised for specified user, which is difficult to reproduce for developers, switch_user can help you reproduce it by login as that user.

## Example

Visit here: <http://switch-user-example.heroku.com>, switch the current user in the select box.

And source code here: <https://github.com/flyerhzm/switch_user_example>

## Install

Add in Gemfile.
```ruby
gem "switch_user"
```
## Usage

Add following code into your layout page.

erb

    <%= switch_user_select %>

or haml

    = switch_user_select

If there are too many users (on production), the switch_user_select is not a good choice, you should call the switch user request by yourself.

    <%= link_to user.login, "/switch_user?scope_identifier=user_#{user.id}" %>
    <%= link_to admin.login, "/switch_user?scope_identifier=admin_#{admin.id}" %>

    = link_to user.login, "/switch_user?scope_identifier=user_#{user.id}"
    = link_to admin.login, "/switch_user?scope_identifier=admin_#{admin.id}"

If you have a wildcard route in your project, add a route before the wildcard route.
```ruby
# config/routes.rb
get 'switch_user' => 'switch_user#set_current_user'
# wildcard route that will get
get ':id' => 'pages#show'
```
## Configuration

By default, you can switch between Guest and all users in users table, you don't need to do anything. The following is some of the more commonly used configuration options.
```ruby
SwitchUser.setup do |config|
  # provider may be :devise, :authlogic, :clearance, :restful_authentication or :sorcery
  config.provider = :devise

  # available_users is a hash,
  # key is the model name of user (:user, :admin, or any name you use),
  # value is a block that return the users that can be switched.
  config.available_users = { :user => lambda { User.all } }

  # available_users_identifiers is a hash,
  # keys in this hash should match a key in the available_users hash
  # value is the name of the identifying column to find by,
  # defaults to id
  # this hash is to allow you to specify a different column to
  # expose for instance a username on a User model instead of id
  config.available_users_identifiers = { :user => :id }

  # available_users_names is a hash,
  # keys in this hash should match a key in the available_users hash
  # value is the column name which will be displayed in select box
  config.available_users_names = { :user => :email }

  # controller_guard is a block,
  # if it returns true, the request will continue,
  # else the request will be refused and returns "Permission Denied"
  # if you switch from "admin" to user, the current_user param is "admin"
  config.controller_guard = lambda { |current_user, request| Rails.env.development? }

  # view_guard is a block,
  # if it returns true, the switch user select box will be shown,
  # else the select box will not be shown
  # if you switch from admin to "user", the current_user param is "user"
  config.view_guard = lambda { |current_user, request| Rails.env.development? }

  # redirect_path is a block, it returns which page will be redirected
  # after switching a user.
  config.redirect_path = lambda { |request, params| '/' }
end
```
If you need to override the default configuration, run rails g switch_user:install and a copy of the configuration file will be copied to config/initializers/switch_user.rb in your project.

If you want to switch both available users and available admins
```ruby
config.available_users = { :user => lambda { User.available }, :admin => lambda { Admin.available } }
```
If you want to use name column as the user identifier
```ruby
config.available_users_identifiers => { :user => :name }
```
If you want to display the login field in switch user select box
```ruby
config.available_users_names = { :user => :login }
```
If you only allow switching from admin to user in production environment
```ruby
config.controller_guard = lambda { |current_user, request| Rails.env == "production" and current_user.admin? }
```
If you only want to display switch user select box for admins in production environment
```ruby
config.view_guard = lambda { |current_user, request| Rails.env == "production" and current_user and current_user.admin? }
```
If you want to redirect user to "/dashboard" page
```ruby
config.redirect_path = lambda { |request, params| "/dashboard" }
```
If you want to hide a 'Guest' item in the helper dropdown list
```ruby
config.helper_with_guest = false
```
## Switch Back
Sometimes you'll want to be able to switch to an unprivileged user and then back again. This can be especially useful in production when trying to reproduce a problem a user is having. The problem is that once you switch to that unprivileged user, you don't have a way to safely switch_back without knowing who the original user was. That's what this feature is for.

You will need to make the following modifications to your configuration:
```ruby
config.switch_back = true
config.controller_guard = lambda { |current_user, request, original_user|
  current_user && current_user.admin? || original_user && original_user.super_admin?
}
# Do something similar for the view_guard as well.
```
This example would allow an admin user to user switch_user, but would only let you switch back to another user if the original user was a super admin.

### How it works

Click the checkbox next to switch_user_select menu to remember that user for this session. Once this
has been checked, that user is passed in as the 3rd option to the view and controller guards.
This allows you to check against current_user as well as that original_user to see if the
switch_user action should be allowed.

### Warning

This feature should be used with extreme caution because of the security implications. This is especially true in a production environment.

## Contributing

#### Run tests

`bundle exec rspec spec`

## Credit

Copyright © 2010 - 2015 Richard Huang (flyerhzm@gmail.com), released under the MIT license

[0]: https://github.com/tablatom/hobo


text:
## Version 0.3.1

* Fixed error on the data pipeline
* Added new fields for the **italy_total** dataset
* Added new fields for the **italy_province** dataset
* Updated Github actions:
    - Create dev and prod docker environments
    - Modify the R CMD to run with docker

## Version 0.3.0
* Updates for the **italy_total** dataset:

  - Added `positive_clinical_activity` - positive cases emerged from clinical activity
  - Added `positive_surveys_tests` - positive cases emerging from surveys and tests, planned at national or regional level

* Updates for the **italy_region** dataset:

  - Added `positive_clinical_activity` - positive cases emerged from clinical activity
  - Added `positive_surveys_tests` - positive cases emerging from surveys and tests, planned at national or regional level

* Updated the data refresh automation - set [docker image](https://hub.docker.com/r/rkrispin/covid19italy) to support the cron job on [Github Actions](https://github.com/RamiKrispin/covid19Italy/blob/master/.github/workflows/data_refresh_docker.yml)

## Version 0.2.0

* Automated the data refresh on the Github version with the use of Github Actions
* Add vignette - Visualization covid19italy with Choropleth Maps (non CRAN, available [here](https://covid19r.github.io/covid19italy/articles/geospatial_visualization.html))
* Update for the **italy_total** dataset:
  - `total_currently_positive` -> `cumulative_positive_cases`
  - `new_currently_positive` -> `daily_positive_cases`
  - `total_positive_cases` -> `cumulative_cases`
  - Add new columns:
      - `total_people_tested` - total number of people tested

* Update for the **italy_region** dataset:
  - `total_currently_positive` -> `cumulative_positive_cases`
  - `new_currently_positive` -> `daily_positive_cases`
   - Add new columns:
      - `total_people_tested` - total number of people tested
      - `region_spatial` - the spatial region name as in the output of the `ne_states` function from the **rnaturalearth** package

* Update for the **italy_province** dataset:
  - `total_positive_cases` was modified to `total_cases`
  -  `total_tests` was removed
  - Add new columns:
      - `new_cases` - add daily number of positive cases
      - `province_spatial` - the spatial province names as in the output of the `ne_states` function from the **rnaturalearth** package

## Version 0.1.0

* Release three datasets:
  - `italy_total` - national level
  - `italy_region` - region level
  - `italy_province` - province level
* `update_data` function to update the dataset to the most recent one

* Added a `NEWS.md` file to track changes to the package.

gha_language: R


text:
# Websocket components for Cascades FBP

This repository contains the following components:

 * Websocket Server
 * Websocket Client

## Websocket Server Component

Usage of Websocket server component:

```
$ ./components/websocket/server
Usage of ./components/websocket/server:
  -debug=false: Enable debug mode
  -json=false: Print component documentation in JSON
  -port.in="": Component's input port endpoint
  -port.options="": Component's options port endpoint
  -port.out="": Component's output port endpoint
```

Example (Websocket echo server):

```
# Configure server and forward its output to packet cloning component
'<IP_ADDRESS>:8000' -> OPTIONS Server(websocket/server)
Server OUT -> IN Demux(core/splitter)

# Show incoming data on the screen
Demux OUT[0] -> IN Log(core/console)

# Return receive data back to server's client
Demux OUT[1] -> IN Server
```

Running example:

```
$ bin/cascades run examples/tcp-server.fbp
runtime | Starting processes...
runtime | Activating processes by sending IIPs...
runtime | Sending 'localhost:9999' to socket 'tcp://<IP_ADDRESS>:5000'
```

Open http://www.websocket.org/echo.html and type in the following location `ws://localhost:9999/ws`. Then enter the following message `{"msg":"Hi!"}` and send it. You should receive exactly the same response back.

## Websocket Client Component

Usage of Websocket client component:

```
$ ./components/websocket/client
Usage of ./components/websocket/client:
  -debug=false: Enable debug mode
  -json=false: Print component documentation in JSON
  -port.in="": Component's input port endpoint
  -port.options="": Component's options port endpoint
  -port.out="": Component's output port endpoint
```

Example (Connecting to public websocket echo server):

```
# Configure client to connect to a public echo server
'ws://echo.websocket.org:80' -> OPTIONS Client(websocket/client)

# Output all received data on the screen
Client OUT -> IN Log(core/console)

# Configure ticker (sends timestamp every 3 seconds)
'3s' -> INTERVAL Ticker(core/ticker)

# Send ticker's timestamp to the client
Ticker OUT -> IN Client
```

Running example:

```
...
Ticker  |<PHONE_NUMBER>
Client  | Sending data from IN port to websocket...
Client  | Writer: will send to websocket [49 52 49 50 50 54 52 53 56 55]
Client  | Reader: received from websocket [49 52 49 50 50 54 52 53 56 55]
Client  | Sending data from websocket to OUT port...
Log     | IP:<PHONE_NUMBER>
...
```

As you can see above a tick `1412264587` is sent to Client, which sends it to Websocket server. The echo server responds back with the same message, which is then forwarded to Log component and shown in the terminal output.

repository: sibeshkar/cascades

repo_name: sibeshkar/cascades


text:
Opencast Studio
===============

[![Build Status](https://travis-ci.com/elan-ev/opencast-studio.svg?branch=master)
](https://travis-ci.com/elan-ev/opencast-studio)
[![Crowdin](https://badges.crowdin.net/e/d961aac56447c193679dfdb5b349e683/localized.svg)
](https://elan-ev.crowdin.com/opencast-studio)
[![MIT license](https://img.shields.io/github/license/elan-ev/opencast-studio)
](https://github.com/elan-ev/opencast-studio/blob/master/LICENSE)

A web-based recording studio for [Opencast](https://opencast.org).

Opencast Studio uses the recording capabilities built into modern browsers to
record audio and video streams. The recording happens completely in the user's
browser: no server is involved in that part. Network access is only needed to
initially load the application and to (optionally) upload the videos to an
Opencast instance.

## Supported Browsers

The following table depicts the current state of browser support.
Please note that Opencast Studio uses fairly new web technologies that are not yet (fully) supported by all browsers.
That's usually the reason for why this app does not work on a particular browser/system.
In the table, "(✔)" means partial support and/or major bugs are still present.

| OS      | Browser    | Capture Camera | Capture Screen | Record | Notes |
| --------| ---------- | -------------- | -------------- | ------ | ----- |
| Win10   | Chrome 77  | ✔   | ✔ | ✔   |
| Win10   | Firefox 68 | ✔   | ✔ | ✔   |
| Win10   | Edge 79    | ✔   | ✔ | ✔   |
| Linux   | Chrome 77  | ✔   | ✔ | ✔   |
| Linux   | Firefox 68 | ✔   | ✔ | ✔   |
| MacOS   | Firefox 70 | ✔   | ✔ | ✔   |
| MacOS   | Chrome 78  | ✔   | ✔ | ✔   | Video file does not allow seeking
| MacOS   | Safari 13  | ✔   | ✘ | ✘   | Recording seems to fail due to unsupported MIME type
| Android | Firefox 68 | ✔   | ✘ | ✔   |
| Android | Chrome 78  | (✔) | ✘ | ✔   | No camera selection. See [issue #217](https://github.com/elan-ev/opencast-studio/issues/217)
| iOS     | Safari     | (✘) | ✘ | (✘) | Many issues. For details see [issue #84](https://github.com/elan-ev/opencast-studio/issues/84)
| iOS     | Firefox    | ✘   | ✘ | ✘   | Non-Safari browsers on iOS are severely limited
| iOS     | Chrome     | ✘   | ✘ | ✘   | Non-Safari browsers on iOS are severely limited

Browsers/systems not listed in this table are not currently tested by us, so they might or might not work.

## Usage

There are mainly two ways how to use Opencast Studio.

### Standalone Version at [studio.opencast.org](https://studio.opencast.org)

This is the easiest solution in many situations. However, uploading your
recording to your own/your institution's Opencast server becomes a bit more
difficult.

In order to upload to an Opencast server from `studio.opencast.org`, that server
needs to be configured appropriately. In particular, CORS requests from Studio
need to be allowed and return the status code 200. For nginx, you need to add
this to your configuration:

```
add_header Access-Control-Allow-Origin https://studio.opencast.org always;
add_header Access-Control-Allow-Methods 'GET, POST, OPTIONS' always;
add_header Access-Control-Allow-Credentials true always;
add_header Access-Control-Allow-Headers 'Origin,Content-Type,Accept,Authorization' always;

# Always respond with 200 to OPTIONS requests as browsers do not accept
# non-200 responses to CORS preflight requests.
if ($request_method = OPTIONS) {
    # On newer nginx versions, you can optionally send an
    # Access-Control-Max-Age header to reduce the number of requests a browser
    # will send.
    #add_header 'Access-Control-Max-Age' 1728000;
    return 200;
}
```

### Self-hosted/Integrated in Opencast

Many institutions prefer a self-hosted solution. As this is a client-only
application, you can simply build Opencast Studio and then serve the resulting
static files.

More easily even, Opencast Studio will be integrated into and shipped with
Opencast itself – for versions ≥8.2. With this, you don't need to configure
your webserver (as described above) and you are more flexible in terms of
user authentication.

## Configuration

Opencast Studio can be configured in three different ways:

- the user can manually configure certain things on the settings page,
- the server can provide a `settings.json` (only applicable if you deploy Studio yourself), and
- configuration values can be given via GET parameters in the URL.

Settings configured by the user have the lowest priority and are overwritten by
both, `settings.json` and GET parameters. GET parameters also override settings
given in `settings.json`. Additionally, on the settings page, values that are
already preconfigured via `settings.json` or a GET parameter are hidden from the
user.

The following settings are currently understood by Studio. The column "shown to user" means whether or not the user can configure this value on the settings page (only if this value is not configured via `settings.json` or a GET parameter, of course).

| Name | Example | Shown to user | Notes |
| ---- | ------- | ---------------------- | ----- |
| `opencast.serverUrl` | `https://develop.opencast.org` | ✔ | The server that recordings are uploaded to. Has to include `https://`. If this is set to an empty string, the domain Studio is deployed on is used. |
| `opencast.loginName` | `peter` | ✔ | Username of the Opencast user to authenticate as |
| `opencast.loginPassword` | `verysecure123` | ✔ | Password of the Opencast user to authenticate as |
| `opencast.loginProvided` | `true` | ✘ | If this is set to `true`, `loginPassword` and `loginName` are ignored. Instead, Studio assumes that the user's browser is already authenticated (via cookies) at the Opencast server URL. This pretty much only makes sense if studio is deployed on the same domain as the target Opencast server (e.g. in the path `/studio`). |
| `upload.seriesId` | `3fe9ea49-a671-4d1e-9669-0c96ff0f8f79` | ✘ | The ID of the series which the recording is a part of. When uploading the recording, it is automatically associated with that series. |
| `upload.workflowId` | `fast` | ✘ | The workflow ID used to process the recording. |
| `recording.mimes` | `["video/mp4", "video/webm"]` | ✘ | A list of preferred MIME types used by the media recorder. Studio uses the first MIME type in that list for which `MediaRecorder.isTypeSupported` returns `true`. If none of the specified ones is supported or if the browser does not support `isTypeSupported`, then Studio lets the browser choose a MIME-type. |
| `recording.videoBitrate` | `2000000` | ✘ | The target video bitrate of the recording in bits per second. Please note that specifying this for all users is usually a bad idea, as the video stream and situation is different for everyone. The resulting quality also largely depends on the browser's encoder. |

**Note**: all data configured via `settings.json` is as public as your Studio installation. For example, if your students can access your deployed studio app, they can also see the `settings.json`. This is particularly important if you want to preconfigure an Opencast user.

#### Example `settings.json`

```json
{
  "opencast": {
    "serverUrl": "https://develop.opencast.org"
  },
  "upload": {
    "workflowId": "fast",
    "seriesId": "3fe9ea49-a671-4d1e-9669-0c96ff0f8f79",
  }
}
```

#### Example GET Parameters

GET parameters can simply be attached to the studio URL if the form `…/?option1=value1&option2=value2&…`.
They are an easy way to provide a link with specific settings to someone.
An example of such a link would be:

```
https://studio.opencast.org/?opencast.serverUrl=https://develop.opencast.org&upload.workflowId=fast&upload.seriesId=3fe9ea49-a671-4d1e-9669-0c96ff0f8f79
```

#### Debugging/Help

To check if your configuration is correctly applied, you can open Studio in your browser and open the developer tools console (via F12). Studio prints the merged settings and the current state of the connection to the Opencast server there.

## Opencast APIs used by Studio

Opencast Studio uses the following APIs:

- `/ingest/*`
- `/info/me.json`

You have to make sure that these APIs are accessible to the user using Studio.
In Opencast ≥8.2, providing a user with `ROLE_STUDIO` should grant a user all necessary rights.
In older versions, you might need to create such a role in the security configuration (e.g. `mh_default_org.xml`) of Opencast.

## Build Instructions

To build Studio yourself, execute these commands:

```sh
% git clone git@github.com:elan-ev/opencast-studio.git
% cd opencast-studio
% npm install
% npm run build
```

This will generate static content you can serve via any web server in `build/`.
That's it.

If you prefer to run a local development server directly, you can use this
instead:

```sh
% npm run start
```

### Additional Build Options

By default, Studio expects to be deployed under the root path of a domain (e.g. https://studio.example.com/) and using a
sub-path would not work (e.g. https://example.com/studio). This can be changed by using a number of build options. You
can apply these options by exporting them as environment variable before starting the build process like this:

```sh
export OPTION=VALUE
npm run build
```

| Option                    | Example            | Description
| ------------------------- | ------------------ | -----------
| `PUBLIC_URL`              | `/studio`          | Path from which Studio will be served
| `REACT_APP_SETTINGS_PATH` | `/mysettings.json` | Path from which to load the configuration

repository: ppettit/opencast-studio

repo_name: ppettit/opencast-studio


text:
#php-rackspace-clouddb

PHP Class for connecting applications to [Rackspace's Cloud Databases Service](http://www.rackspace.com/cloud/cloud_hosting_products/databases/)

**It helps view and manage:**

- API Connection
- Instances
- Database
- Users
- Flavors

##Usage - Connecting

**Simple Connection**

	<?php

		$rcdb = new RackspaceCloudDB('example user','123abc123abc123abc123abc123abc12','123456');

	?>

**Connection to Alternative Datacenter**

	<?php

		$rcdb = new RackspaceCloudDB('example user','123abc123abc123abc123abc123abc12','123456','DFW');

	?>

**Connection to London Datacenter using London Authentication**

	<?php

		$rcdb = new RackspaceCloudDB('example user','123abc123abc123abc123abc123abc12','123456','LON','UK');

	?>

##Usage - Basic

**Example One - List Instances**

	<?php

		// Set up connection
		$rcdb = new RackspaceCloudDB('example user','123abc123abc123abc123abc123abc12','123456');

		// execute request
		$responseObject = $rcdb->listInstances();

		// View Response
		echo '<pre>'.print_r($responseObject,true).'</pre>';

	?>

##Usage - Advanced

**Manual Token Generation**

	<?php

		// Set up connection (with automatic token generation off)
		$rcdb = new RackspaceCloudDB('example user','123abc123abc123abc123abc123abc12','123456','ORD','US',false);

		// Create Token
		$rcdb->createAuthToken();

	?>

##Additional Resources

[Getting Started Guide](http://docs.rackspace.com/cdb/api/cdb-getting-started-latest/index.html)

[API Developer Guide](http://docs.rackspace.com/cdb/api/cdb-devguide-latest/index.html)

[How-to and Other Resources](http://www.rackspace.com/knowledge_center/content/cloud-databases-how-articles-other-resources)

[Code Samples and Bindings](http://www.rackspace.com/knowledge_center/content/cloud-databases-sample-code-bindings)

[Release Notes](http://docs.rackspace.com/cdb/api/cdb-releasenotes-latest/index.html)

##License

Unless otherwise noted, all files are released under the MIT license, exceptions contain licensing information in them.

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

repository: iaincollins/php-rackspace-clouddb

repo_name: iaincollins/php-rackspace-clouddb


text:
---
layout: docs
title: 'Collection'
---

Represents a collection of database objects. Note that it will not contain any objects by itself. Instead, it yields a preparation for how to execute a DB query. A query will be executed when calling methods that returns a Promise, such as [toArray()](/docs/Collection/Collection.toArray()), [keys()](/docs/Collection/Collection.keys()), [count()](/docs/Collection/Collection.count()) or [each()](/docs/Collection/Collection.each()).

### Construction

Collection constructor is private. Instances are returned from the [WhereClause](/docs/WhereClause/WhereClause) methods and some of the [Table](/docs/Table/Table) methods.

### Samples

```javascript
// each()
var collection = db.friends.where('name').equalsIgnoreCase('david');

collection.each(function(friend) {
    console.log('Found: ' + friend.name + ' with phone number ' + friend.phone);
});
```

```javascript
// toArray()
db.friends.where('name').startsWithIgnoreCase('d').toArray(function(friends) {
    console.log("Found: " + friends.length + " friends starting with d");
});
```

```javascript
// offset/limit
db.friends
  .where('age').above(25)
  .offset(10)
  .limit(10)
  .toArray(function (friends) {
    console.log(friends.map(JSON.stringify).join('\n'));
  });
```

```javascript
// count
db.friends.toCollection().count(function (count) {
    console.log(count + " friends in total");
});
```

```javascript
// or
db.friends
  .where('age').above(25)
  .or('shoeSize').above(9)
  .each (function (friend) {
    console.log("Found big friend: " + friend.name);
  });
```

### Methods

#### [and()](/docs/Collection/Collection.and())
Add JS based criteria to collection

#### [clone()](/docs/Collection/Collection.clone())
Clone the query before manipulating it further (Does not clone database items).

#### [count()](/docs/Collection/Collection.count())
Get the number of items in the collection

#### [delete()](/docs/Collection/Collection.delete())
Delete all objects in the collection

#### [desc()](/docs/Collection/Collection.desc())
Sort in descending order

#### [distinct()](/docs/Collection/Collection.distinct())
Remove duplicates of items with same primary key

#### [each()](/docs/Collection/Collection.each())
Execute query and call a function for each item

#### [eachKey()](/docs/Collection/Collection.eachKey())
Execute query on the index or primary key being used and call a function for each key

#### [eachPrimaryKey()](/docs/Collection/Collection.eachPrimaryKey())
Execute query on the index and call a function for each primary key that corresponds to the index.

#### [eachUniqueKey()](/docs/Collection/Collection.eachUniqueKey())
Execute query on the index or primary key being used and call a function for each unique key

#### [filter()](/docs/Collection/Collection.filter())
Filter objects

#### [first()](/docs/Collection/Collection.first())
Get the first item in the collection

#### [keys()](/docs/Collection/Collection.keys())
Retrieve an array containing all keys of the collection (index or primary key depending on where() clause)

#### [last()](/docs/Collection/Collection.last())
Get the last item in the collection

#### [limit()](/docs/Collection/Collection.limit())
Limit the result to given number of items

#### [modify()](/docs/Collection/Collection.modify())
Modify all objects in the collection with given properties or function.

#### [offset()](/docs/Collection/Collection.offset())
Ignore N items before given offset and return the rest

#### [or()](/docs/Collection/Collection.or())
Logical OR operation

#### [primaryKeys()](/docs/Collection/Collection.primaryKeys())
Retrieve an array containing all primary keys of the collection

#### [raw()](/docs/Collection/Collection.raw())
Don't filter results through [reading hooks](/docs/Table/Table.hook('reading'))

#### [reverse()](/docs/Collection/Collection.reverse())
Reverse the order of items.

#### [sortBy()](/docs/Collection/Collection.sortBy())
Execute query and get an array with the results sorted by given property

#### [toArray()](/docs/Collection/Collection.toArray())
Execute query and get an array with the results sorted by the index used in the where() clause

#### [uniqueKeys()](/docs/Collection/Collection.uniqueKeys())
Retrieve an array containing all unique keys of the collection (index or primary key depending on where() clause)

#### [until()](/docs/Collection/Collection.until())
Ignores items occurring after given filter returns true.

branch_name: refs/heads/gh-pages


text:
# Changelog

## [5.0.0] - TBA

### Added

- `@dicebear/avatars-pixel-art`
  Replacement for `male`, `female` and `human` avatar styles.

- `@dicebear/avatars-shapes`
  Replacement for `jdenticon` avatar style.

- `@dicebear/avatars-micha`
  New avatar style. Designed by [Micah Lanier](https://dribbble.com/micahlanier).

- `@dicebear/avatars-cli`
  Official Dicebear Avatars CLI.

### Changed

- Package `@dicebear/avatars-avataaars-sprites` renamed to `@dicebear/avatars-avataaars`.

- Package `@dicebear/avatars-bottts-sprites` renamed to `@dicebear/avatars-bottts`.

- Package `@dicebear/avatars-gridy-sprites` renamed to `@dicebear/avatars-gridy`.

- Package `@dicebear/avatars-identicon-sprites` renamed to `@dicebear/avatars-identicon`.

- Package `@dicebear/avatars-initials-sprites` renamed to `@dicebear/avatars-initials`.

#### @dicebear/avatars

- Classes are rewritten as functions. This allows direct access to the `createAvatar` function without having to
  initialize an object first.

  Old API

  ```js
  import Avatars from `@dicebear/avatars`;
  import style from `@dicebear/avatars-identicon-sprites`;

  let options = {};
  let seed = 'custom-seed';
  let avatars = new Avatars(style, options);
  let svg = avatars.create(seed);
  ```

  New API

  ```js
  import { createAvatar } from `@dicebear/avatars`;
  import * as style from `@dicebear/avatars-identicon`;

  let svg = createAvatar(style, {
    seed: 'custom-seed',
    // ... and other options
  });
  ```

- The following options have been renamed:

  - `background` => `backgroundColor`

### Removed

- `@dicebear/avatars-male-sprites`
  Use `@dicebear/avatars-pixel-art` instead.

- `@dicebear/avatars-female-sprites`
  Use `@dicebear/avatars-pixel-art` instead.

- `@dicebear/avatars-human-sprites`
  Use `@dicebear/avatars-pixel-art` instead.

- `@dicebear/avatars-jdenticon-sprites`
  Use `@dicebear/avatars-shapes` instead.

#### @dicebear/avatars

- The following options have been removed:

  - `base64` => Use `dataUri` instead.

## Older Versions

- [4.x](https://github.com/DiceBear/avatars/blob/v4/CHANGELOG.md)

repository: hyzco/dicebear

branch_name: refs/heads/main

repo_name: hyzco/dicebear


text:
---
title: Overcoming the common parenting mistakes
feature_image:
  image: https://res.cloudinary.com/whanganuihigh/image/upload/v1599084398/News/joseph_driessen_RCP_20.8.20.jpg
news_author:
  date: 2020-08-19T22:01:58.633Z
  publication: River City Press
show_in_slider: false
date: 2020-09-02T22:01:58.661Z
---
Education Consultant, Joseph Driessen, who once taught at Whanganui High School, is often asked about good parenting tips. This article summarises his top ten parenting mistakes and how to overcome them.

1. Not keeping calm
• It is only natural to get angry as a parent but we need to commit to a more peaceful approach – to walk away from an argument and then start again the next day.

2. Using extreme language
• So easy to do but we need to keep our language moderate and constructive.

3. Focusing only on ‘bad’ behaviour
• Joseph says “Coach, rather than criticize.”

4. Ignoring ‘good’ behaviour
• Focus in on your child’s strengths and weaknesses and the child will start to become more aware of their own strengths.

5. Labelling a child as ‘bad’
• A child repeatedly told they’re ‘bad’ will likely internalise and come to believe that idea.

6. Collapsing into ‘learned helplessness’
• We need to talk with a friend or relative, possibly attend a positive parenting course to improve our parenting skills.

7. Isolating yourself because of your child’s behaviour
• Instead of battening down the hatches, we need to seek support.

8. Holding on to anger
• We need to move from anger to forgiveness. Use positive attention to their negative attention.

9. Being overly authoritarian
• Steamrolling will provoke active or passive resistance. We need to move from ‘my way or the highway’ to more listening, talking and negotiation.

10. Being overly permissive
• Children need limits and boundaries. They feel more secure. Have the courage to take on little battles.

You can read more on Joseph’s recommendations at https://
www.rnz.co.nz/national/ programmes/ninetonoon

gha_language: Blade


text:
## What does puts do?

#### puts writes on the screen what comes after it without actually evaluating the code. It prints the output with a new line.

## What is an integer? What is a float?

#### An *integer* is any number without decimal points and if you include decimal points you will have a *float*.

## What is the difference between float and integer division? How would you explain the difference to someone who doesn't know anything about programming?

#### So since integers have no decimal point and floats do, the same goes for their corresponding styles of division. For instance if you "puts 9 / 2" in ruby, you will get "4" back instead a calculator's answer of "4.5". This is actually not necessarily the wrong answer but you can interpret the asnwer as being what would happen if you went grocery shopping for apples, you have $9 and the apples are $2 each. Since you cannot buy half an apple you would only be able to purchase 4 apples. That is a word problem example of integer division. Float division is more towards what a calculator will do. If you "puts 9.0 / 2.0" you will get back "4.5". You must make sure to add your decimal points, otherwise ruby will consider you automatically using integers!

*Hours in a year*

```Ruby
puts 365 * 24
```

*Minutes in a decade*

```Ruby
puts (24*60) * (365*10)
```

[4.2.1](https://github.com/Tooconfident/phase-0/blob/master/week-4/defining-variables.rb/ "4.2.1")

[4.2.2](https://github.com/Tooconfident/phase-0/blob/master/week-4/simple-string.rb/ "4.2.2")

[4.2.3](https://github.com/Tooconfident/phase-0/blob/master/week-4/basic-math.rb/ "4.2.3")

## How does Ruby handle addition, subtraction, multiplication, and division of numbers?
#### Very simliar to a calculator. You use (1+2) for addition, - for subtraction, / for division and * for multiplication.

##What is the difference between integers and floats?
#### Integers are whole numbers with no decimal point. Floats include the decimal point.

#What is the difference between integer and float division?
#### So since integers have no decimal point and floats do, the same goes for their corresponding styles of division. For instance if you "puts 9 / 2" in ruby, you will get "4" back instead a calculator's answer of "4.5". This is integer division. Once you include the decimal points, this is float division and more like what a traditional calculator will do.

##What are strings? Why and when would you use them?
#### Strings are a group of letters, words or text found within quotation marks and are just a set of characters, usually contructing a sentence of the human language. You would use them when you want your program to print out a question or response to user inputs with a sentence instead of a number.

##What are local variables? Why and when would you use them?
####A local variable begins with a owr case letter or _ and are used to hold data to be used in a ruby program. You assign this data by giving the variable a name and a value (variable_name = value). One you assign the value of the variable, you can call on the name throughout you program.

##How was this challenge? Did you get a good review of some of the basics?
#### Absolutely. This challenge helped dust the rust off from what we learned before our interview process.

gha_language: Ruby