I worked at Placester for a couple of years and built the system that imports data from real estate agencies. When I left last year, we had coverage with around 90% of the MLS's in the US. Most of what you say is right, but some clarifications and context:
You don't need to be a brokerage to get access to the MLS feed. Each MLS has their own policies for how you can display the data, what logos, size and text needs to be shown on the page with their listings though. Which means it unrealistic to build Zillow/Trulia site off of MLS data. Placester builds them for individual real estate agents which is significantly easier for keeping the MLS happy.
Some MLS's are great and will give you access to the data without much hassle, others are not and you have to pay a lot of money. Even once you get access, you will get almost no technical help or useful documentation on integrating with them. Since MLS's are almost never related, you still need to talk to 300+ different companies in order to get coverage of the US.
There is a standard that most MLS's follow for their data, which is called RETS [1]. I would say about 80% of MLS's use RETS, the problem with RETS is that it's a standard in the same sense that CSS was a standard 10 years ago. The original library I wrote for RETS [2] is open sourced, and is littered with examples [3], [4] and [5] (to name a few), of inconsistencies across RETS servers.
If you can work through all of that, you're golden. It took us about 1.5-2 years to get the experience of seeing how MLS's work in order to simplify the integration process down to 1-2 days, with RETS typically requiring no (or minimal) engineering work.
That's what errbit is for. You only have to use the Airbrake libraries for reporting the errors, and errbit hosted locally collects/notifies/displays them.
If you already integrated with Airbrake, you just have to reconfigure the host it reports to, to your own errbit server and it'll swap everything over from deploy tracking to error reporting.
Errbit is an active project, https://github.com/errbit/errbit, and error reporting libraries don't tend to need a lot of maintenance.
Since you're only using 1GB, you would pay 9.5 cents for the storage a month. Then about $122.76/month for the bandwidth since the first GB is free and it's $0.120 per GB afterwards up to 10TB.
Making it around $122.855/month total. This change doesn't really reduce your costs by much since most of it in bandwidth which hasn't changed.
Started to use Stripe recently for a project and have used Braintree extensively for work. Your comparison is spot on.
There are some small differences such as, Stripe can send credit card details through AJAX to their servers so they are never sent to yours. Whereas Braintree uses Javascript encryption to do it, so the encrypted values are sent to your server. But I haven't seen anything that only Braintree supports yet.
Tradeoff with Stripe is that while you get a much simpler API, it (likely) will cost you more than Braintree depending on scale and what cards are commonly used.
The aggregation framework is meant to fill a gap between SQLs SUM, COUNT, AVG, etc without requiring a full map/reduce. The Hadoop integrations are unrelated and are just a nice little bonus that they added.
Even with the iteration count, SHA512 is not exactly meant to be slow. They're taking the long way around to try and get the security of bcrypt... without just using bcrypt.
It was crypt-MD5, the fact that they call it MD5 with salt is generous at best. They seem to have made the decision to move to crypt-MD5. I don't really have any faith in their ability to secure the servers.
I actually had the same concerns, but after going through it they give you two ways to solve that:
One is you can set a backup phone to use to get into the account, it can even be the same phone you have the authenticator on, so as long as you have the same number, you can access it. The backup phone option can also work with landlines through voice.
They also allow you to print out a set of numbers you can use in case you lose the authenticator to get back into the account.
Yes, there is support for stream parsing of JSON. I haven't tried it myself, https://github.com/lloyd/yajl is one example, which has various bindings in other languages.
Reiterating the point the blog post makes, but: It's very very easy to structure the same data in different ways in XML. While JSON has the same issue, it's a lot harder to do and you have less flexibility in making bad storage decisions.
You are absolutely right on walking the structure. JSON just tends to be easier (in my experience), even when working with XML libraries that make it less of a pain.
While SimpleXML gives you an easy way to walk the tree, it still requires you to actually do it. All 3 of those examples would require slightly different calls to SimpleXML to handle.
In theory, it just slows it down so rainbow tables are ineffective (not that people need them anymore), and it requires you to brute force each password than brute forcing one password and then checking it against everything.
In reality, it's all MD5 and the passwords were leaked to a community who are running tons of GPUs to brute force hashes. So it's kind of irrelevant.
You generate (on Braintree's site), a RSA keypair and you use the public key and JS library they provide.
You call a JS method on the fields you want to encrypt like credit card number and CVV, and it encrypts it using the public key.
When an user submits a form, you send the encrypted values to your server, and then you pass them off to Braintree's API as you normally would.
Braintree then decrypts it on their end using the private key. If you set it up properly, you are never aware of the users credit card number, CVV, etc.
It prevents your servers (if it's setup properly) from ever knowing the credit card details. SSL only prevents somebody from seeing the data as its sent, your server will still know the plaintext details.
It doesn't fix the fact that if your JS or the forms itself are compromised, credit card details can be leaked, but the transparent redirect setup has the same issue anyway.