We use it for a few things. We use it internally for a few dashboards because it’s actually really nice to have real-time dashboard data with Firebase. We also use it extensively for live order updating. For example, when a shopper is picking your items, you'll be able to go on your order screen. There will be live showing like found or not found or whatever. You'll have live position updating of your shopper on the map. You will have live information of the status of the order like “Nicole is now picking up your order,” and all these kind of things, so you don’t have to reload the page or pull or anything. Just live updates happen natively through Firebase API, which is nice.shiftb
Trello and HipChat for coordination...Trello allows the entire company to have insight into what the developers are doing, they can contribute and comment about things versus if we used GitHub Issues, and we’d all need to have accounts have tons of people that don’t need to be on our GitHub account. There's no reason to manage them all there.shiftb
So before, we were having … not a huge, but we were having a fraud problem where people were placing orders, and they were getting fulfilled even though they were very obviously using a stolen credit card. So we started using Sift, which basically, we send Sift a collection of signals from users, so like they added this item to the cart. They tried to add a credit card, but it failed. They added this address and then they submitted. So we send them the collection of signals, and they run machine learning on those signals and send us back a classification of the user, and we use that as one of our elements to decide if we should fulfill that order or not.
So that's all happening in real-time. Without human intervention, you can tell. If they have a very high Sift score, you can say, “This person is clearly fraudulent. They’re using credit cards from six different places and ordering only Patrón.”shiftb
Yeah, so we use GitHub, and we basically use a variant of continuous deployment where when anyone merges in a feature that they’ve finished with, they ship it immediately, and we bundle it up as a build pack and send it to all of our EC2 servers... Any developer on the team can trigger a build and deploy at any time. So on a given day, we probably deploy 20 or 30 times to prod.shiftb
The very first version of the search was just a Postgres database query. It wasn’t terribly efficient, and then at some point, we moved over to ElasticSearch, and then since then, Andrew just did a lot of work with it, so ElasticSearch is amazing, but out of the box, it doesn’t come configured with all the nice things that are there, but you spend a lot of time figuring out how to put it all together to add stemming, auto suggestions, all kinds of different things, like even spelling adjustments and tomato/tomatoes, that would return different results, so Andrew did a ton of work to make it really, really nice and build a very simple Ruby gem called SearchKick.shiftb
We liked a lot of things about Heroku. We loved the build packs, and we still in fact use Heroku build packs, but we were frustrated by lack of control about a lot of things. It’s nice to own the complete stack, or rather as far down as AWS goes. It gave us a lot of flexibility and functionality that we didn’t have before. We use a lot of Amazon technology.shiftb