This is a bigger issue than can be thoughtfully discussed in an Internet comment thread, but if you are interested, I highly recommend Amia Srinivasan's "The Conspiracy Against Men" for a thoughtful, nuanced, and comprehensive examination specifically of "believe women" as a slogan, and more generally of the way our culture navigates accusations of and regulations around rape and sexual assault. It is the first essay in her book "The Right to Sex."
I find the gesture choices interesting and suggestive of future directions for interaction with wearable devices. Their help article on gestures lists the four supported gestures with GIFs. One detail worth noting: "We recommend using four fingers when performing gestures. Note: To avoid unintentional activation, the jacket will not respond to gestures performed with a single finger."
Hi there, I'm one of the engineers who worked on AT-AT.
Shapefiles are useful when we export data, but because we want to give our cartographer the ability to continually edit neighborhood boundaries, we store these as polygons in PostGIS. Hope this addresses your concern. Feel free to ask for further clarification.
Hackpad's search functionality is pretty good at ensuring that people find what they need. We do also maintain a Table of Contents pad, which serves as a central place that links to all our canonical content; this helps people find what they need by browsing. This ToC pad is pinned to the top of the Engineering Wiki collection.
One guiding principle we've followed is to favor long wiki articles so that it's easy to see a list of everything you can access from that one Table of Contents. Each pad is then well-organized so that you can search within the article to find what you need. We used to have lots of articles that each addressed just one thing, but that made it hard to locate the right article when you needed it.
Sometimes content gets duplicated, but we just clean that up when we notice it. So far it has not been a big deal.
Airbnb Engineering currently uses Hackpad (https://hackpad.com) for this purpose, and it's working very well. We previously used Google wikis and GitHub wikis, but the poor editing interface was enough of a barrier that few people contributed wiki content, preferring instead to send emails or just explain in person. Hackpad changed the game by making content creation dead simple. In addition, it has good search and organization capabilities.
In addition to canonical, long-lasting wiki content, we also use Hackpad for RFCs to the team (e.g. to gather opinions on the design of a new system or API) and checklists for ops events (e.g. migrating an RDS database to PIOPS). Hackpad's real-time collaborative nature works especially well for these use cases.
Whatever you choose, I submit to you that the most important thing is making it extremely easy to contribute content to that central knowledge repository. The ability to organize and format content nicely doesn't mean much if it's cumbersome to add new content in the first place.
Actually, package managers are core to most Linux distributions! That's been the case long before there was ever Homebrew for OS X. You should almost never have to manually install from source if you're installing anything relatively well-known.
If you're Fedora or Red Hat, you should use yum, which a tool for the RPM package manager. Here is a list of basic yum commands: http://yum.baseurl.org/wiki/YumCommands
You can find more explanations/tutorials if you search using queries like "apt tutorial ubuntu" or "yum tutorial red hat." Hope you get acquainted quickly!
This might raise the question: Why make Homebrew work on Linux if other package managers exist already and work really well? I can think of a couple reasons: 1) fun experimentation, and 2) the fact that Homebrew formulas are Ruby code, which many people find more approachable to write than APT or RPM packages. My opinion is that it would be fun to see Homebrew on Linux, but it's not necessary given that existing package managers work very well, and many developers are willing to do the work of packaging for the rest of us.
We do use a Rails engine for one of our components, but this isn't something we've explored a lot (or at least, I haven't personally; maybe some of the other Airbnb nerds will step in with their own thoughts). Even so, I don't see this as a good long-term solution for our architecture, mostly because not everything we do is Rails -- we currently run JVM services and Node.js services, for instance, and we'd like to keep things flexible in the future so we can always pick the best tool for a particular use case. Our routing service should be able to handle all those needs.
Our service discovery system is indeed a layer that sits between ZooKeeper and the application. But it's also pluggable -- that means that you don't have to use ZooKeeper as the system that tracks which service nodes are available; you can use something else, and write a plugin for our service discovery system that will talk to that instead. So it's not necessarily a layer on top of ZooKeeper, although we certainly use it that way.
I don't want to say too much about the technical details yet since we're still rolling it out in production and may change some pieces before it's released. Also, I'm not one of the primary authors and don't want to steal their thunder. ;) But yes, we do plan to open source it once the code is fairly stable (and once we have some time to jump through all the usual hoops of open sourcing code), and then we'll do a detailed post about how it all works. It's really cool and stunningly simple.