The Developer Rig can be used in two modes to test your Extension, Online Mode and Local Mode. Online Mode will let you test with production APIs and hosted assets on Twitch, but will first require completion of Extensions Developer onboarding here. The Rig also supports Local Mode to let you get started building quickly pre-onboarding, using mock versions of the APIs.
Take these steps to get Hello World running in Local Mode in the Rig.
scripts
folder in the developer-rig
folder.run
file on Mac, run.cmd
file on Windows. The first time you run the script it will take a while since it will install and configure all of the dependencies.When you are done using the Developer Rig, close all opened terminal windows or command prompts.
There are detailed guides for Mac and Windows that describe what the above script does to get you from nothing to Hello World.
See additional documentation on how to use the Developer Rig in Local Mode here: Using Local Mode
If you're looking to move past Local Mode and run the Rig in Online Mode, go here: Getting Started in Online Mode
Think of Twitch Extensions as Apps for Twitch. Developers can create sandboxed web applications that run on Twitch that provide new and different ways for viewers and broadcasters to interact.
To build the simplest Extension, a developer creates a web application (a collection of assets that include HTML, CSS, and Javascript) and then hosts these assets from the Twitch CDN ext.twitch.tv. A more complicated but more common Extension leverages an Extension Back-end Service (EBS). An EBS is a web service written by a developer for managing the state of their Extension. These two blocks of developer written code are often referred to as the front-end and the back-end.
Developers are currently completely responsible for operating their back-ends.
The Twitch Developer Site is currently where the lifecycle of an Extension is managed. This includes creation, front-end asset upload, submitting to review, and promoting to be released. The Dev Site is where key pieces of data are retrieved to configure and run the Developer Rig.
The Developer Rig hosts Extension front-ends locally. This gives developers complete flexibility to run and test their Extensions without needing to load Twitch. For example, the Developer Rig does not currently stream video, reducing friction for testing a Video Overlay Extension. Additionally, multiple views of a single Extension can be loaded onto a single page, giving developers a single pane of glass for the different relevant views for their Extension.
The Developer Rig is a tool that enables Twitch Extensions developers to iterate more quickly and focus on building great Extensions, by providing a single pane of glass for all end user Extensions views and interactions. It is a lightweight web app that runs in a browser and is built using NodeJS 6+ and React. The Developer Rig allows Extensions Developers to quickly and easily, locally end-to-end test in development Extensions.
The Developer Rig renders Extensions in a combination of user contexts, views and different anchor types.
Supported user contexts include:
Supported views include:
Supported anchor types include:
Extension output logs can be redirected to the Rig Console, a Developer Rig specific local console.
If you're just getting started with Extensions and haven't gone through Extension Developer Onboarding, follow the steps at the top of the documentation for Local Mode. Otherwise, the following guide will help you create your first Extension on Twitch and run it in the Developer Rig in Online Mode.
There are detailed guides for Mac and Windows to get you from nothing to Hello World.
For each Extension to be tested online in the Developer Rig, a corresponding Extension needs to be created on the Twitch Dev Site. More detailed instructions to do this can be found here. Most fields are not relevant for the Developer Rig. The Type of Extension is loaded into the Developer Rig, and is hence important. Similarly, the Author Email must be correctly set and verified, before an Extension secret can be created.
There are several highly pertinent pieces of data that need to be taken from the dev site, and surfaced in the Developer Rig for it to operate. These include:
These are hard requirements that enable the Developer Rig to function correctly in Online Mode!
Where possible, the Developer Rig is self-contained. Note that you should sign in with your Twitch credentials in Local Mode before using online mode, as it provides necessary information for the Rig Configuration.
If you are new to building Twitch Extensions, read this first.
There are several pieces of configuration that the Developer Rig requires to function correctly:
Client ID: the unique identifier for your Extension. Go to the Extensions Dashboard, select the Extension you want to run in the Developer Rig, then look for Client ID
under About This Extension
.
Extension Secret: a valid secret, that allows your Extension to authenticate. Go to the Extensions Dashboard, select the Extension you want to run in the Developer Rig, select the settings
tab, and then navigate to Secret Keys
and create/retrieve a valid secret.
This is not the Client Secret field located on the General tab under settings. Please ensure to go to Secret Keys.
Version: the exact version of an Extension to be loaded in the Developer Rig. Go to the Extensions Dashboard, find the Extension you want to run in the Developer Rig, and take note of the version number displayed under status
.
Values for these fields need to be injected as environment variables to the Developer Rig at startup. The environment variables names are:
EXT_CLIENT_ID
EXT_SECRET
EXT_VERSION
If you don't want to set these values via environment variables, all but the extension secret can be set through a configuration file. This file is specified via a command line argument and is in the format of
{
"clientID": "<client id>",
"version": "<version>"
}
Ensure that the Developer Rig dependencies are installed and required configuration is available.
To start the rig with environment variables, run:
Mac:
EXT_CLIENT_ID=<client id> EXT_SECRET=<secret> EXT_VERSION=<version> yarn start
Windows:
SET EXT_CLIENT_ID=<client id>& SET EXT_SECRET=<secret>& SET EXT_VERSION=<version>& yarn start
(Note the lack of spaces before the ampersands.)
To start the rig with a configuration file and command line arguments, run:
yarn start -s <secret> -c location/of/your/config
The location of your configuration file can be either relative to the directory you are running the command or an absolute path to the file.
This will cause your browser to open to https://localhost.rig.twitch.tv:3000
.
The Developer Rig UI presents a variety of views, anchors, and contexts.
This is likely the most used area for the Developer Rig. Views, anchors, and contexts can be configured to support comprehensive testing of an Extension.
Click the plus
button to add a new view for the configured Extension Client ID, and remove them by clicking on the x
on a view.
This section displays the Broadcaster Config view that is presented to broadcasters after they have installed an Extension, but before they are able to activate it.
This section displays the Live Config view that appears on a broadcaster's dashboard for an Extension.
The section displays manifest data pulled from Twitch for the corresponding Extension Client ID.
At the bottom of every page, there is the Developer Rig Console. Extensions are able to output directly to this console by making the following call from their Extension's front-end javascript:
window.Twitch.ext.rig.log(<message to log>)
Each view is prefixed with the corresponding "user context", i.e logged in viewer, broadcaster etc. An active video stream is not required to leverage video overlays in the Developer Rig. When an Extension is running in the Developer Rig, developers can interact with it just like an end user.
For developers currently in the Bits Limited Preview, this tab will let you configure your various bits products for use in your extension. You will need to sign in with your developer credentials to get this working. If you are not currently in the Bits Limited Preview, you will not be able to access this page (but stay tuned for when it goes to general availability).
By default, the Developer Rig links to example Extension code available on GitHub. To pull and link this code into the Developer Rig, run:
# Usage: yarn extension-init -a [github_account] -r [github_repo] -d [directory]
yarn extension-init -d <directory>
To have the Developer Rig host the front-end assets of an Extension, use the host
command. Assets for the example Extension can be hosted on https://localhost.rig.twitch.tv:8080
by issuing the following command:
# Usage: yarn host -d <directory> -p [port]
yarn host -d <directory>/public -p 8080
Ensure that the URL that the example Extension's Extension Back-end Service (EBS) is running on and the Extension secret, match what is specified in the dev site!
In the above screenshot, assets are specified as being available at:
https://localhost:8080/viewer.html
https://localhost:8080/config.html
If the Developer Rig is used to host
an Extension's front-end assets, the Testing Base URI must be set to:
https://localhost.rig.twitch.tv:[port]
When an Extension has been loaded into the Developer Rig, refreshing your browser window will cause the latest Extension assets to be pulled into the page.
Conceptualizing how an Extension works can be tricky, particularly in the context of the Developer Rig. Three main pieces are needed:
yarn start
)yarn host
)The Developer Rig loads the front-end assets into its pages. The front-end pages are able to call the EBS (signing requests with the Extension's JWT). An EBS can either respond directly to a front-end client, or is able to push messages to all connected front-ends via PubSub.
If you are experience difficulties getting things to work:
Local Mode enables developers to run their extension projects against mock APIs and mock PubSub locally on their machine. Developers can start building extensions without having first gone through the Twitch Extension Developer onboarding. Additionally, it provides an ability to perform integration tests against your extension via configurable responses to the Extensions Helper Library. The following sections will illustrate how to use Local Mode in the Rig.
There are several options for creating an extension manifest file. The
example above creates an extension manifest file for a panel extension.
There are four types of extensions. You may specify multiple types
for the -t
parameter, any combination of panel, video_overlay,
mobile and video_component. There are other options for panel or
component attributes along with some text descriptors. They all have
reasonable defaults; specifying them is optional. For more information
on the available options, run yarn create-manifest -h
in a terminal
window. Note that you can edit the JSON file to make changes or
adjustments.
After having created a suitable manifest, you can launch the rig in local mode using yarn start -l manifest.json
The foundation of Local Mode is a JSON document called the "Run List". It provides developers the ability to trigger specific callback responses through the Extensions Helper Library. To your extension, it will appear like these have come from Twitch Extension APIs.
When you get the Local Mode edition of the rig, it will contain a Run List pre-populated with mock responses. You'll be able to alter these responses by directly editing the document.
When Local Mode is enabled, each extension view will have a dropdown that enables the developer to choose a response from the "Run List". When a response is selected, clicking the "Trigger" button will send it through the Extension Coordinator and it will pass through Helper to your extension code.
Different views can be pointing at different places in the "Run List" at the same time.
For more details about the APIs and responses see the documentation here.
To edit the "Run List" look for the document called runlist.json in your Rig directory. Each entry in the Run List has 3 components:
Refer to the Helper API documentation here before editing and creating new responses.
When you use Local Mode with your EBS, you'll be using a hard-coded secret in the Rig. This is also included already in the Hello World example. When creating an extension on Twitch, you'll have your own client ID and secret.
The base-64-encoded Local Mode Secret is: kkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkkk
Do not expose your EBS beyond your local machine while using the Local Mode secret. It is purely meant to speed up initial development.
When you are in Local Mode, to make calls to Pub Sub, it's important to make sure your EBS is pointing at the correct URI. You'll want to be making calls to localhost.rig.twitch.tv:3000/extensions/message
as opposed to api.twitch.tv/extensions/message
in order to correctly send your message. Format the rest of your message the same as if you were sending to Twitch PubSub. See the Hello World backend.js
file for examples.
After you create your local extension manifest, you can open up manifest.json
and edit the fields directly. Most of the fields are not relevant to running your extension locally in the Developer Rig, but you should be aware of a few:
name
: Not critical for Local Mode, but it's always important to give your project a sweet nameanchor
: This should be left blankpanel_height
: This is the height of a panel extension. Default is 300 pixels and must be between 100 and 500 pixels. For Panel extensions only.host
command, be sure to make sure the port and base URI are correct.aspect_width
: expressed as a % of the screen width and must be < 50%. Note that the manifest file will express 30% as 3000. For Component Extensions only.aspect_height
: expressed as a % of the screen height from 1% to 100%. Note that the manifest file will express 30% as 3000. For Component Extensions only.zoom_pixels
: default is 1024. For Component extensions only.zoom
: default is true
. For Component Extensions onlyWhen creating additional manifests, use the -h flag to see what additional arguments you can add.
Can I use the Developer Rig without first completing Extensions Developer On-boarding?
Yes, but you must use the Developer Rig in Local Mode. For Online Mode, valid client IDs and Extension secrets are required to leverage the Developer Rig. Currently, these can only be generated on the Twitch Dev Site, once on-boarding is complete.
Are the Extensions Actions supported?
Extensions Actions will be added shortly to the Developer Rig.
XXX in the Developer Rig sucks! The Developer Rig is missing feature YYY!
Neither of these are questions :) . Raise a PR with proposed changes, and let's help each other!
What are these Twitch Extensions of which you speak, and how can I learn more?
More information about Twitch Extensions is available on the Twitch Developer Site, and in the Twitch Developer Forums.
What browsers and platforms are supported?
We know the Developer Rig works in Chrome and Firefox on Mac and Windows. Feel free to help ensure it works in other browsers and platforms!
What are the transparent purple zones in the Video Overlay view and the Component view?
These are the areas where your extension cannot be interacted with due to Twitch Video Player elements. Please see Desiging Extensions for more details.
The Extension I have specified is not appearing the Developer Rig.
There are a number of things that can create problems. The most common causes are: invalid NPM or NodeJS installations; a missing host file entry for the Developer Rig; misconfigured Environment variables being passed to the Developer Rig; or Extension configuration that does not match the contents of the Twitch Developer Site.
I am certain that my Developer Rig Configuration is correct, but my Extension is still not working.
Clear your browser cache and local storage, restart the Developer Rig, and cross your fingers. To delete its local storage, use your browser's developer tools to do so then refresh your browser. Ensure you've included the Twitch Extension Helper in your front-end files.
I see an error when attempting to run yarn test
.
Sometimes deleting and reinstalling your
node_modules
can correct this issue. On MacOS, you may need to explicitly install watchman viabrew install watchman
.
yarn install
fails in libssh2
See issue #48. Be sure
libssh
and its dependencies are installed.
I get an error when pulling in the example project!
Ensure that Git is in your PATH variable by attempting to run "git" at your commmand line. If that works, also ensure that you don't already have the example project folder.
The Developer Rig stops running unexpectedly in Local Mode.
Try deleting the
node_modules
directory and rerunningyarn install
.
I recently updated Windows and now the scripts don't run.
Turn on "Developer mode" in the "For developers" settings. (Press Windows-X and select "Settings". "For developers" is under "Update & security".) Also, ensure the last checkbox on that page (the one for PowerShell script execution policy) is checked.


