Introduction
Routing in a web application is about managing state. Modern single-page web applications make use of the HTML5 history API in order to retain normal browser navigation while not forcing a complete refresh of the page on every state/url change. Footwork includes a router which provides this functionality.
The router included with Footwork has a several key features:
- Unlimited nesting of routers (relative and non-relative).
- Unlimited number of named-based view outlets per router.
- Context based sub-routing.
- Context based outlets.
- Parameterized routes (with optional or required parameters).
- Filtered/predicated routes.
- Animated page loads.
- Integration with history.js for cross-browser history API as well as hash-based routing support.
In essence the router combines several design patterns (MVC + MVVM + Observable), context-based subrouting, and context-based outlets to provide a novel and extremely powerful routing solution.
Routers have four principle components which make them useful:
- configuration object: A router configuration used to generate the constructor function. It defines the router, its routes, controllers, and their actions.
- <router> declaration: A <router> declaration tells Footwork what portion of the DOM a router is responsible for.
- outlets: Any number of <outlet></outlet> declarations in your HTML which are the output points your router controls.
- route bindings: Special bindings for links (and other tags) which will initiate new states in your router.
Just like a viewModel or dataModel, a router can be bound against your UI/markup (either on its own or integrated into a <component>).
A router is really just an enhanced viewModel, meaning you can use it in exactly the same way you would a viewModel, but with the added ability of being able to have it manage its inner/nested routing and state.
Usage
A router can be instantiated and used in 3 different ways:
-
Manually initialized (standard KnockoutJS methodology), and optionally bound to the DOM (See: manual binding).
markup.html

     <outlet name="mainArea"></outlet>

markup.jsvar Router = fw.router.create({ initialize: function() { this.hello = 'world'; }, routes: [ /* ... */ ] }); fw.applyBindings(new Router(), document.getElementById('main-router'));
-
Automatically via a <router module="moduleName"> ... </router> declaration in the DOM (See: <router> usage).
markup.html<router module="MainRouter">

     <outlet name="mainArea"></outlet> </router>
markup.jsfw.router.create({ namespace: 'MainRouter', autoRegister: true, initialize: function() { this.user = 'Frank'; }, routes: [ /* ... */ ] }); fw.start();
- Automatically via a <component-name></component-name> declaration in the DOM (See: <component> usage).
NOTE: There are many ways to register and/or load a router so it can be found/used when needed. See: router registration.
Factory Method
A router instance is created using the constructor function made for it.
router constructor functions are created by calling the factory method fw.router.create() and passing it a configuration object.
The resulting constructor function can then be used to instantiate new instances of that router. These constructor functions are essentially specialized wrappers which enable Footwork to hook into both knockout and your router/module to provide for all of the additional features the framework provides.
var RouterConstructor = fw.router.create({
// by default the namespace is based off of the viewModel it is paired with
namespace: 'namespaceName', // (this is not usually needed)
/**
* If true, Footwork will register the router under its namespace name. This means
* that when this fw.router.create() call is made it will automatically call
* fw.router.register('RouterName', ThisRouterConstructor)
* This is one (handy) way of telling Footwork how to find your router when it needs it.
*/
autoRegister: false, // default === false
/**
* If true, the namespace will have an auto-incremented 0-based index number appended for
* each new router (ie: new instances will not share the same namespace).
*/
autoIncrement: false, // default === false
// routes list definition (See: Routes List)
routes: [
{ route: '/', controller: function() {} },
// ...
],
// unknown route (triggered if none of the routes[] match from above)
unknownRoute: {},
/**
* Sometimes you want to show something while an outlet loads. This is the property
* that defines which component to show while the chosen one downloads.
* Note: You will typically only want to use an explicitly registered component/view for
* this otherwise it will need to be downloaded first as well.
*/
showDuringLoad: 'component-name',
showDuringLoad: function(outletName, componentToShow) {
// callback which can be used to determine what to temporarily show based on the
// outletName and componentToShow. This is called each time an outlet is changed.
return 'component-name';
},
/**
* Specify the minimum transition time between outlet changes (ie: show the
* showDuringLoad component for a minimum specified amount of time). Using this helps
* reduce UI thrashing and provides a more friendly user experience.
*/
minTransitionPeriod: 300, // 300msec (default is 0msec)
minTransitionPeriod: function(outletName, componentToShow) {
// callback which can be used to determine the minimum time based on the outletName
// and componentToShow. This is called each time an outlet is changed.
return 300; // 300msec
},
/**
* Initialization function called at creation of a new router.
* Note: it is passed in the parameters supplied at creation.
*/
initialize: function(param1, param2, param3, ...) {
// this === the router instance
var router = this;
// You can create observables to bind against just like a viewModel/dataModel
router.param1 = fw.observable(param1);
},
// Called after initialize() and after binding to the DOM
afterRender: function(containingElement) {
// this === the router instance
},
/**
* Called after afterRender() and after all nested components/viewModels/etc have been resolved.
*
* This enables you to control when the module is 'resolved', such as when you need to
* load some data before displaying to the user. Parent components/etc will not resolve until
* their children do. If you are using animations they will not trigger on a component until it
* is resolved.
*/
afterResolving: function(resolve) {
// If this method is defined you will have to call the passed in resolve() callback once
// your router is 'resolved'.
// You can pass it a truthy value to indicate resolution is complete:
resolve(true);
// You can pass it a promise, footwork will wait for it to be resolved or fail:
resolve(promiseToWaitFor);
// You can pass it an array of promises for footwork to wait to be resolved or fail:
resolve([ promiseToWaitFor, anotherPromiseToWaitFor ]);
// Note that if you call resolve(false) nothing will occur, footwork will not tell
// higher-level viewModel/dataModel/etc that your module is resolved until you call
// resolve(true) or hand it a promise that resolves/fails.
},
// Function called just before the html this router is bound to is removed from the DOM
onDispose: function(containingElement) {
// this === the router instance
},
// When used in a component, ensure that (if being animated) they are sequenced in with a
// minimum time between animations.
sequenceAnimations: 100, // 100ms minimum
sequenceAnimations: function() { return 100; }, // 100ms minimum
// if true all routes defined for the router will be relative to its parent router (if any)
isRelative: true, // default is true
// if true the router will activate as soon as it is bound to the DOM
activate: true, // default is true
// tell the router to exclude the beginning portion of a route
baseRoute: '', // default is null
/**
* Attributes/properties that are extended onto each newly instantiated router
* NOTE: Only suitable for primitive values (strings, numbers, etc) or functions, do not
* put observables or namespaces/etc here as they are shared across instances.
*/
extend: {
prop1: 'value',
prop2: 123
},
// Behavioral mixins to include with each new router created
mixins: [
// See: 'Mixins' section on this page
]
});
NOTE: All configuration parameters are optional.
Manual Instantiation and Binding
Manually instantiating a router is done by calling new ConstructorFunc(). With the instance in hand you can then use it as you wish, either directly or by binding it to the DOM.
To manually bind a router you use a fw.applyBindings() call after instantiating it.
var AppRouter = fw.router.create({
namespace: 'AppRouter',
// ...
});
var router = new AppRouter();
Now we can bind the AppRouter instance (router) to the DOM:
fw.applyBindings(router, document.getElementById('app-container'));
<router>
A router can be instantiated and bound automatically when using a <router> declarative wrapper element. Using the module="" attribute you can specify which router should be instantiated and bound by Footwork.
<router module="AppRouter">
Router Current Path:
<outlet name="MainArea"></outlet>
</router>
... and as an example, this router was registered directly:
fw.router.register('AppRouter', fw.router.create({
namespace: 'AppRouter',
routes: [ /* ... */ ]
})
);
NOTE: You can have your router automatically downloaded for you when needed.
See router registration for information on how to tell Footwork where to find your router module.
<component>
In addition to using a router in the ways shown above they can also be used inside of a custom <component>.
For more information on how to create a router-based component see the component documentation.
Routing
The following sections describe how to define routes as well as bind and route to different addresses in your application.
The enables you to set and trigger different states within your application based on the browser address/URL.
Routes and Controllers
In order for the router to do its job it must have a list of routes to work with.
The following sections describe how to define various routes and their respective controller methods that get called upon.
Routes List
When a new state/url is requested each router will iteratively search its routes: [] list from the top down for the first matching route. If more than one route matches for a given url/state then only the first one found found will be used.
Example routes: [] list definition:
// ...
routes: [
{ // default route: '/'
route: '/',
// ...
},
{ // route: /store
route: '/store',
// ...
}
],
unknownRoute: { /* ... */ }
// ...
You may also configure routes at any time using the provided helper methods:
fw.router.create({
namespace: 'MainRouter',
initialize: function() {
this.addRoutes([
{
title: 'Index Page',
route: '/',
controller: function() { /* ... */ }
},
{
title: 'Book Page',
route: '/book/:isbn',
controller: function(isbn) { /* ... */ }
}
]);
}
});
fw.router.create({
namespace: 'MainRouter',
initialize: function() {
this.setRoutes([
{
title: 'Index Page',
route: '/',
controller: function() { /* ... */ }
},
{
title: 'Book Page',
route: '/book/:isbn',
controller: function(isbn) { /* ... */ }
}
]);
}
});
Route Definition
A route definition is simply an object which describes a route. Footwork will match the browser path up against the route: parameter and use the other options to trigger and setup the state of your application.
A route definition has four possible parameters:
- route: - A specially structured string (or array of strings) which is used to match against a given URL (and optionally provide for named parameters).
- name: - A string value which can be used to route with.
- controller: - Callback function used when a route is chosen, this is where an outlet gets changed and the state of your application is altered. Any parameters defined by the route: will be passed in as individual arguments.
- title: - (optional) A string or callback function used to set the title of the page when the route is chosen. Any parameters defined by the route: will be passed in.
- filter: - (optional) A predicate function used to tell Footwork if it should consider a route. Any parameters defined by the route: will be passed in.
routes: [
// static routes (no parameters): /about-us and /about go to the same controller
{
route: [ '/about-us', '/about' ],
name: 'about', // optional/alternative name for this route
controller: function() { /* ... */ }
},
// route with optional parameter storeNum
{
route: '/info(/:storeNum)',
controller: function(storeNum) { /* ... */ }
},
// only routed to when isbn === '12345'
{
route: '/book/:isbn',
title: 'Special Book Page',
controller: function(isbn) {
console.log('Special Book ISBN', isbn);
},
filter: function(isbn) {
if(isbn === '12345') {
return true; // this route used only if isbn === '12345'
}
return false;
}
},
// normal book/:isbn route that is used when isbn !== '12345'
{
route: '/book/:isbn',
name: 'book', // optional/alternative name for this route
title: 'Home Page',
controller: function(isbn) {
console.log('Book ISBN', isbn);
}
}
]
Sometimes you might need to check and see if a 'string' matches a route. An example use case for this would be when integrating some sort of authentication system. You might want to block a route from being accessed when a user is not logged in. Footwork includes a method on an instantiated router called matchesRoute().
var Router = fw.router.create({
initialize: function() {
this.userIsLoggedIn = fw.observable().receiveFrom('auth', 'userIsLoggedIn');
},
beforeRoute: function(url) {
if(this.matchesRoute('profile', url) && !this.userIsLoggedIn()) {
return false;
}
return true;
},
routes: [
{
name: 'home',
route: '/',
controller: function() {
// ...
}
},
{
name: 'profile',
route: '/profile/:username',
controller: function(username) {
// ...
}
}
]
});
Outlets
Outlets are simply areas in your application where you can control what is displayed. Their placement in your application is designated by one or more <outlet name=""></outlet> declarations in your HTML. The name="" key is used by the router to target that specific outlet.

