diessica

WAC 2019 Audiovisual Programming Workshop

Workshop Goals:

We will all have fun with the following:

Learning the basics of various environments for graphics programming and thinking about the strategies they use for syncing with audio. This will include shader programming and ray marching.
Watching videos / discussing strategies for how to “best” combine audio and visuals together. We will look at classic examples from the field of visual music and more recent contemporary examples.

Workshop Facilitator:

This is a proposal for a lightning talk at the Reactive 2016 conference. If you like this, star the Gist.

Thinking metrics on React applications

In regular websites, it is common to send multiple events to track user clicks. Single Page Applications change the way you look at metrics. This is a talk about a simple pattern we created at Globo.com to manage a metrics layer for http://globoplay.globo.com. The talk will cover how to track user flow using Google Analytics and other services. We solved the challenge of tying metrics and components, keeping information across pages and having global data. Also some React, React Router and React Side Effects concepts like context, higher order components, history state will be covered.

architectures and whatnot

plain ol' React

let state = initial
render(view(state), element)

view is pure!

We're excited to have you attend one of our workshops! Here's a JavaScript (re)fresher to help you get up-to-speed on some features of the language we'll be using.

Let and Const

JavaScript has always had var:

var name = 'Ryan'

Folder Structure

Please note

While this gist has been shared and followed for years, I regret not giving more background. It was originally a gist for the engineering org I was in, not a "general suggestion" for any React app.

Typically I avoid folders altogether. Heck, I even avoid new files. If I can build an app with one 2000 line file I will. New files and folders are a pain.

The introduction to Reactive Programming you've been missing

(by @andrestaltz)

This tutorial as a series of videos

If you prefer to watch video tutorials with live-coding, then check out this series I recorded with the same contents as in this article: Egghead.io - Introduction to Reactive Programming.

Documentation-Driven Development

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.

Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
Once documentation has been written, development should commence, and test-driven development is preferred.
Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
When a feature is being modified, it should be modified documentation-first.
When documentation is modified, so should be the tests.

The Open Information Pledge

I believe in the freedom of information, free as in money, and free as in freedom. That this is a fundamental requirement for empowerment.

Ideas

I understand that ideas are not copyrightable. I expect that you understand this too. I expect that we can both regard all ideas discussed to be of Public Domain, as they are.

Implementations

I understand that the implementation of ideas is copyrightable.

	const R = new LaRamda()

	/**
	* A subset of custom implementations of functions from
	* the Ramda library. (all in Lamda form)
	* - thanks to @xgrommx for uniq, intersection, where, evolve,
	* applySpec, defaultTo, both, either, cond, zipWith
	*/
	function LaRamda () {
	const I = x => x

	#!/bin/bash


	# ------------------------------------------------------------------------------
	# \| System \|
	# ------------------------------------------------------------------------------

	# Navigation
	# -------------------