|
libpqxx 4.0
|
Iterator for rows (tuples) in a result. Use as result::const_iterator. More...
#include <result.hxx>
Iterator for rows (tuples) in a result. Use as result::const_iterator.
A result, once obtained, cannot be modified. Therefore there is no plain iterator type for result. However its const_iterator type can be used to inspect its tuples without changing them.
Reimplemented from pqxx::tuple.
| typedef const tuple* pqxx::const_result_iterator::pointer |
Reimplemented from pqxx::tuple.
Reimplemented from pqxx::tuple.
Reimplemented from pqxx::tuple.
| pqxx::const_result_iterator::const_result_iterator | ( | ) | throw () |
| pqxx::const_result_iterator::const_result_iterator | ( | const tuple & | t | ) | throw () |
| bool pqxx::const_result_iterator::operator!= | ( | const const_result_iterator & | i | ) | const |
| reference pqxx::const_result_iterator::operator* | ( | ) | const |
| const_result_iterator pqxx::const_result_iterator::operator+ | ( | result::difference_type | o | ) | const |
Reimplemented in pqxx::const_reverse_result_iterator.
| const_result_iterator& pqxx::const_result_iterator::operator++ | ( | ) |
Reimplemented in pqxx::const_reverse_result_iterator.
| pqxx::const_result_iterator pqxx::const_result_iterator::operator++ | ( | int | ) |
Reimplemented in pqxx::const_reverse_result_iterator.
| const_result_iterator& pqxx::const_result_iterator::operator+= | ( | difference_type | i | ) |
Reimplemented in pqxx::const_reverse_result_iterator.
| const_result_iterator pqxx::const_result_iterator::operator- | ( | result::difference_type | o | ) | const |
| result::difference_type pqxx::const_result_iterator::operator- | ( | const_result_iterator | i | ) | const |
References pqxx::tuple::num().
| pqxx::const_result_iterator pqxx::const_result_iterator::operator-- | ( | int | ) |
Reimplemented in pqxx::const_reverse_result_iterator.
| const_result_iterator& pqxx::const_result_iterator::operator-- | ( | ) |
Reimplemented in pqxx::const_reverse_result_iterator.
| const_result_iterator& pqxx::const_result_iterator::operator-= | ( | difference_type | i | ) |
Reimplemented in pqxx::const_reverse_result_iterator.
| pointer pqxx::const_result_iterator::operator-> | ( | ) | const |
The iterator "points to" its own tuple, which is also itself. This allows a result to be addressed as a two-dimensional container without going through the intermediate step of dereferencing the iterator. I hope this works out to be similar to C pointer/array semantics in useful cases.
IIRC Alex Stepanov, the inventor of the STL, once remarked that having this as standard behaviour for pointers would be useful in some algorithms. So even if this makes me look foolish, I would seem to be in distinguished company.
| bool pqxx::const_result_iterator::operator< | ( | const const_result_iterator & | i | ) | const |
| bool pqxx::const_result_iterator::operator<= | ( | const const_result_iterator & | i | ) | const |
| bool pqxx::const_result_iterator::operator== | ( | const const_result_iterator & | i | ) | const |
| bool pqxx::const_result_iterator::operator> | ( | const const_result_iterator & | i | ) | const |
| bool pqxx::const_result_iterator::operator>= | ( | const const_result_iterator & | i | ) | const |
| const_result_iterator operator+ | ( | result::difference_type | o, |
| const_result_iterator | i | ||
| ) | [friend] |
friend class pqxx::result [friend] |


