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 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 always enthusiastic and knowledgeable mr. @jasaltvik shared with our team an article on writing (good) Git commit messages: How to Write a Git Commit Message. This excellent article explains why good Git commit messages are important, and explains what constitutes a good commit message. I wholeheartedly agree with what @cbeams writes in his article. (Have you read it yet? If not, go read it now. I'll wait.) It's sensible stuff. So I decided to start following the
// 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 ( |
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. ★
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; |
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; |