Add style guide for order of properties in Android views

Alphabetized is pretty much the standard, but we felt that `id`,
`layout_width`, and `layout_height` should be listed first. `id` is
the property you care about most (if it is present), and should be
quick to find at a glance. `layout_width` and `layout_height` are
required on all views, and affect the layout of the view most, so they
should also be separated from the rest.
Add missing links to samples
Add "Product Review" protocol before "Code Review"

Our core workflow has been:

* Work in feature branch.
* Open GitHub pull request for code review.
* Make changes based on teammate feedback.
* Merge into master.
* Push to staging.
* Get feedback on the product in-browser from teammates.

This generally works well.

However, when something isn't quite right with the product
and the developer needs to make changes,
the feedback loop is too slow.

Fast-moving startup teams may want to blame code reviews for causing problems.
However, fewer or sloppier reviews lead to
problems like bugs and hard-to-change code.
We still highly value code reviews.

Our hypothesis is that the root problem is that the steps are out of order.
What if we performed "Product Review" before "Code Review"?

![Product before Code](http://f.cl.ly/items/1k2b2T1b3v2O1d0A0p3z/Screen%20Shot%202013-05-19%20at%204.57.03%20PM.png)

Moving "Product Review" before "Code Review" in our core workflow
can be solved in different ways.

The most effective is when [teammates are available in person.
However, that's not always feasible.

Many teams value remote work due to teammates' choices of
where they want to live and when they want to work.

In the absence of *always* having teammates
who are *always* available in person,
we have [experimented with approaches] for about 18 months.

[experimented with approaches]: http://botcave.thoughtbot.com/ssh-tunnels-for-sharing-development-branches-in-browser-development-platform-as-a-service-and-more

This pull request captures the conclusions of the successful experiments.
Rewrite `printf` vs `echo` guideline

If not passing options, including escapes, or including variables (which
may contain escapes), `echo` will work consistently across systems. It
should not be broadly avoided as this simple and safe use-case is
common.

http://unix.stackexchange.com/questions/65803/why-is-printf-better-than-echo
Add first guidelines for Ember
Remove the partial guideline

* https://github.com/thoughtbot/guides/commit/a2428be0f85fa30c0c30dba8d5843e86ff1163f8#commitcomment-8468894
Use `ENV.fetch` instead of `ENV[]`

It's easy to forget to set environment variables (e.g. `AWS_SECRET_KEY`) on
staging or production. Using `ENV.fetch("AWS_SECRET_KEY")` ensures that missing
environment variables raise errors instead of just being `nil`.

Heroku boots the app on deploy, which runs the app's initializers. Often,
environment variables are set in an initializer. This combination means that if
an environment variable isn't set, an error will be raised and Heroku will abort
the deploy. This means users can never see a version of the app without the environment
variables set.
Add Angular Best Practices

A first crack at some Angular best practices arrived at through a seven
month angular project and discussions with other teams doing angular
work around the company. I'm no angular expert, but these are practices
I can remember working well, particularly in the face of other options
that *did not* work equally well.
Prefer `reduce` over `inject`

`reduce` provides symmetry with our already-preferred `map`.
Additionally, it has a more intention-revealing name and is more
approachable for people unfamiliar with it. "I am reducing this array to
something". `inject` doesn't make the same sense.