zachanker

Hah! Glad to hear some people got some use out of it. It was definitely a huge pain to work through all of that.

Real Estate agents post their own listings on Craigslist.

There are companies who provide the fancy HTML templates you see real estate agents use, but Craigslist doesn't allow automatic posting of listings.

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.

[1] http://en.wikipedia.org/wiki/Real_Estate_Transaction_Standar... [2] https://github.com/zanker/ruby-rets [3] https://github.com/zanker/ruby-rets/blob/master/lib/rets/htt... [4] https://github.com/zanker/ruby-rets/blob/master/lib/rets/htt... [5] https://github.com/zanker/ruby-rets/blob/master/lib/rets/htt...

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.

http://aws.amazon.com/s3/pricing/ (standard storage pricing hasn't been updated yet)

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.

Seems that they do http://www.videolan.org/vlc/download-ios.html unless it's a different iOS version of VLC than the one on the app store that was removed.

In addition they changed the private repo indicator so it's no longer a very obvious yellow background, but a single label that says "PRIVATE".

It was actually useful to have a very obvious indicator that your repo was private and nobody else could see it.

It would be nice if "Plans & Pricing" on https://www.mybalsamiq.com/ actually took you to http://balsamiq.com/buy?p=myb rather than http://balsamiq.com/products/mockups/mybalsamiq#pricingtable and then having to click another "Plans and Pricing" link.

Looks cool though, will definitely have to check it out.

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.

The invites weren't actually that bad, nothing like Gmail was initially. Most (Everyone?) had unlimited invites for a good 4-5+ hours.

You could actually get in if you refreshed the main page, they seemed to let people sign up through some magical formula.

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.

[edit] Added voice backup note.

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.

From the sounds of it:

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.

You can specify whether or not to allow chats from anyone, or only those on your contact list. Can't recall what the default is on OSX.

This was about 5 months ago, so it's possible they drastically improved it in that time (although it doesn't sound like it). But I ran into the exact same issues.

Debugging was a pain because of you were writing JavaScript rather than Obj-C and the line or file on some errors were on were entirely unhelpful.

Performance (which you don't notice in the simulator) is poor. I was working with tables on iOS, even after cutting the app down to using 10 rows, people noticed a lot of lag on iPhone 4s (and it was unusable on a 3G or 3). This was with the only scroll events being a scroll position check suggested by the KitchenSink demo they provide.

Entirely possible this was something I missed, but while it says cross-platform, you don't really get cross-platform. The difference in UIs between Android and iOS means you're going to be writing quite a lot more code to actually get an app that works on both Android and iOS.

[edit] syntax

You don't mention it in your question, but what is your experience? You say you want to work at an awesome startup, but do you have projects (such as websites) or anything you can reference to prove you know what you're doing?

San Francisco is a great place, but you're already going to be fighting against quite a lot of people with more experience. Unless you some impressive projects to show, finding a startup who is going to take a risk on a 19 year is not a good bet to make.