PaymentRequest API demos
Specifications
PaymentRequest API specification
[
repo
] (
adrianba fork
[
repo
])
Payment Method Identifiers specification
[
repo
] (
adrianba fork
[
repo
])
Basic Card specification
[
repo
] (
adrianba fork
[
repo
])
#
Demo
1
Simple request with no shipping
2
Request shipping address with free worldwide delivery
3
Request shipping address and calculate shipping options
#
Tests
1
PaymentRequest Tests
[
demo repo
]


Lamination and Vaccum Forming
16 - 31 October 2018
This week, we used vaccum forming, subtractive manufacturing, and other techniques to make skateboards and molds. The software I used
this week included Fusion 360 and Photoshop.
Assignment 1: Skateboard
This week, we made skateboards from pre-prepared wood. We received seven thin strips of wood, arranged in an alternating pattern of
inflexible and flexible. The inflexible pieces were the ones cut with the grain of the wood, and the flexible pieces were cut
perpendicular to the grain of the wood. The inflexible pieces went on the outside and then alternated with flexible ones in the middle,
in order to give the board both stability and flexibility. We used Titebond III glue to hold it all together, and from there the
process diverged.
For those of us making a pintail skateboard, which is straight and flat, all we had to do from there was sandwich our board between
two larger wood boards and use clamps to hold it all together so that when we retrieved our boards a day later, they would be
fully attached and straight.
For the people making more traditional skateboards, they used vaccum bags and vaccum forms to form the boards. They placed their
boards on top of the vaccum forms inside the vaccum and pumped all the air out of the bag, leaving the skateboard in the shape of the mold.
They left their boards in the bags until the next class, and when they returned, their boards remained in their shape.
Once my board was glued, the edges were pretty uneven, so I had to use a disk sander to even them out. Once that was finished,
I used photoshop to create the design for the bottom of the board. I had to figure out how to remove the background from a picutre
I found of a Saturn V using Photoshop and then put in a solid blue background. After that, I printed out the design on sticker
paper and stuck it on the skateboard.
Assignment 2: Chocolate Mold
This week, we made molds in order to make chocolate in various shapes. This required a number of steps with a variety of processes.
First, of course, we had to decide on an image and create a .stl file from that image. To make a .stl from an image, we first had
to convert it to a .dxf in CorelDRAW, then import that .dxf to Fusion 360, extrude parts of it, and export the resulting .stl.
I decided to make my chocolate in the shape of the Doors of Durin, the entrance to the Mines of Moria in Lord of the Rings .
After converting my image to a .stl, Mr. Gerber helped me mill the mold out of wax using CNC milling. From there, we mixed
parts A and B of Smooth-Sil 960 to create our silicone negative. To prevent any bubbles messing up our design, we used a vaccum
to degas the silicone mixture. Then, we carefully poured it into our wax mold and allowed it to set for 24 hours. Finally - and
this is the fun part - we melted chocolate, poured it into our silicone molds, let it sit in the fridge for awhile to set, and
then ate it.
I am very satisfied with my mold and chocolate. I think it turned out very nicely, and it gave me yet another chance to do
something both very cool and very nerdy. Also, the chocolate was delicious!


