Michael Gingras mcgingras

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.

This is a plain-text version of Bret Victor’s reading list. It was requested by hf on Hacker News.

Highly recommended things!

This is my five-star list. These are my favorite things in all the world.

A few of these works have had an extraordinary effect on my life or way of thinking. They get a sixth star. ★

ANNOUNCEMENT

I have moved this over to the Tech Interview Cheat Sheet Repo and has been expanded and even has code challenges you can run and practice against!

\

The Complete Guide to Nested Forms in Phoenix

I recently spent some time dealing with nested forms in Phoenix. Nested forms are great when you want to create multiple database records in a single transaction and associate them with each other. I am new to Phoenix and really struggled to find any resources that helped me with my specific problem. I decided to document what I learned in the process in hopes of helping others that are new to Elixir and Phoenix.

Here is my attempt at a one stop shop to learn everything you will need to know about nested forms. If you would like to view the GitHub repo you can check it out here.

Thanks to Heartbeat and Jose for excellent blog posts on nested forms. Also shoutout to Josh for showing me some examples at Ruby

	function go() {
	var userId = prompt('Username?', 'Guest');
	// Consider adding '/<unique id>' if you have multiple games.
	var gameRef = new Firebase(GAME_LOCATION);
	assignPlayerNumberAndPlayGame(userId, gameRef);
	};

	// The maximum number of players. If there are already
	// NUM_PLAYERS assigned, users won't be able to join the game.
	var NUM_PLAYERS = 4;

	// connect() is a function that injects Redux-related props into your component.
	// You can inject data and callbacks that change that data by dispatching actions.
	function connect(mapStateToProps, mapDispatchToProps) {
	// It lets us inject component as the last step so people can use it as a decorator.
	// Generally you don't need to worry about it.
	return function (WrappedComponent) {
	// It returns a component
	return class extends React.Component {
	render() {
	return (

	All actions are performed in Terminal.app.

	1. Install Homebrew http://brew.sh/

	2. Install Jack (route audio tool) http://jackaudio.org/. Current stable version from official website doesn't work with
	MacOS Sierra (I use 10.12.3) so you need to download beta version from there https://yadi.sk/d/JwT10b7v3Dm5yy.
	After installing reboot your computer.

	3. Install Darkice (audio streamer) via brew.

	#!/bin/bash

	POST_INIT_SYNC_DELAY=60
	POLL_DELAY=60
	STALL_THRESHOLD=5

	if [ -z `pidof btcd` ]; then
	echo "Starting btcd"
	nohup btcd &
	sleep $POST_INIT_SYNC_DELAY

	pragma solidity ^0.4.11;


	/**
	* @title Ownable
	* @dev The Ownable contract has an owner address, and provides basic authorization control
	* functions, this simplifies the implementation of "user permissions".
	*/
	contract Ownable {
	address public owner;