<router module="MainRouter">

<outlet name="main-view"></outlet>

</router>

When you tell an outlet what to show, you are actually telling it to load a component. Thus for each 'page' or view you want to display for an outlet, Footwork will need one of the three following things:
- A corresponding view registered (cached/preloaded) via fw.outlet.registerView() or fw.components.register()
- A registered location where it can load the view via fw.outlet.registerViewLocation() or fw.components.registerLocation()
- A component/view available at the default component location (fw.components.defaultLocation()).
NOTE: You can tell an <outlet></outlet> to show any component, not just ones you register with fw.outlet.registerView() or fw.outlet.registerViewLocation(). Those methods are simply provided as a shortcut for creating a component and marking it as 'template-only'.
Also remember that components can contain any depth and complexity of nested viewModels, components, routers, etc. This means you can even nest entire applications within the view of another, all with simple declarative syntax.
Registering Views
Because most things you might want to show in an outlet (pages/views) consist of only template/html code (they have no corresponding viewModel), Footwork provides two shortcut methods for registering a template-only outlet view (ie: a page/view/template you can show in an <outlet></outlet>).
- fw.outlet.registerView() - Cache a view/template for later use (available instantly, no download time).
- fw.outlet.registerViewLocation() - Tell Footwork where it can download it via AMD/RequireJS (dynamically/lazy loaded for you when requested). Since outlet views are just viewModel-less components, they are resolved just like any other AMD/RequireJS loaded component.
Essentially they are ways to easily create/register a view you can use in an outlet.
// Register the 'index-page' template view
fw.outlet.registerView('index-page', '
Welcome to Footwork.js
');
// Register a different view that has a nested component
fw.outlet.registerView('calendar-page', 'Calendar: <calendar></calendar>');
NOTE: It is generally recommended you load your templates via a module system such as RequireJS (don't just write them inline in a string as shown, that was only used as an example for reasons of brevity).
namespaceFor an example of how to do this check the tutorials page, or alternatively just specify the location of the view via fw.outlet.registerViewLocation().
// Register location of the 'index-page' template view
fw.outlet.registerViewLocation('index-page', '/pages/index-page.html');
/**
* Footwork will append the filename if you end it with a trailing slash (/)
* The following will try to load '/otherPages/calendar-page.html' when needed
*/
fw.outlet.registerViewLocation('calendar-page', '/otherPages/');
// Register location for multiple views (the same filename appending occurs):
fw.outlet.registerViewLocation(['calendar-page', 'about-page'], '/otherPages/');
<outlet>
Once Footwork knows how to resolve your outlet view it can be used in your application. From that point you need only place whatever <outlet name=""></outlet> declarations you want in the HTML and then change/set them via the router.outlet() method.
fw.router.create({
namespace: 'MainRouter',
routes: [
{
route: '/',
controller: function() {
// route changed to '/', make the 'main-view' outlet show the 'index-page' view
this.outlet('main-view', 'index-page');
}
}, {
route: '/about',
controller: function() {
// route changed to '/about', make the 'main-view' outlet show the 'about-page' view
this.outlet('main-view', 'about-page', function(element) {
// callback triggered after about-page is loaded
console.log('About page is loaded inside of', element);
});
}
}, {
route: '/dashboard',
controller: function() {
/**
* route changed to '/dashboard', make the 'main-view' outlet show the
* 'dashboard' component while passing in the accountId to its viewModel as well as
* callbacks for onComplete and onFailure lifecycle events
*/
this.outlet('main-view', 'dashboard', {
params: {
accountId: 234
},
onComplete: function(element) { /* ... */ },
onFailure: function(element) { /* ... */ }
});
}
}
]
});
fw.router.create({
namespace: 'MainRouter',
afterRender: function() {
console.log('Registered outlets', this.$router.outlets);
}
});
Changing the Route
Changing the route of your router can occur via a few differing methods. It can be triggered either explicitly or via some external means such as a $route binding on the DOM.
The following sections explain how to trigger route changes in your application.
Setting State Explicitly
There are two ways to set the state explicitly on a router.
The first involves simply calling setState() on the router instance itself.
fw.router.create({
namespace: 'MainRouter',
routes: [
{
name: 'book',
title: 'Book Page',
route: '/book/:isbn',
controller: function(isbn) { /* ... */ }
}
],
initialize: function() {
var router = this;
this.$namespace.command.handler('goHome', function() {
// We received the 'goHome' command, lets go to the default ('/') home route
router.setState('/');
});
this.$namespace.command.handler('gotoBook', function(bookNum) {
// We received the 'goHome' command, lets go to the named 'book' route and pass it the bookNum
router.setState('book', '/book/' + bookNum);
});
this.$namespace.command.handler('gotoMyBook', function() {
// We received the 'gotoMyBook' command, lets go to the named 'book' route and pass it the id of our book
router.setState('book', { id: 123 });
});
}
});
For the second, Footwork also sets up a default command handler (setState) that you can use/call in case you just want to tell the router to set its state to a certain value from another area in your application.
fw.router.create({
namespace: 'MainRouter',
routes: [ /* ... */ ]
});
// ...
var mainRouter = fw.namespace('MainRouter');
// Send the router to the default '/' route
mainRouter.command('setState', '/');
// Send the router to the named route 'book' with the id passed in
mainRouter.command('setState', {
name: 'book',
params: {
id: 123
}
});
$route Binding
In order to make your links and other elements work with the router, Footwork needs to know about them. This is done with the $route binding.
The $route binding is simply a custom knockout binding which is created by Footwork. This binding allows Footwork to correctly connect your DOM element event (click, by default) to a router action.
Whenever Footwork encounters the $route binding it will traverse up the DOM node path searching for the nearest parent router. Whenever the designated event occurs on that element it will trigger the state change as described on that router.
A common use for the $route binding is with no options (as the first example below shows), and in this mode of operation it will bind to the click event and (if it is an anchor tag) look at the element href="" attribute for the destination URL. All of this (and more) can be overridden with the following optional parameters:
- url: 'string' / callback() / observable The route to send the application to (uses href="" attribute when not supplied).
- on: 'string' / callback() / observable The event to trigger the action on ('click', by default).
- handler: function(event, url) Callback handler for the event.
- addActiveClass: boolean / callback() / observable Flag indicating whether or not the 'active' class should be added to the element.
- activeClass: 'string' / callback() / observable The class name to add to the element when the route is active (default is 'active').
- parentHasState: '.selector' / boolean If supplied, the parent will have the activeClass managed on a parent of the bound element (true selects the immediate parent).

About Page
About Page

About Page

About Page

About Page

About Page

About Page

About Page

// viewModel showing the example handler from above
var MainViewModel = fw.viewModel.create({
initialize: function() {
this.clickHandler = function(event, url) {
console.log('Route Destination:', url);
// must prevent the default action on an  tag (otherwise it will reload the page)
event.preventDefault();
// tell Footwork to route to the url (false === do not route)
return true;
}
}
});
Getting the State
Sometimes you might want to retrieve or read the current state of the router.
There are two principle ways to retrieve the current state of a router. The most direct method is via reading the currentRoute observable directly from the instance.
// Instantiate the router, activate it and set the state
var router = new MyRouter();
router.activate().setState('/book/1234');
// Grab the currentRoute directly from the instance
var currentRoute = router.currentRoute();
console.info(currentRoute.url); // === '/book/1234'
If you need to retrieve the currentRoute from another part of your application (outside of the router then you will want to REQUEST it using the namespace of your router. Footwork sets up a REQUEST handler by default for 'currentRoute' which returns the current route details.
var MyRouter = fw.router.create({
namespace: 'MyRouter', // note we will use this namespace to REQUEST the currentRoute
// ...
});
// Instantiate the router, activate it and set the state
var router = new MyRouter();
router.activate().setState('/book/1234');
// Create the namespace channel we will use to request the currentRoute
var MyRouterNS = fw.namespace('MyRouter');
// Request the currentRoute
var currentRoute = MyRouterNS.request('currentRoute');
console.info(currentRoute.url); // === '/book/1234'
Animating Views
Often times it is desirable to animate the loading of a new view inside an <outlet>. FootworkJS builds animation capability into every <component> and <outlet>.
To use the built in animation capability you first need to include the companion CSS which has the relevant animation code in it.

<link rel="stylesheet" href="bower_components/footwork/dist/animation/animation.css">

<router module="MainRouter">

<outlet name="mainArea"></outlet>
</router>

After you have the animation.css asset being loaded you will need to add one of the available animation classes to the top-level container elements inside of your views/components that you are loading inside of an <outlet>.
Lets say that we are loading a view into the mainArea <outlet> above, the template HTML could contain something like this:

All of the content inside of this view will fade-in!

All of the content inside of this view will fade-in-from-top!

Currently available animations by default:
- fade-in
- fade-in-from-top
- fade-in-from-bottom
- fade-in-from-left
- fade-in-from-right
Displaying something temporarily while the outlet is loading...
Using the previous animation classes we can make the inner rendered components animate into place once they are loaded/resolved. You probably also want to display something to the user while the outlet is loading as well. To do this you specify the showDuringLoad option in the router configuration.
The showDuringLoad option is used to tell Footwork what component to display while the outlet is being resolved.
A typical use of this feature is to show a loading spinner to the user while the outlet is loading its contents.
Lifecycle & Registration
Each router instantiated and bound to the DOM will receive lifecycle events.
These events can be used for any logic you need to incorporate when the instance is initially setup/bound onto or removed from the page. A common example would be the setup and teardown of a jQuery plugin, or events.
Registration of a router is referring to telling Footwork (in one way or another) where your router is so that it can be used when needed.
Lifecycle
A router lifecycle follows exactly the same pattern as a viewModel but with one crucial exception. A router will not trigger any of its routes (and thus, controllers) until it is activated.
This activation can occur under 3 different circumstances.
- Automatically when you bind it to the DOM.
- Explicitly by calling router.activate() directly on the instance.
- Explicitly by issuing the 'activate' COMMAND via its namespace.
A router is first instantiated (either automatically via a declarative <router> in your markup or explicitly), then bound to the DOM and used, or just used independent of the DOM. Depending on what you choose to do with a router determines its exact lifecycle.
Lifecycle events are automatically triggered for you when using a router via one of the three main methods:
- Use the <router> ... </router> declarative syntax.
- Use the <component-name></component-name> declarative syntax.
- Manually bound (fw.applyBindings()) to the DOM.
A router that is attached to the DOM will retrive two main lifecycle events, one just after binding to the DOM (afterRender()) and one when the element (that the router bound itself to) is removed from the DOM (onDispose(), called just before the element is removed).
Activation
A router is first instantiated and then activated. No routing will occur (the controller methods will not be activated/called) until a router is activated.
This activation can occur under 3 different circumstances.
- Automatically when you bind it to the DOM (declarative <router> in your markup).
- Explicitly by calling router.activate() directly on the instance.
- Explicitly by issuing the 'activate' COMMAND via its namespace.
Explicit activation via calling of router.activate() directly on the instance:
// Configure the router with a single route
var MainRouter = fw.router.create({
routes: [
{
title: 'Home Page',
route: '/home',
controller: function() {
console.info('Went to home page');
}
}
]
});
// Instantiate an instance of the router
var router = new MainRouter();
// Activate the router without binding it to the DOM
router.activate();
// Set the state/route to a specific value
router.setState('/home');
// Console prints 'Went to home page'
Explicitly by issuing the 'activate' COMMAND via its namespace:
fw.router.create({
namespace: 'MainRouter',
routes: [ /* ... */ ]
});
// ...
var mainRouter = fw.namespace('MainRouter');
// activate the router
mainRouter.command('activate');
Binding
If provided, the router configuration afterRender() method will be called just after a router is bound to the DOM. This provides a handy integration point for external libraries or plugins (such as jQuery).
var MainRouter = fw.router.create({
namespace: 'MainRouter',
routes: [ /* ... */ ],
afterRender: function(domElement) {
domElement.addEventListener('click', function() {
console.info('You clicked the router');
});
}
});
Disposal
If provided, the router configuration onDispose() method will be called just after the element a router is bound to is removed from the DOM. This provides a handy integration point for external libraries or plugins (such as jQuery).
var MainRouter = fw.router.create({
namespace: 'MainRouter',
initialize: function(params) {
this.clickRouter = function() {
console.info('You clicked the router');
};
},
afterRender: function(domElement) {
domElement.addEventListener('click', this.clickRouter);
},
onDispose: function(domElement) {
domElement.removeEventListener('click', this.clickRouter);
}
});
If you do not bind a router to the DOM then you will want to tell it to clean up its references when you are getting rid of it. This is done by calling router.dispose() directly.
var MyRouter = fw.router.create({ /* ... */ });
var router = new MyRouter();
// ...
router.dispose(); // all namespaces, handlers, and subscriptions now cleaned up/removed
var someOtherObservable = fw.observable();
var MyRouter = fw.router.create({
routes: [ /* ... */ ],
initialize: function() {
// Make router the instance reference
var router = this;
router.myVarSub = someOtherObservable.subscribe(function() {
// This subscription will get cleaned up when the router is disposed
});
router.$namespace.command.handler('doSomething', function() {
// This command handler will get cleaned up when the router is disposed
});
router.$someOtherNamespace = fw.namespace('SomeOtherNamespace');
router.$someOtherNamespace.command.handler('doSomethingElse', function() {
// This command handler will get cleaned up when the router is disposed
});
}
});
Registration
In order for Footwork to know what to do when it encounters a <router> declaration it must be registered in some way (it needs to know where it is).
Footwork supports both explicitly registering your router ahead of time (caching its constructor function or instance directly) or by telling it where it can be downloaded (automatically/lazy loading via AMD/RequireJS).
You can register your module with one of the following methods:
- fw.router.register() - Register (cache) a router explicitly.
- fw.router.registerLocation() - Register the location of a router so that it can be dynamically loaded at some time in the future.
In either case, the declarative <router module="moduleName"> ... </router> syntax will trigger the loading (if necessary), instantiation, and binding of the router.
NOTE: AMD/RequireJS is fully supported (and highly encouraged) for a number of reasons:
- It strongly encourages modularization and separation of concerns.
- Helps decouple your application and allow for easier testability.
- Footwork can take advantage of its dependency resolution to automatically load and use resources for you as needed at runtime (including the automatic loading and composing of entire (including nested) views/pages, routers, components, viewModels, or dataModels).
- Allows for easier debugging as non-compiled assets while still being buildable for release into a production environment.
- Allows for easy and highly configurable caching/preloading of assets (this includes all components, routers, and templates). None, some, or all of it...you choose what your users wait for.
Module Resolution
There are 3 ways Footwork will try to resolve your router when it encounters the declarative <router module="moduleName"> ... </router> element you place in the DOM.
Here they are in order of priority:
- Explicitly registered with a fw.router.register() call.
- Automatic download/resolution via AMD/RequireJS at a pre-registered location (fw.router.registerLocation()).
- Automatic download/resolution via AMD/RequireJS at the configurable default (fw.router.defaultLocation()).
Registering a router explicitly with fw.router.register() makes it immediately available. Any <router module="moduleName"> ... </router> declarations encountered will be processed with no delay (the router is 'cached' when registered).
The 2 methods registerLocation() and defaultLocation() tell Footwork where it can download your router module (in the event you do not explicitly register it). In any case your markup will wait until the router is resolved prior to being initialized.
// register a Footwork router
fw.router.register('MainRouter', fw.router.create({ /* ... */ }));
NOTE: Are you using a fw.router.create() constructor and simply want to register it using the namespace name (recommended)?
You can optionally just set autoRegister: true in the router configuration object, then the fw.router.register call is taken care of for you when the router constructor is created.
See: router configuration.
// Load MainRouter from: /routers/MainRouter.js (based on router/module name, case sensitive)
fw.router.registerLocation('MainRouter', '/routers/');
// Load all *OtherRouters from /routers/
fw.router.registerLocation(/.*OtherRouters/, '/routers/');
// Load MainRouter from: /routers/DifferentFileName.js (specify full file name)
fw.router.registerLocation('MainRouter', '/routers/DifferentFileName.js');
// Load all routers from /myrouters/[module-name].js (case sensitive)
fw.router.defaultLocation('/myRouters/');
Module Formats
Loading your router in so that Footwork can use it is done via a script loader.
Both AMD/RequireJS and Browserify are supported. However RequireJS is preferred as it will enable Footwork to resolve your routers/etc (and their dependencies) automatically at runtime as needed.
The following example shows the RequireJS/AMD flavored version:
define(["footwork"],
function(fw) {
// return the constructor created by fw.router.create()
return fw.router.create({
namespace: 'MainRouter'
initialize: function() {
// ...
}
});
}
);
Mixins
Mixins are about reusing behavior, functionality, and code whenever possible. They allow you to write various behaviors/logic and then later on combine and compose them as you want at runtime.
The mixin functionality in Footwork is provided via a library called riveter. All fw.router.create() based constructor functions are riveter constructor functions. Above and beyond the functionality outlined here, each object has various methods extended from riveter which can enable you to extend routers in various ways, it is recommended you to also look at its documentation.
Basic usage:
var mainRouterBehavior = { /* mixin configuration object */ };
var optRouterBehavior = { /* mixin configuration object, detailed in the next section */ };
/**
* Mixin behavior is applied to a router by passing it into the
* fw.router.create() configuration object
* NOTE: mixins are applied to the router in the order they are given.
*/
var MainRouter = fw.router.create({
namespace: 'MainRouter',
routes: [ /* ... */ ],
// mixins/behavior to include for each new 'Sprocket' router
mixins: [ mainRouterBehavior, optRouterBehavior ]
});
var myRouter = new MainRouter();
Configuration
Each mixin is simply a configuration object defining certain behaviors, functionality, and logic. The behavior you define will be added to each router instance it is configured with.
Mixin configuration object synopsis:
// define 'mainRouterBehavior' as an object to serve as the configuration container
var mainRouterBehavior = {
_preInit: function(param1, param2, ...) {
/**
* called prior to the initialize() method from the router configuration being called
* params === params passed in at creation
* this === the router
*/
},
mixin: {
/**
* these properties are added the instance object immediately upon creation, before
* any methods (including _preInit) are called
*/
function1: function() {
// function that is extended onto the router object (this) upon creation
},
function2: function() {
// another function that is extended onto the router object (this) upon creation
},
property1: 'someValue' // a raw property extended to the object
// ...
},
_postInit: function() {
/**
* called after the initialize() method from the router configuration is called
* this === the router instance
*/
}
};
- If you require some other type of object extension or mixin, as recommended above you should look at the riveter documentation.
- A router can have as many mixins as you want, and you can re-use them across as many differing routers/modules as you like.
Example mixin usage
Each mixin behavior is added to each new instance of the router that is created. This goes for ones instantiated automatically via declarative HTML, or directly/manually in javascript code.
All mixins may be reused on both a standalone router and routers attributed with a component.
Example usage:
// define the mixin configuration object
var routerBehavior = {
_preInit: function(param) {
this.isAwesome = (param.type === 'awesome' ? true : false);
}
};
// create a MainRouter contructor and include the routerBehavior mixin
var MainRouter = fw.router.create({
namespace: 'MainRouter',
routes: [ /* ... */ ],
mixins: [ routerBehavior ]
});
var router = new MainRouter();
// router.isAwesome === false
Utility Functions
Various useful methods and utility functions for miscellaneous and debugging purposes.
var routers = fw.router.getAll(); // get all instantiated routers
fw.router.register('MainRouter', fw.router.create({
namespace: 'MainRouter'
}));
// fw.router.isRegistered('MainRouter') === true
// fw.router.isRegistered('ModuleThatIsLoadedByAMD') === false
// Explicit registration
fw.router.register('MainRouter', fw.router.create({ /* ... configuration object */ }));
// router that registers itself
var MainRouter = fw.router.create({
namespace: 'MainRouter',
autoRegister: true,
// ...
});
// fw.router.getRegistered('MainRouter') === MainRouter;
fw.router.registerLocation('MainRouter', '/path/to/router/folder');
// fw.router.getLocation('MainRouter') === '/path/to/router/folder'
var fileNameForSprocket = fw.router.getFileName('MainRouter'); // === MainRouter.js
// explicitly set the extension
fw.router.fileExtensions('.jscript'); // append router module files with '.jscript'
// You can also specify a function() whose return value is used as the extension.
fw.router.fileExtensions(function(moduleName) {
if(moduleName === 'SubRouter') {
return '.jscript';
} else {
return '.js';
}
});
// fw.router.baseRoute() === ''
fw.router.baseRoute('/home/directory'); // routers will ignore '/home/directory' at beginning of url
// fw.router.activeRouteClassName() === 'active' // default === 'active'
// active routes will now have 'currentlyActive' added to their className
fw.router.activeRouteClassName('currentlyActive');
// fw.router.disableHistory() === false (default)
fw.router.disableHistory(true); // history now disabled, but app still navigable
// fw.router.html5History() === true (when using chrome)
fw.router.html5History(); // === false when using <=IE8
Instance Properties
After a router has been created, there are a few properties which are on the instantiated object.
The namespace channel created as a result of the namespace: configuration attribute given.
This should be used to setup any handlers and subscriptions on the current namespace that a router might need.
var MainPage = fw.router.create({
namespace: 'MainPage',
initialize: function() {
this.$namespace.event.handler('userLoggedIn', function(username) {
console.log('Welcome', username);
});
}
});
The root (non-indexed) namespace channel created as a result of the namespace: configuration attribute given.
If you provide the option autoIncrement: true then each new router instance will have an indexed namespace name, the $rootNamespace is the namespace channel provided which hooks into the non-indexed (root) namespace name.
fw.router.create({
namespace: 'SubRouter',
autoIncrement: true,
initialize: function() {
this.$rootNamespace.event.handler('userLoggedOut', function(username) {
console.log('SubRouter, not SubRouter0 or SubRouter1, received the logout notice for:', username);
});
}
});
Global namespace channel all instances get access to. Think of this as a broadcast channel everyone can talk on.
fw.router.create({
namespace: 'SubRouters',
initialize: function() {
var thisRouter = this;
this.$globalNamespace.command.handler('sayHello', function() {
console.log('Hello from', thisRouter);
});
}
});
var MainRouter = fw.router.create({
namespace: 'MainRouter',
initialize: function() {
this.isLoggedIn = fw.observable();
this.disposeWithInstance(this.isLoggedIn.subscribe(function(isLoggedIn) {
console.info('isLoggedIn', isLoggedIn);
}));
}
});
var router = new MainRouter();
router.dispose(); // the subscriptions tracked using disposeWithInstance are now also disposed of with the instance


Or you can put your content in as HTML
A blank slide has little to no properties
All it's designed to be is an HTML passthrough


Cancun, Mexico - Ultra Inclusive Resort - Couples Only!
Inclusive Includes
- Breakfast Buffet
- Gourmet lunch
- Gourmet snacks
- 24. Hrs. Room Service
- Alcoholics drinks
- Mini bar at the your room
- Activities and entertainment
- Non-motorized water sports equip Breakfast
- Day beds and towel on the beach
- Fitness Center
- Kids Club
- All taxes and services


Demo objectives:
- Display a map on a web page using HTML, CSS, and JavaScript only.
- Add static data to the map.
- Add dynamic content to the map.
- Apply styling to the map elements (cartography).
- Add controls to the map.
- Add popups with custom content to the map.


Daily Lotto: Three winners on Thursday
Three lucky winners in Thursday's Daily Lotto walk away with R125 551.
In case you missed it, here are the winning Lotto and Lotto Plus numbers from the Wednesday, November 13 draw:
Get the full list of past Lotto and PowerBall draws here.


Hello Bulma!
Congratulations! You're running the
Bulma start
project customized by
KMuncie
.
It includes everything you need to
build your own website
with Bulma.
Starter Pack
Use these resources to get started with Bulma.
Bulma Documentation
Bulma Source Code


ESP8266 configuration
WiFi settings
{{SSID_OPTIONS}}
Warning!
After clicking 'Connect' you will be disconnected from ESP8266 configuration network.


--- layout: default-post ---
Jarek Paul Ervin is a music scholar and writer working at the intersection of
musicology, cultural studies, philosophy, and social theory. Broadly, Ervin’s
thought investigates the overlapping and often conflicting dynamics of music as
aesthetic practice, social force, historical inheritance, and a privileged window
into the domain of sensory experience. More generally, his research
concentrates on the areas of popular music studies; philosophy of music,
especially historical materialism, German Idealism, and critical theory (Lukács,
Benjamin, Bloch, and Adorno); and gender and sexuality in music.
Ervin is currently a PhD candidate in University of Virginia’s McIntire Department
of Music. His dissertation concentrates on the fraught character of New York’s
iconic punk scene during the 1970s. The project focuses on a range of important
early punk artists, from well-known artists such as Velvet Underground, the
Ramones, and Patti Smith, to less-recognized figures including Jayne County,
Mumps, and Tuff Darts. Drawing on a range of archival, critical, and recorded
materials, Ervin’s project explores the way the category of punk served as a
fragile placeholder for a diverse and polemical musical practice during its early
history. Ultimately, this leads to an interrogation of broader issues related to
genre theory, gender and sexual identity in rock, and popular music’s troubled
internal history.
Recent projects have also addressed the early history of popular music studies,
avant-garde musical aesthetics, and the recent resurgence of white supremacist
music. Ervin is also actively involved in digital and public platforms for music
scholarship. He has written for a number of online forums, and actively maintains
a blog. Ervin is currently the Assistant Web Editor of the International Association
for the Study of Popular Music’s U.S. Branch; follow IASPM-US’s twitter at
@IASPMUS.
Ervin’s published work appears with or is forthcoming in Popular Music, Popular
music and Society, and Jacobin. He has also presented at a number of recent
conferences including 2014’s Left Forum and IASPM-US 2016; this fall, he will
present at the joint meeting of AMS and SMT in Vancouver. Ervin has held
fellowships from the Library of Congress and UVa’s Vice President's Office for
Research, and in 2015 was the Gladys Krieble Delmas Visiting Scholar at the
Rock and Roll Hall of Fame’s Library and Archives. In 2016, his work will be
supported by a Battestin Fellowship from the Bibliographical Society of the
University of Virginia.
For more about his research and teaching, click here.
Ph.D. Candidate
McIntire Department of Music
University of Virginia
112 Old Cabell Hall
P.O. Box 400176
Charlottesville, VA 22904-4176
610-717-6051
<EMAIL_ADDRESS>EDUCATION
PUBLICATIONS
AWARDS, FELLOWSHIPS, AND HONORS
subscribe via RSS
Inside the Green Room.
Jacobin. June 14, 2016.
Punk Rock New York.
International Association for the Study of
Popular Music-US Website. March 10, 2016.
Networks of Sound, Style, and Subversion: The Punk and Post-Punk Worlds of Manchester, London, Liverpool, and Sheffield, 1975-80, by Nick Crossley. Popular Music 35:02 (May, 2016): 291-293.
{% if page.author %} • {{ page.author }}{% endif %}


To start recording your own voice or any sound, press the "Push to speak" button. When enough voice audio is recorded, press the "Stop" button.
When the recording stops, you can give us feedback about whether guessed the sound of the language correctly. Simple answers "Yes" and "No" are usually good enough. It would be grate if you can provide correct sound or language label when we get it wrong.
Just type in some letters from the label and choose the correct label from the options that have appeared.


Container{{ container }}
{% if trash_enabled %}
{% endif %}
{% if backup_obj %}
{% endif %}
{% trans 'Trash' %}
{% trans 'There is already an object with this name in the container, we suggest a new name. If you need to edit, click on the new name and then click restore.' %}
{% trans 'Name' %}
{% trans 'Size' %}
Restaurar
{% if backup_obj %}
{% trans 'Backup' %}
{% trans 'Restore Backup' %}:
{% trans 'The backup will be restored to a container with the following name' %}:
[container]_[backup_type]_[timestamp]
{% trans 'The backup service for this container was requested on' %} {{ backup_obj.created_at }}
{% trans 'If you want to restore a backup, please contact Vault administrator' %}


Florida man arrested for punching little league umpire in the face
by Tamar LapinHe went bats–t crazy.
A Florida man was arrested on Friday for allegedly slugging an umpire in the face at his nephew’s little league baseball game.
Alberto Ramos, 22, disagreed with one of the ump’s calls and confronted him after the game to complain, the Polk County Sheriff’s Office said in a press release.
Things escalated, with Ramos raising his voice and the umpire asking him to leave the ballpark, according to an arrest affidavit.
Instead of leaving, the hothead began raging, telling the ump that he would “kick his ass.”
He then punched the ump in the face, cutting the man’s lip and breaking one of his teeth, police said.
“This is completely inexcusable — assaulting a little league official while he’s officiating at a game where children are supposed to be having fun, and learning sportsmanlike behavior,” said Sheriff Grady Judd.
Ramos was charged with one count of felony battery of a sports official and released on a $1,000 bond.


Learn and compete at the same time!
Checkout the project repohere
See how the project workshere
Contact Andrew to Register!


If you hide the status bar, be sure to let people retrieve it (and the appropriate app UI) with a single tap. Unless you have a compelling reason to do so, avoaid defining a custom gesture to redisplay the status bar becasue users are unlikely to discover such a gesture or to remember it.


Port Legacy Apps
This topic provides general info on porting legacy apps to Legato.
There's also specific info available to Port Legacy C App.
Sandboxed App
High-level steps for porting your app to Legato:
- Build the app’s executables and libraries using the legacy program’s build system, but using the appropriate cross-build tool chain.
- Create an .adef file for your app.
- Leave the
executables:
section in.adef
empty (or omit that section entirely). - Include files to be installed as part of the app (executables, libraries, configuration files, devices, etc.) in the
files:
subsection of the bundles: section of the .adef file. - Use the extern: section of the .adef file to include files and directories that need to be imported into the sandbox from the target’s file system.
- Add run: lines in the
processes
: section in the .adef to define processes that should run in the app. - Run mkapp on the
.adef
file to create the app bundle (e.g., .wp85 file) to be installed on the target.
An app bundle produced like this can be installed exactly the same as any other Legato app bundle.
Detailed info:
Definition Files
Create Apps
Port Legacy C App
Here's a foo.adef
sample (for application foo) with executables bar1 and bar2 needing library lib1. The application name should be the same as the .adef file name:
To bundle everything into an app, run:
where [target] is something like "ar7" or "wp85".
The app bundle file can be installed using the instapp
tool.
- Note
- Other app settings (e.g.,
faultAction
) can also be set in the .adef files. See Application Definition .adef.
Porting Apps with Root Access
This method is necessary if your legacy apps require root privileges or access to system resources like /proc
. It means your app will be ported as a non-sandboxed Legato app.
In the .adef file, turn-off sandboxing:
- Note
- It can sometimes be easier to begin porting an application with sandboxing turned off and, when you have it working, turn sandboxing on and fix the resulting permissions issues by importing required files into your app using the .adef requires section.
Copyright (C) Sierra Wireless Inc. Use of this work is subject to license.


I am a full-stack web developer passionate about developing an innovative future, and easing the tasks of everyday life with the advances of modern technology.
I'm currently working with technologies such as NodeJS, Express, MongoDB, Ruby on Rails, HTML5, CSS3, Javascript, and Javascript libraries like React.
Before I started coding professionally, I ran and maintained a successful photography and graphic design entrepreneurship. This experience enabled me to get familiarized with Adobe Creative Suite to a second nature.
View Some of My Work


Tool for easy and efficient discretization of continuous and categorical data. The package calculates the most optimal binning of a given explanatory variable with respect to a user-specified target variable. The purpose is to assign a unique Weight-of-Evidence value to each of the calculated binpoints in order to recode the original variable. The package allows users to impose certain restrictions on the functional form on the resulting binning while maximizing the overall information value in the original data. The package is well suited for logistic scoring models where input variables may be subject to restrictions such as linearity by e.g. regulatory authorities. An excellent source describing in detail the development of scorecards, and the role of Weight-of-Evidence coding in credit scoring is (Siddiqi 2006, ISBN: 978–0-471–75451–0). The package utilizes the discrete nature of decision trees and Isotonic Regression to accommodate the trade-off between flexible functional forms and maximum information value.
| Version: | 0.2.1 |
| Imports: | rpart |
| Published: | 2018-10-12 |
| Author: | Daniel Safai |
| Maintainer: | Daniel Safai <danielsafai at gmail.com> |
| License: | GPL-2 | GPL-3 [expanded from: GPL (≥ 2)] |
| NeedsCompilation: | no |
| CRAN checks: | varbin results |
| Reference manual: | varbin.pdf |
| Package source: | varbin_0.2.1.tar.gz |
| Windows binaries: | r-devel: varbin_0.2.1.zip, r-release: varbin_0.2.1.zip, r-oldrel: varbin_0.2.1.zip |
| OS X binaries: | r-release: varbin_0.2.1.tgz, r-oldrel: varbin_0.2.1.tgz |
Please use the canonical form https://CRAN.R-project.org/package=varbin to link to this page.


 Let's say you were immensely lucky and your little service's traffic went over the roof, because Justin Bieber started using your service. So, your service starts to crash because the backend store your servers uses to serve content from, is getting overloaded, you certainly can't blame the beliebers for it? Caching will certainly help reduce the load on the database, so you added a local cache in every server. And to increase the hits you wisely started to use Consistent Hashing as a load balancing algorithm, after all it's what Memcached uses right? But soon after that you saw that while you got better cache hits, the load became skewed, and that there's an increased load on the servers that hosts Justin's site. There's still a way to have the best of both worlds, high cache hits and bounded server load. This is where Consistent Hashing With Bounded Loads comes into play.
It's a variation of Consistent Hashing
that guarantees an upper bound on the maximum load of every server (ceil((total_load/number_of_server)*scale_factor)
) relative to the average total load of the cluster.
The algorithm works the same way as Consistent Hashing but differs in how it selects a server in order to assign work to it.
The step goes as follows:
In pseudo code:
// initialize a hash table to keep track of the current load of each server loadTable := {"<IP_ADDRESS>": 0, "<IP_ADDRESS>": 0. "<IP_ADDRESS>": 0} // a counter that track the total load of the whole cluster totalLoad := 0 // a function to calculate the maximum load allowed per server def maxLoad() int: // scale_factor controls the amount of overhead each server can take // in this implementation a server will incur 25% load more than // the average load per server scale_factor = 1.25 // the 1 added to the average is there to make sure that // the current request will always be served by a server no matter what return ((totalLoad/length(loadTable))+1)*scale_factor // a function that return true if the given host is can serve the current request // otherwise it returns false def loadOK(hostName string) bool: if loadTable[hostName] < maxLoad(): loadTable[hostName]++ totalLoad++ return true else: return false
An example of the code used by the client to assign requests to servers, using liblb/consistent
Go package, which implements the Consistent Hashing algorithm.
lb := bounded.New("<IP_ADDRESS>:8009", "<IP_ADDRESS>:8008", "<IP_ADDRESS>:8007") for i := 0; i < 10; i++ { host, err := lb.Balance("hello, world!") if err != nil { log.Fatal(err) } lb.Inc(host) // a host will get an upper load of ceil(((total_load/number_of_server)+1)*scale_factor) // which for this example, is ceil(((10/3)+1)*1.25) = 6 fmt.Printf("Send request #%d to host %s\n", i, host) lb.Done(host) }
1/(e^2)
of the keys, where e
is scale_factor-1
. In our example scale_factor
is 1.25 so the percentage of keys that change location is 1/(0.25^2)
resulting in 16% of the keys.


Robert Starchead Fan Club
This is my fan club and I will be posting regular content on here, be sure to check it out.
Hey guys its Robert n today I have a quick post of me in my bin :D
About me
Im a cool youtuber, i live in scotland but im not fum glasgow, im also 11 years old.
I hope to reach 1 million subscribers in the next few months. Remember to hit that like button and
subscribe for more content.
My channel
Channel Link
Vlogs


| Home | Trees | Indices | Help |
|---|
|
|
object --+ | Api
A python interface into the Yipit API All calls require to to pass in your Yipit API Key as api_key For example: >> import yipit >> api = yipit.Api(api_key='jkldskfjdfl88234llkj')
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
|||
|
Inherited from |
|
|||
|
Inherited from |
|
Instantiate a new yipit.Api object. Args: api_key: Your Yipit API Key.
|
Return deals from Yipit given the parameters' Args: lat,lon: Latitude and longitude (respectively) of point to sort deals by proximity to. Uses radius. [Optional] Example: lat=-37.74,lon=-76.00 radius: Maximum distance of radius in miles to deal location from center point. Defaults to 10. Requires lat and lon if used. [Optional] Example: radius=1.7 division: A list of one or more division slugs. To see division slugs call Api.get_divisions() which lists yipit.Division instances[Optional] Example: division=["new-york", "atlanta"] source: A list of one or more source slugs. To see source slugs call Api.get_sources() which lists yipit.Source instances [Optional] Example: source=["groupon", "scoutmob"] phone: A list of phone numbers of specific bussinesses. Deals available at a business matching one of the phone numbers. [Optional] Example: phone=[2124134259,2124655555] tag: A list of one or more tag slugs. To see tag slugs call Api.get_tags() which lists yipit.Tag instances [Optional] Example: tag=["restaurants","bar-club"] paid: If set to True, returns only deals Yipit pays you as a dev. If set to False (default/recommended), returns deals Yipit does not pay you for. [Optional] Example: paid=True limit: Sets maximum number of items returned. Default 20. Max 5000. [Optional] Example: limit=300 Returns: A list of yipit.Deal instances, each matching the parameters given |
Return a deal from Yipit based off its Yipit deal id Args: deal_id: returns a yipit.Deal instance with the an id matching deal_id or nothing if it does not exist Returns: A yipit.Deal instance, matching the deal_id. Or None if none match. |
Returns a list of object instances from calling the api with the url and given parameters. The object type is determined by the yipit_type_key. Args: url: The string url to be requested. yipit_type_key: The string key to be found inside the 'response' section of the Yipit API call. The following keys are known to currently work: 'deals', 'sources', 'divisions', 'tags', 'businesses' **params: A packed dictionary of values to be translated into a query string. [Optional] Returns: A list of yipit.Deal/yipit.Source/yipit.Division/yipit.Tag/ yipit.Business (depending on the yipit_type_key given) instances grabbed and processed from the url with the given parameters |
Return Sources from Yipit given the parameters' Args: division: A list of one or more division slugs. To see division slugs call Api.get_divisions() which lists yipit.Division instances[Optional] Example: division=["new-york", "atlanta"] paid: If set to True, returns only deals Yipit pays you as a dev. If set to False (default/recommended), returns deals Yipit does not pay you for. [Optional] Example: paid=True limit: Sets maximum number of items returned. Default 20. Max 1000. [Optional] Example: limit=300 Returns: A list of yipit.Source instances, each matching the parameters given |
Return Divisions from Yipit given the parameters' Args: source: A list of one or more source slugs. To see source slugs call Api.get_sources() which lists yipit.Source instances [Optional] Example: source=["groupon", "scoutmob"] lat,lon: Latitude and longitude (respectively) of point to sort divisions by proximity to. Uses radius. [Optional] Example: lat=-37.74,lon=-76.00 radius: Maximum distance of radius in miles to deal location from center point. Defaults to 10. Requires lat and lon if used. [Optional] Example: radius=1.7 limit: Sets maximum number of items returned. Default 20. Max 200. [Optional] Example: limit=200 Returns: A list of yipit.Division instances, each matching the parameters given |
Return Tags from Yipit given the parameters' Note: Yipit currently does not have any parameters to specify tag search. Returns: A list of yipit.Tag instances, each matching the parameters given |
Return businesses from Yipit given the parameters' Args: lat,lon: Latitude and longitude (respectively) of point to sort businesses by proximity to. Uses radius. [Optional] Example: lat=-37.74,lon=-76.00 radius: Maximum distance of radius in miles to businesses location from center point. Defaults to 10. Requires lat and lon if used. [Optional] Example: radius=1.7 division: A list of one or more division slugs. To see division slugs call Api.get_divisions() which lists yipit.Division instances[Optional] Example: division=["new-york", "atlanta"] phone: A phone numbers of the specific bussiness. [Optional] Example: phone=2124134259 NOTE: The Business API has NOT YET BEEN FULLY IMPLEMENTED. Not all businesses are listed. The Business API is intended to be used to look up a business. Returns: A list of yipit.Business instances, each matching the parameters given |
Fetch the data from a url with the given parameters Args: url: The URL to retrieve parameters: A packed dictionary whose key/value pairs will be added to the query string. [Optional] Returns: A string representation of the body of the response |
Try and parse the JSON returned from Yipit's API Args: json: The JSON string Returns: A dictionary object of the parsed JSON, or if there was some error then return the error information |
Builds a url with a proper query string based off the parameters Args: url: The base of the URL parameters: A dictionary whose key/value paris will be translated to a query string and appended to the base URL. [Optional] Returns: A string of the concacted base URL and query string |
Raises a YipitError if Yipit returns an error Args: data: A converted JSON dict with a response from the Yipit API. Should always have the keys 'meta' and 'response' Raises: YipitError wrapping for yipit error message if one exists |
| Home | Trees | Indices | Help |
|---|
| Generated by Epydoc 3.0.1 on Sun Oct 9 02:19:13 2011 | http://epydoc.sourceforge.net |


Contact
This page lists the contact points and communication channels for Gammapy
-
Gammapy slack (gammapy.slack.com)
Many Gammapy developers and users are using the Gammapy Slack to chat. There is a #general and some other Slack channels that will go to many people. But you can also join and use the Gammapy slack for 1:1 text chat with someone from the Gammapy team to get help with Python, git, Gammapy, ... The Gammapy slack is private and the history is not archived, i.e. is lost at some point.
To get access, sign-up here, and wait a bit for moderator approval. -
Gammapy CTA mailing list
<EMAIL_ADDRESS>archive)
Ask any question about CTA data analysis with Gammapy. This is a private mailing list, so discussing CTA-internal information is OK.
Sign up here, and wait a bit for moderator approval. -
Gammapy coordination committee mailing list
<EMAIL_ADDRESS>archives)
Use this mailing list to contact the Gammapy coordination committee. Anyone can post, but only coordination committee members can read it. Don't be shy: just email us if you have any question or comment about Gammapy! -
Github (https://github.com/gammapy/gammapy)
The place where we develop Gammapy (code, tests, documentation). If you want to report an issue, you can do it directly in the issue tracker there, or by posting on the mailing lists mentioned above.
You can make a Github account yourself, it's free.


A new game show with doors has been invented and you are invited. In this case, there are two doors. Each has a pile of gold Krugerrands behind it, but one has twice as many as the other. You point to a door. The game show host opens it for you, then offers to allow you to switch your choice.
Picture it. You are on stage, the TV lights glaring. The host has just opened the door. Before you lie the coins, glistening. The audience lets out a moan of admiration and envy. For a moment you feel faint. Then the game show host, Monty Hall style, interrupts your reverie and offers you the opportunity to switch doors. (He does this to every contestant every time.) Do you do it?
Before you decide, you have to know the possibilities. Half the time, there are 100 coins behind one door and 200 coins behind the other. One quarter of the time there are 200 behind one door and 400 behind the other. One quarter of the time there are 400 coins behind one door and 800 behind the other.
You want to maximize your expected winnings.
Duh. Clearly yes, because you cannot lose. If there are 800 coins, just as clearly you don’t change.
Would you switch if you see 200 coins behind the door?
Would you switch if you see 400 coins behind the door?
Suppose that the probabilities were 1/3, 1/3, 1/3 instead of 1/2, 1/4, 1/4. Then would you switch if there were 400 coins?
It’s a new season and the game show producers are afraid of a drop of popularity. For that reason the producers set the range of coins to be much larger: 25, 50, 100, 200, 400, 800, 1600, 3200, and 6400. All the door possibilities - 25-50, 50-100, and so on up to 3200-6400 - are equally likely.
Assuming your first selected door opens to any number of coins other than 25 or 6,400, should you switch?
Another season passes and the TV ratings are flagging just a little. The producer decides to extend the range from 1 coin to 1,048,576 coins. All x-and-2x possibilities are equally likely, he promises. But now that the extremes are so unlikely, the host won’t bother opening the door that the contestant first guesses. When the contestant makes his final choice, the curtain opens to a large bucket of gold, the sight of which causes predictable shrieks among the audience.
Should the contestant switch even when the host doesn’t open the contestant’s initial door?
Would you switch if you see 200 coins behind the door?
Let’s find the equi-probable events. Because the 100-200 situation is twice as likely as any other, we’ll write that one twice. The following are the equi-probable door pair situations:
|
100 |
200 |
|
100 |
200 |
|
200 |
400 |
|
400 |
800 |
Therefore, if you see 200 coins, you are twice as likely to be in the 100-200 situation as in any other. Switching to the other door, therefore, is twice as likely to cause you to lose 100 coins as to win 200. So, your expected winning by switching is zero. It’s your call.
Would you switch if you see 400 coins behind the door?
In this case, you are as likely to be in the 200-400 as in the 400-800 situation. In the first case, switching costs you 200 coins. In the second, switching enables you to win 400. So you expect to benefit by switching.
Suppose that the probabilities were 1/3, 1/3, 1/3 instead of 1/2, 1/4, 1/4. Then would you switch if there were 400 coins?
In this case, the equi-probable situations are:
|
100 |
200 |
|
200 |
400 |
|
400 |
800 |
Nothing has changed for the 400 coin case - you should switch. By the way, you should switch in the 200 coin case as well. Half the time, you’ll win an extra 200 coins.
Assuming your first selected door opens to any number of coins other than 25 or 6,400, should you switch?
Switch every time. It’s the same reasoning as in question 3.
Should the contestant switch even when the host doesn’t open the door to which the contestant first points?
Switching doesn’t help on the average. By symmetry it can’t. If it did, then the contestant could have simply chosen the other door to begin with. As the game show host opened no door, the contestant has gained no information. But how do we show this analytically? The equi-probable situations are:
|
1 |
2 |
|
2 |
4 |
|
4 |
8 |
|
… | |
|
1,048,576 |
524,288 |
In each case, if the contestant switches in one direction in the x-and-2x situation he will win x; if he switches in the other, he will lose x. So switching as a strategy yields no net gain (or loss). Why is this protocol different from the one where the host opens the door that the contestant first points to? In that protocol, the only time the contestant doesn’t switch is when he sees the bucket with 1,048,576 coins. That happens only one time in 40, but in that case, the contestant saves 524,288 coins by not switching. Therein lies the contestant’s edge.


Dashboard
Generate Report
Sort By:
Category
Language
Date Published
Our Stories
{% for post in posts %}
{% endfor %}
{{post.title}}
Some quick example text to build on the card title and make up the bulk of the card's content.
Read More


I am currently a junior at the College of William and Mary (US News Ranking) pursuing a BS in Computer Science. While I enjoy working on all aspects of technology, some of my specific interests include machine learning, mobile application development, and network security. I love working on projects and am interested in contributing to open source projects in my free time.


--- layout: post title: Using aliases tags: [] status: publish type: post published: true meta: {} ---
This document will introduce you to the aliases file. You can use this file to create mailing lists, reference old user accounts to new ones, or even point departed employee accounts to a manager's account to make sure that no e-mail message gets lost. Before we begin please make sure that you have either superuser access rights or are logged in as root. Also you will have to be familiar with Vi editing (see Basic Vi editing for an introduction). Also in the examples don't type the information in brackets, unless othewise specified, as it's only their for comment purposes.
Creating alternative user names
To set up an alias you need to edit the file aliases located in /etc. To alias alternative user names to an actual account follow this example using our John Smith:
vi /etc/aliases
(Scroll down the alias file until you get to #USER LIST, immedialtely after it add an entry for John Smith using the following syntax)
#jsmith John Smith Sales
(Next you can create your own alias lists of alternative names, insert the following lines)
#Groups at your company
#Alternative user names
johns: jsmith
(Save and exit the file and type the following command to inform sendmail of the update)
sendmail -bi
Creating a mailing list The same technique is applied to creating a mailing list. Here you simply create an alias and add all the account names that the messages sent to alias are to be delivered to. To clarify this point just imagine you want to create a sales team mailing list with the following address<EMAIL_ADDRESS>Here the alias will be sales and all members of the sales team have tobe added to that alias.
vi /etc/aliases
(Scroll to the of the alias file, i.e. after the last entry made and insert the following assuming that you two user called jsmith and jdough)
#Sales at your company
sales: jsmith,jdough
(Save and exit the file and type the following command to inform sendmail of the update)
sendmail -bi
There is one thing you should bear in mind when editing the aliases file. Make sure that you never leave more than 1 blank line at the end of the file. If you leave 2 empty lines when it comes to running the sendmail -bi command, you'll get an error message and the system won't be updated. Please note it's also good practice to add a reference to the user list (#USER LIST) every single time you add a new user to the system. Chances are he'll have to be added to a mailing group anyway. Right's that's all...


This link is invalid. You'll need to sign in and confirm your email again so we can send you a new link.
This link has expired. You'll need to sign in and confirm your email again so we can send you a new link.


Parallel Animation Group
Exercise 1 - Make a Parallel Group
Groupings are important so let's get started on the exercise
In this exercise, create a parallel group of animation that has 3 children. Each children should run 300px, 500px, 700px from top respectively for 5 seconds.
Hint: you should first create the children then include the children into the group. You might also need to create more animation divs in the html section and change their colour depends on your preferences.
Show Solution
var A = new Animation(document.querySelector("#a"), {top: "300px"}, 5);
var B = new Animation(document.querySelector("#b"), {top: "500px"}, 5);
var C = new Animation(document.querySelector("#c"), {top: "700px"}, 5);
new ParGroup([A, B, C]);


Messari brings transparency to the cryptoeconomy. We want to help investors, regulators, and the public make sense of this revolutionary new asset class, and are building data tools that will drive informed decision making and investment. We believe that crypto will democratize access to information, break down data silos, and ultimately give everyone the tools to build wealth.
Our team is an exceptional crew of industry experts and creative problem solvers. Our backgrounds span a diverse landscape of fields including mathematics, public service, economics, engineering, finance, linguistics, urbanism, philosophy and art.


--- title: Template for sam nbdev keywords: fastai sidebar: home_sidebar summary: "Summary description here." description: "Summary description here." nb_path: "index.ipynb" ---
pip install aws-sam-cli nbdev pynamodb-dax
to configure aws credentials run brew install awscli
then aws configure
you can put the IAM user keys in
fill in all the notebooks in the folder nbs
#export
on top of any cells you want to export and #default_exp filename
on top of the notebook (see exampleget.ipynb
)#hide
on top of the cells you dont want to include in python packagemake build
edit sam template
template.yaml
make test
put library to install with pip into layerRequirements.txt
or samRequirements.txt
only for the first run:
sam build
then sam deploy --guided
make test
editing the app router
app/app.py
from src.<your nb name> import <your lambda function in nbdev>
#export
on top of the cells you want to include in the product(optional) to deploy using github action, edit the deploy.yml
file as appropriate
in most cases you should only edit the last line
go to cloudformation console to see the result


Premiere: Ignacio Arfeli - Weird Stone [Odd Recordings]
Peak-time warehouse techno
by MagneticToday, Magnetic brings you an exclusive premiere from Arjun Vagale's Odd Recordings imprint. 'Weird Stone', from Ignacio Arfeli, is a peak-time techno stomper that is perfectly at home in any club or warehouse. A boxy kick marches forward the lead bell-like sound dances around it, reaching a frenzy once the track hits the climax. The track is part of the label's upcoming Series 01 VA, which also features, Irregular Synth, Juliana Yamasaki, KUSP and Yoikol, and will be released November 15th. Pre-order it here.
Track: Weird Stone
Artist: Ignacio Arfeli
Label: Odd Recordings
Format: Digital
Release Date: 11-15-19


postgresql: types/providers for postgresql files for Puppet
This module provides a new type/provider for Puppet to read and modify postgresql config files using the Augeas configuration library.
The advantage of using Augeas over the default Puppet parsedfile
implementations is that Augeas will go to great lengths to preserve file
formatting and comments, while also failing safely when needed.
This provider will hide all of the Augeas commands etc., you don't need to know anything about Augeas to make use of it.
Requirements
Ensure both Augeas and ruby-augeas 0.3.0+ bindings are installed and working as normal.
See Puppet/Augeas pre-requisites.
Installing
On Puppet 2.7.14+, the module can be installed easily (documentation):
puppet module install herculesteam/augeasproviders_postgresql
You may see an error similar to this on Puppet 2.x (#13858):
Error 400 on SERVER: Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid resource type `pg_hba` at ...
Ensure the module is present in your puppetmaster's own environment (it doesn't
have to use it) and that the master has pluginsync enabled. Run the agent on
the puppetmaster to cause the custom types to be synced to its local libdir
(puppet master --configprint libdir
) and then restart the puppetmaster so it
loads them.
Compatibility
Puppet versions
Minimum of Puppet 2.7.
Augeas versions
| Augeas Versions | 0.10.0 | 1.0.0 | 1.1.0 | 1.2.0 |
|---|---|---|---|---|
| PROVIDERS | ||||
| pg_hba | yes | yes | yes | yes |
Documentation and examples
Type documentation can be generated with puppet doc -r type
or viewed on the
Puppet Forge page.
pg_hba provider
Composite namevars
This type supports composite namevars in order to easily specify the entry you want to manage. The format for composite namevars is:
local to <user> on <database> [in <target>]
if defining a local (socket) rule, or:
<type> to <user> on <database> from <address> [in <target>]
otherwise.
In each form, in <target>
is optional. You can also use a personalized namevar and specify all parameters manually.
manage simple local entry
pg_hba { 'local to all on all':
ensure => present,
method => 'md5',
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
manage simple host entry
pg_hba { 'host to all on all from <IP_ADDRESS>':
ensure => present,
method => 'md5',
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
multiple users and databases
pg_hba { 'host to user1,user2 on db1,db2 from <IP_ADDRESS>':
ensure => present,
method => 'md5',
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
pg_hba { 'Allow +foo and @bar to mydb and yourdb':
ensure => present,
user => ['+foo', '@bar'],
database => ['mydb', 'yourdb'],
method => 'md5',
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
using a personalized namevar
pg_hba { 'Default entry':
type => 'local',
user => 'all',
database => 'all',
method => 'md5',
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
pass options for the method
pg_hba { 'Default entry with option':
method => 'ident',
options => { 'sameuser' => undef },
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
pg_hba { 'host to all on all from .dev.example.com in /etc/postgresql/9.1/main/pg_hba.conf':
method => 'ldap',
options => {
'ldapserver' => 'auth.example.com',
'ldaptls' => '1',
'ldapprefix' => 'uid=',
'ldapsuffix' => ',ou=people,dc=example,dc=com',
},
}
insert entry in specific position
pg_hba { 'local to all on all':
ensure => present,
method => 'md5',
position => 'before first entry',
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
pg_hba { 'local to all on all':
ensure => present,
method => 'md5',
position => 'after last entry',
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
pg_hba { 'local to all on all':
ensure => present,
method => 'md5',
position => 'before last local',
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
pg_hba { 'local to all on all':
ensure => present,
method => 'md5',
position => 'after first hostssl',
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
pg_hba { 'local to all on all':
ensure => present,
method => 'md5',
position => 'after first anyhost', # any type matching host.*
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
pg_hba { 'local to all on all':
ensure => present,
method => 'md5',
position => 'before 5', # Before the fifth entry
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
pg_hba { 'local to all on all':
ensure => present,
method => 'md5',
position => '*[database="all" and user="admin"][1]', # First entry for database 'all' and user 'admin'
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
ensure position is correct
pg_hba { 'local to all on all':
ensure => positioned,
method => 'md5',
position => 'before first entry',
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
delete entry
pg_hba { 'local to all on all':
ensure => absent,
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
pg_hba { 'host to all on all from <IP_ADDRESS>':
ensure => absent,
target => '/etc/postgresql/9.1/main/pg_hba.conf',
}
Issues
Please file any issues or suggestions on GitHub.


Description
DEWAG make 3-Phase SCR Controller is designed to control phase
angle of SCRs in 3 phase half controlled SCR-Diode bridge
configuration. It is ideal for use in Battery Charger, Power Supply
etc. applications.
Features
- Smooth Phase angle control over entire range
- Soft start for limiting inrush current
- Gate circuit protection
- Constant Voltage/Constant Current modes
- Auto/manual operating modes
- Plug-in PCBs for ease of maintenance
- Easy to install
Dimensions
- Overall: 360mm(L) X 215mm(W) X 200mm(H)
- Mounting: By 4 screws, 5mm dia.
Technical Specifications
- Supply Voltage:- 415V AC, 3ph., 4wire
Ordering Information
- Series: 3PC-01 Model: 03
- Output Voltage: 24V, 48V, 110V, 220V DC


tablemodify is a javascript-plugin which boosts your html tables with awesome style and functionalities!
It is written in plain js, so no jQuery is required.
Tm is based on a core Tablemodify-object which can be extended by several modules.
There are some modules defined by default or you could even write your own if you wish to.
Browser support: supported by all major browsers (IE11, Firefox, Opera, Chrome, Safari).
the current version is 0.9.6
Intro
Demo
| first name | last name | birthday | score | favourite pet |
|---|
the demo shows the modules 'pager', 'sorter', 'filter', 'fixed' and 'columnStyles' in action.
Setup
First of all, get the sources from Github ("/dist/") and include them in your header.
what you need:
- tablemodify.js or tablemodify.min.js
- tablemodify.css
- a .css-file from the theme folder
After the document has loaded, you can initialize the Tablemodify-instance.
var tm,
options = {} // some options can be passed via this object, read more below
function init() {
tm = new Tablemodify('#myTable', options) // assume the table's selector is #myTable.
}
window.addEventListener('DOMContentLoaded', init)
options
an overview over all the options you can choose:
{
// table will be wrapped in a container. you may give it an id
containerId: 'myContainer',
// default is 'en', choose between 'en', 'de', or add own Language pack (read below)
language: 'en',
// necessary! pass your theme's name here
theme: 'default',
// pass 'fade' or null. adds a nice transition when the table data changes
transition: 'fade',
/*
This is an overview of the default modules tablemodify offers.
All modules are optional.
To run a module, add it's name to the following object. the values are js-objects again.
To run a module with default values, you can just pass an empty object, for example: "sorter: {}",
The specific module settings will be explained in the accompaniyng chapter.
*/
modules: {
columnStyles: columnStylesSettings,
filter: filterSettings,
sorter: sorterSettings,
pager: pagerSettings,
fixed: fixedSettings
}
}
Modules
All modules are optional and work independent.
Once initialized, it is possible to access them via tm.getModule(name)
, each provides some utilities you can use.
sorter
This module sorts the rows of your tbody, ascending or descending, sorted by a single column or even by multiple columns.
For multisort, press shift and click another head cell. Still press shift and click a selected cell again to invert the order.
For big data amounts, it is recommended to combine sorter and pager or sort via php.
var sorterSettings = {
/*
these are the defaults:
*/
initialColumn: 'firstEnabled', // initial sorting column, either a column index or the special value 'firstEnabled'
initialOrder: 'asc', // initial sorting order, either 'asc', or 'desc'
enableMultisort: true, // enable/disable multisort functionality
columns: {
all: {
enabled: true,
parser: 'intelligent' // different types of parsers: 'intelligent' (for strings and numbers combined),
// 'string', 'numeric' (integer and float), 'date' (see below)
},
/*
custom settings for single columns:
*/
0: {
enabled: false // disable sorting
},
1: {
parser: 'date', // use another parser for this column
parserOptions: { // provide parameters to the parser
preset: 'english'
}
}
},
/*
adding own parsers. Read below how it works.
*/
customParsers: customParsers
}
parsers
there are some parsers available by default:
| parsername | notice | description | parameters |
|---|---|---|---|
| "intelligent" | default | differentiates automatically between strings and numbers. recommended for mixed types. | none |
| "string" | sorts in alphabetic order. efficient, recommended for pure strings | none | |
| "numeric" | sorts numbers (also floats). efficient, recommended for numbers | none | |
| "date" | sorts by a given date format | format: A date/time format string which will be used to parse the dates preset: either 'english' or 'german', 'german' will match 'TT.MM.YYYY' and 'TT.MM.YY', 'english' will match 'YYYY-MM-DD' or 'MM/DD/YYYY'. It is recommended not to rely on the presets but rather provide your own date format string Here you can find an overview of the tokens which can be used |
A parser is simply a compare function which is passed to the Array.sort() method. here you can read more about compare functions If you want to define your own parsers, add them like this:
var customParsers = {
myParser: function(a, b) {
/*
parameters a, b: strings of two cell-contents to compare.
if a > b, return a positive number,
if a < b, return a negative number,
if a = b, return 0. (<- this is important for multisort!)
*/
// for example, this is the implementation of parser "string"
if (a > b) return 1
if (a < b) return -1
return 0
}
}
change header appearance
you can simply overwrite the default sorter styles of your table. Therefore, tm provides several css-classes.
Different order-icons:
/* default sorter icon (for no active sorting) */
.tm-container td.sortable {
background-image:url(path/to/your/icon-default.jpg);
}
/* icon for active ascending order */
.tm-container td.sortable.sort-up {
background-image:url(path/to/your/icon-up.jpg);
}
/* icon for active descending order */
.tm-container td.sortable.sort-down {
background-image:url(path/to/your/icon-down.jpg);
}
different background-color of active sorting:
/* this will set the color to yellow */
.tm-container td.sortable.sort-up, .tm-container td.sortable.sort-down {
background-color: 'yellow'
}
pager
filter
fixed
columnStyles
resizer
Themes


Spring Web MVC is a Java based framework that facilitates web development through the use of the model-view-controller pattern.
model-view-controller
This sample application demonstrates the use of the following features of the Spring Web MVC framework:


Our Lawyers
Directors
-
Pauline H. Wilson Claudio Ruz Software for you, for free. You can replace all this text with your own text.You can remove any link to our website from this website template.
-
Kenneth E. Lunderberg You're free to use this website template without linking back to us. Horizont System
Senior Associates
-
George R. Montgomery Claudio Ruz Software for you, for free. You can replace all this text with your own text.You can remove any link to our website from this website template.
Associates
-
Denise M. Silvia Claudio Ruz Software for you, for free. You can replace all this text with your own text.You can remove any link to our website from this website template.
-
Nancy R. Bakken You're free to use this website template without linking back to us. Horizont System


Component without overlayComponent without overlay - alpha enabledDisable
Change used color label
Additional collections
Additional collection with colors object as input
Show used colors after custom collections
Show used color reversed
Max usedColors lengthDefine used colors init valueHide empty color slotsHide "EMPTY_COLOR" option from used colorsReset used colorsCustom selector heightHide color picker selectorChange color when confirmChange color on changeHide colors formChange button labelsHide buttonsConnect color picker with an input - HEXConnect color picker with an input - RGBConnect color picker with an input - HSLConnect color picker with an input - RGB with alphaConnect color picker with an input - RGB with alpha inside Field (use matPrefix and matSuffix)Connect color picker with an input - HEX with alpha inside Field (use matPrefix and matSuffix) - mccColorPickerOrigin="openOnFocus"
Connect color picker with an input - HEX with alpha inside Field (use matPrefix and matSuffix) - mccColorPickerOrigin="openOnFocus" with hidden color-button
Connect color picker with an input - HSL with alpha inside Field (use matPrefix and matSuffix)


The release of 0.8.3 includes the following improvements to Export and Import APIs:
The Import-Export APIs for Atlas facilitate transfer of data to and from a cluster that has Atlas provisioned.
The APIs when integrated with backup and/or disaster recovery process will ensure participation of Atlas.
There are 2 broad categories viz. Export & Import. The details of the APIs are discussed below.
The APIs are available only to admin user.
Only a single import or export operation can be performed at a given time. The operations have a potential for generating large amount. They can also put pressure on resources. This restriction tries to alleviate this problem.
For Import-Export APIs relating to HDFS path, can be found here.
For additional information please refer to the following:
If an import or export operation is initiated while another is in progress, the consumer will receive this error:
"ATLAS5005E": "Another import or export is in progress. Please try again."
Unhandled errors will be returned as Internal error code 500.


THE MIRROR HAS TWO FACES RATING: 7 / 10 --> Good movie
For more movie reviews and trivia, visit http://www.joblo.com/
PLOT: A nerdy College professor believes that the perfect relationship between a man and a woman should be based entirely on matters other than physical attraction and sex. He decides to prove this theory to himself by choosing a physically unattractive woman as his companion. She also seems to agree with his theory but ultimately falls into the traps of the human heart.
CRITIQUE:
Pleasant film with an interesting premise managed to keep me entertained
through all of its lengthy runtime, which is a little over two hours, with
some funny lines, original points of view on relationships, and a simple but
applicable musical score. One of the only problems that I had with this film
was the casting of Barbra Streisand as the "ugly ducking" woman.
Little Known Facts about this film and its stars: Dudley Moore was originally cast in the role that went to George Segal. "Creative differences" were cited for his reason for leaving. This film is a remake of the 1958 French film LE MIROIR A DEUX FACES.
Review Date: February 7, 1999 Director: Barbra Streisand Writer: Richard LaGrenevese Producer: Barbra Streisand and Arnon Milchan Actors: Barbra Streisand as Rose Morgan, Jeff Bridges as Gregory Larkin, Lauren Bacall as Hannah Morgan Genre: Romance Year of Release: 1996
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


|
eDSP
0.0.1
A cross-platform DSP library written in C++.
|
Classes | |
| class | leq |
| This class estimates the Equivalent Continuous Sound Level over consecutive frames. More... | |
Functions | |
| template<typename InputIt , typename OutputIt > | |
| constexpr void | amdf (InputIt first, InputIt last, OutputIt d_first) |
| Computes the AMDF (Average Magnitude Difference Function) of the contiguous elements in the range [first, last) and stores the result in another range, beginning at d_first. More... | |
| template<typename ForwardIt , typename Numeric > | |
| constexpr auto | duration (ForwardIt first, ForwardIt last, Numeric samplerate) |
| Computes the duration of the elements in the range [first, last) More... | |
| template<typename ForwardIt , typename Numeric > | |
| constexpr auto | effective_duration (ForwardIt first, ForwardIt last, Numeric samplerate, Numeric threshold) |
| Computes the effective duration of the elements in the range [first, last) More... | |
| template<typename ForwardIt > | |
| constexpr auto | energy (ForwardIt first, ForwardIt last) |
| Computes the energy of the elements in the range [first, last) More... | |
| template<typename ForwardIt , typename Numeric > | |
| constexpr auto | lat (ForwardIt first, ForwardIt last, Numeric samplerate, Numeric start_threshold, Numeric stop_threshold) |
| The laq class estimates the logarithmic attack time of an envelope signal. More... | |
| template<typename ForwardIt > | |
| constexpr auto | power (ForwardIt first, ForwardIt last) |
| Computes the instant power of the elements in the range [first, last) More... | |
| constexpr void edsp::feature::temporal::amdf | ( | InputIt | first, |
| InputIt | last, | ||
| OutputIt | d_first | ||
| ) |
Computes the AMDF (Average Magnitude Difference Function) of the contiguous elements in the range [first, last) and stores the result in another range, beginning at d_first.
Computes the AZCR (Average Zero Crossing Rate) of the contiguous elements in the range [first, last) and stores the result in another range, beginning at d_first.
Computes the ASDF (Average Square Difference Function) of the contiguous elements in the range [first, last) and stores the result in another range, beginning at d_first.
The definition of AMDF is:
\[ Q_x[k,n_0] \triangleq \frac{1}{N} \sum\limits_{n=0}^{N-1} \Big| x[n+n_0] - x[n+n_0+k] \Big| \]
| first | Input iterator defining the begin of the range to examine. |
| last | Input iterator defining the end of the range to examine. |
| d_first | Output iterator defining the begin of the output range. |
The definition of ASDF is:
\[ Q_x[k,n_0] \triangleq \frac{1}{N} \sum\limits_{n=0}^{N-1} \big( x[n+n_0] - x[n+n_0+k] \big)^2 \]
There is a relation between the ASDF function and the ACF function:
\[ \begin{align} x[k] & \triangleq \frac{1}{N} \sum x[n] x[n+k] \\ & = \overline{x^2[n]} - \tfrac{1}{2} Q_x[k] \\ & = R_x[0] - \tfrac{1}{2} Q_x[k] \\ \end{align} \]
| first | Input iterator defining the begin of the range to examine. |
| last | Input iterator defining the end of the range to examine. |
| d_first | Output iterator defining the begin of the output range. |
The definition of AZCR is:
\[ {\displaystyle zcr={\frac {1}{T-1}}\sum _{t=1}^{T-1}\mathbb {1} _{\mathbb {R} _{<0}}(s_{t}s_{t-1})} \]
| first | Input iterator defining the begin of the range to examine. |
| last | Input iterator defining the end of the range to examine. |
| d_first | Output iterator defining the begin of the output range. |
| constexpr auto edsp::feature::temporal::duration | ( | ForwardIt | first, |
| ForwardIt | last, | ||
| Numeric | samplerate | ||
| ) |
Computes the duration of the elements in the range [first, last)
| first | Forward iterator defining the begin of the range to examine. |
| last | Forward iterator defining the end of the range to examine. |
| samplerate | Sampling frequency in Hz. |
| constexpr auto edsp::feature::temporal::effective_duration | ( | ForwardIt | first, |
| ForwardIt | last, | ||
| Numeric | samplerate, | ||
| Numeric | threshold | ||
| ) |
Computes the effective duration of the elements in the range [first, last)
The effective duration is a measure of the time the signal is perceptually meaningful. It is approximated by the time the energy envelope is above a given threshold.
| first | Forward iterator defining the begin of the range to examine. |
| last | Forward iterator defining the end of the range to examine. |
| samplerate | Sampling frequency in Hz. |
| threshold | Numeric value in the range [0, 1] representing the active threshold. |
| constexpr auto edsp::feature::temporal::energy | ( | ForwardIt | first, |
| ForwardIt | last | ||
| ) |
Computes the energy of the elements in the range [first, last)
The energy estimates the signal power at a given time, it is estimated directly from the signal frame around a given time:
\[ e = \sum\limits_{n=0}^{N-1} x^2(n) \]
| first | Forward iterator defining the begin of the range to examine. |
| last | Forward iterator defining the end of the range to examine. |
| constexpr auto edsp::feature::temporal::lat | ( | ForwardIt | first, |
| ForwardIt | last, | ||
| Numeric | samplerate, | ||
| Numeric | start_threshold, | ||
| Numeric | stop_threshold | ||
| ) |
The laq class estimates the logarithmic attack time of an envelope signal.
The log-attack time is the logarithmic (decimal base) of the time duration between the time the signal to the time it reaches its stable part:
\[ lat = \log10 \left( t_{stop} - t_{start} \right) \]
| first | Forward iterator defining the begin of the range to examine. |
| last | Forward iterator defining the end of the range to examine. |
| samplerate | Sampling frequency in Hz. |
| start_threshold | Numeric value between [0, 1] representing the percentage of the amplitude signal representing the start of the attack time. |
| stop_threshold | Numeric value between [0, 1] representing the percentage of the amplitude signal representing the limit of the attack time. |
| constexpr auto edsp::feature::temporal::power | ( | ForwardIt | first, |
| ForwardIt | last | ||
| ) |
Computes the instant power of the elements in the range [first, last)
The energy of signal can be computed as:
\[ P_x = \frac{1}{N} \sum\limits_{n=0}^{N-1} x^2(n) \]
| first | Forward iterator defining the begin of the range to examine. |
| last | Forward iterator defining the end of the range to examine. |