Dom dpiatek

Creating interactive audio visualisations with Clojurescript, Figwheel and Web Audio

For years, one of the great strengths of writing code for the browser was the short feedback loop. Write some HTML, Javascript and CSS, hit refresh. See it sparkle. Rinse and repeat. In time, we've lost some of that power; web apps are a lot more complex these days, code is often compiled and our applications have a lot more state, which is lost on refresh and so our quick feedback loop is gone. Figwheel is a library for Clojurescript that aims to give us some of that power back, provided you will write "re-loadable" code. I wasn't really sure what that would entail, so I set out to make a project - a tiny library for creating audio visualisations, that would let you change the graphics while the music is playing.

The key enabler, though in the end a small part of the library, is the Web Audio API interop. It's somewhat of a peculiar API if you've never worked with audio; it allows you to create nodes and connections betwee

There has been recently a big drive in the web development community to improve the performance of websites and web apps. Google has been a big part in this, favouring fast websites and tying in performance improvements to better UX. For the most part, this is great. What has been bugging me for a while though is that while performance is being put on a pedestal, other, many times business critical things are dismissed in it’s favour.

As developers, we love to improve performance. It’s a problem that is easy to understand but often hard to do, oftentimes requiring ingenuity, but also rewarding in nature. On the web, the situation get’s really complicated. We send more and more over the wire, while people rely often on flaky connections, we stretch the platforms to it’s limits, while our users GPU’s give up. So we get smart, tone down, cache, cache, cache. Sometimes, we get rid of good code abstractions because they are slow and replace them with something closer to the “metal”. And in this pursuit, hard but

	class MyCheckbox extends React.PureComponent {
	render() {
	const { label, checked, onChange } = this.props;

	return (
	<TouchableOpacity
	accessibilityComponentType={
	checked ? "radiobutton_checked" : "radiobutton_unchecked"
	}
	accessibilityTraits={

	(function(){
	var title = document.getElementById("shipment[address_attributes][title]")
	var firstname = document.getElementById("shipment[address_attributes][firstname]")
	var lastname = document.getElementById("shipment[address_attributes][lastname]")
	var companyname = document.getElementById("shipment[address_attributes][company]")
	var telephone = document.getElementById("shipment[address_attributes][phone]")
	var postcode = document.getElementById("shipment[address_attributes][find_address_postcode]")

	title.value = "Mr"
	firstname.value = "Bill"

	(function(){
	var terms = document.querySelector("[id$='[terms]']")
	terms.click();

	var cd = document.querySelector("[id$='[number]']")
	var name = document.querySelector("[id$='[name]']")
	var exp = document.querySelector("[id$='[expiry]']")
	var sc = document.querySelector("[id$='[verification_value]']")

	var btn = document.querySelector("button.payment-form__submit")

	"merch": {
	"banners": {
	"test 1" : {
	"banerContent" : "<img src=\"http://dicdevelopmenttrust.com/Redux/wp-content/uploads/2013/03/Diary.svg_.hi_.png\" />",
	"bannerLocation":"bottom_of_results",
	"creativeId":"5764479",
	"bannerId":"5764479",
	"bannerName":"test 1",
	}
	"test 2" : {

	"merch": {
	"banners": {
	"test 1" : { "banerContent" : "<img src=\"http://dicdevelopmenttrust.com/Redux/wp-content/uploads/2013/03/Diary.svg_.hi_.png\" />",
	"bannerLocation":"bottom_of_results",
	"creativeId":"5764479",
	"bannerId":"5764479",
	"bannerName":"test 1",}

	"test 2" : { "banerContent" : "<p>hello</p>"}

	DynamoDB backups notes:
	- shepherd-backup bucket in s3, subfolders for tables:
	activity, addresses, orders, customers, products and users
	- uses AWS data pipeline (which uses EMR), so will incur cost for both but should be fairly cheap
	- once a day at 5:00UTC, keep data for 2 weeks (deleted with s3 lifecycle management)
	- can't terraform until aws pipeline support https://github.com/hashicorp/terraform/issues/4077

	Data considerations:
	Our recent non-peak throughput per month is about 60k requests, and much more in peak. An average order might be 3-4KB,
	so our monthly space use should be around 240MB. The main use case for almost all data is get/set and much less retrieving
	sets, which are only needed for the UI. The sets need to support ordering as well as filtering.

	Design:
	Considering our relatively small workload and Dynamos constraints, we can put our "listable" data (orders, products,
	customers, addresses) into an single table where the hashkey is the type of data and sort key the id. Local indexes
	should be created for the sorting options we require at time of table creation. Local indexes reuse the table capacity
	so incur a lower cost, although they limit a given partitions size to 10GB, as well as actually copying the data thus

	- one table for all 4 data types: orders, customers, products, addresses
	- type is hash key (and date of creation up to day?)
	- id is range, so default sort is by id
	- local secondary indexes for other sort types, but there is a limit of 5 per table (need to be added at creation time!)
	- dates can be in ISO 8601, these are actually sortable
	- sort keys need to be scalars on the top level of an item
	- relevant attributes for each data type will need to be projected into the indexes, but indexes introduce write costs ()

	- only tables with Local indexes have the 10GB limit per partition
	- we will be doing more writing then reading from the database