A FAR OFF PLACE A film review by James Berardinelli Copyright 1993 James Berardinelli
Date Released: 3/12/93 Running Length: 1:47 Rated: PG (Mature themes)
Starring: Reese Witherspoon, Ethan Randall, Jack Thompson, Sarel Bok, Maximilian Schell Director: Mikael Salomon Producers: Eva Monley and Elaine Sperber Screenplay: Robert Caswell, Jonathan Hensleigh, and Sally Robinson Music: James Horner Released by Walt Disney Pictures in association with Amblin Entertainment
Nonnie Parker (Reese Witherspoon) is a 14-year-old girl living on a farm in Africa. Harry Winslow (Ethan Randall) is a 16-year-old boy visiting with his father from America. The two get thrown together when elephant-tusk poachers murder Nonnie's parents and Harry's father in an attempt to cover their tracks. With the help of a teenage bush man named Xhabbo (Sarel Bok), Nonnie and Harry attempt a crossing of the Kalahari desert to escape the poachers.
A FAR OFF PLACE is undoubtedly designed as a "family film" (hence the PG rating), but parents should be warned. Some of the scenes of animal death may be quite disturbing to younger children. Despite Disney's disclaimer that no animals were injured during the filming of the picture (the dead elephants are actually meticulously-constructed life-size replicas), this is unlikely to make more of a difference to the little ones in the audience than the knowledge that Bambi's mother was only a cartoon deer.
The basic plot is relatively simple, although there are moments when certain elements of it becomes needlessly (albeit briefly) convoluted. The best part of A FAR OFF PLACE is, predictably, its centerpiece--the trek across the Kalahari. On this journey, the three principle characters learn a lot about life and each other. The revelations border on trite, but they're at least presented in an enjoyable fashion.
Reese Witherspoon (last seen as the charming younger sister in THE MAN IN THE MOON) shows a lot of ability and presence in her role as Nonnie. Her character is not especially well-written, but she gets a lot out of it. Sarel Bok is equally good. Unfortunately, the same cannot be said of Ethan Randall. Randall's Harry is an often-obnoxious whiner, and the actor seems to have trouble finding much that is noble in Harry's character. Randall is outclassed by Witherspoon and Bok in almost every scene. They are pleasures to watch; he is not.
As a family feature, A FAR OFF PLACE does a pretty good job. It puts together all the right formulas in a frequently-engaging fashion. The villains are predictably evil and the heroes unabashedly good, but the main struggle is less of a morality play than man against nature. The cinematography (by Juan Ruiz-Anchia) is impressive, especially coupled with James Horner's fine score. A FAR OFF PLACE, while clearly not a milestone of film, is a predictable-but-satisfying movie adventure.
 The nine-minute short is rather average cartoon fare until the clever ending. I found it neither exceptionally funny nor dull. Children will love it; adults, if not as fond of it as their offspring, should at least be able to tolerate it. "Trail Mix-Up" has the subtlety--and plot--of a Roadrunner and Wiley Coyote cartoon, although it certainly isn't as clever as the latter. While not worth a trip to the theater on its own merits, "Trail Mix-Up" is a painless diversion, and an okay appetizer for the much longer A FAR OFF PLACE.
Rating: 8.2 (B+, ***)
- James Berardinelli<EMAIL_ADDRESS>.
The review above was posted to the
rec.arts.movies.reviews newsgroup (de.rec.film.kritiken for German reviews).
The Internet Movie Database accepts no responsibility for the contents of the
review and has no editorial control. Unless stated otherwise, the copyright
belongs to the author.
Please direct comments/criticisms of the review to relevant newsgroups.
Broken URLs inthe reviews are the responsibility of the author.
The formatting of the review is likely to differ from the original due
to ASCII to HTML conversion.
Related links: index of all rec.arts.movies.reviews reviews


This is the header
This is a part for large contents as caroussels, adverts, etc.
This is the main content of the page
This is a part for large contents as adverts, caroussels, etc.