Hacker Newsnew | comments | show | ask | jobs | submit | cubes's comments login

Congratulations Todd and team!

-----


Wait, what? You didn't take AMT into account? Because I have colleagues that AMT has nearly bankrupted, and who spent years having their wages garnished by the IRS because of it.

Feel free to edit your post so as not to send people to the poor house.

-----


I lean toward the 13" Air. My current work laptop is a 15" Macbook Pro, but I have an Air at home. If you don't need the larger screen, which I don't because I plug into at least one extra monitor most of the time, the Air is a nicer package. Less to lug to and from work. The other caveat is that, if you need to run multiple development virtual machines for testing, the 4GB memory max for the Air is somewhat limiting.

-----


I've been considering a 13" Air for a while now - incidentally the one advantage of the 13" Air over the slightly more powerful 13" Pro is the screen resolution: 1440x900 on the Air vs 1280x800 on the Pro. Probably not a huge deal if you plug it in to a monitor a lot but I'd be going for the Air for portability!

-----


My current work laptop is a 13" air. For non-compiled development (e.g. JS or other interpreted languages) I find the slower CPU of the Air and limited memory (4GB) plenty sufficient.

-----


The SSD and the screen make it for me.

I've also got a new Mac mini with a considerably faster processor and twice as much RAM, but the little hard drive in it makes the mini seem slow as molasses after getting accustomed to the SSD in the Air.

I can't go back to hard drives as my booting device.

-----


You're also missing the fact that joining an early phase startup carries non-trivial risk, and part of the reason early equity grants are large is to compensate for the risk one assumes by joining.

-----


It's a potentially neat idea, but keep in mind that many people already use their email for such a purpose. Rather than a specialized app for managing and tracking pitches, consider building something that integrates into mail clients ala Rapportive?

-----


SES is extremely easy. Unless you actually care about deliverability. Deliverability on the modern internet is hard. SES does not handle this. If Mailgun handles deliverability well, that alone is worth the price. Making it programmable is awesome.

-----


Amazon implements trust-based dynamic throttling and only allows verified email addresses. I don't think anyone else does both.

Where's your evidence that anyone has better deliverability than SES?

-----


Nobody can claim to sell you "better deliverability". It largely depends on 2 things, they are easy to understand:

1. Infrastructure. A lot goes into this, and you can Google what needs to be done, and do it yourself if you have the time.

2. Content quality. If your recipients keep flagging your mails as spam, nobody will help you - that's your responsibility not to spam people.

Myriads email sending services do #1. Mailgun, among many other things, does that too. Plus, we can give you a completely separated, dedicated setup where your reputation won't be affected by other senders (something SES can't promise you).

But in the end, you need to send something people want to read. Saying "email company X gives you automatic deliverability" is a bit like saying that "hosting company Y gives you automatic PageRank" :-) Yes, your emails will be 100% solid on protocol/format/rate level and the IP you're sending from is watched, but you'll be taken down if you're spamming.

Hope this helps. And if you need assistance regarding deliverability (on your own server, or with Mailgun) - shoot me an email at ev@mailgun.net BTW, this mailbox is hosted by Mailgun itself. see? we're eating our own dogfood here!

-----


>"Plus, we can give you a completely separated, dedicated setup where your reputation won't be affected by other senders (something SES can't promise you)."

Ahh, so you're using a different IP / subnet for each customer, then? With the internet running out of IPv4 space, I think that companies that do this kind of thing should just have all their addresses revoked. Same goes for "SEO web hosting"

-----


Eventbrite is hiring in San Francisco. It's a fun place to work, and we've got lots of openings: http://www.eventbrite.com/jobs/

Email cubes@eventbrite.com if you're curious.

-----


What do you mean by large scale? The first San Francisco event featured 20 trucks. The most recent Brooklyn one, which is where it originated, had 30.

-----


I meant in more places, e.g. Chicago. This is the first time I've ever heard of this. Is there a site where I can check the schedules?

-----


It's kind of organized ad hoc. If you're interested in putting one on, I'd suggest contacting the organizers. :)

-----


While luigi's statement is a little extreme, I think the gist is right. Yes outsiders can offer advice on a system, but it's really difficult to offer sound advice without specific details of the system. Perhaps outsider advice shouldn't be dismissed outright, but it ought be taken with a grain of salt.

-----


I very much agree that the devil is in the details, and the largest detail here is how Foursquare goes about calculating badges. So without knowing that the article can't fully evaluate alternatives. That has less to do with the author not being an engineer on Foursquare's team rather Foursquare not detailing the calculation. Maybe on Riak map/reduce is fast enough and Foursquare can shard by checkin, which would be much easier to balance.

Maybe they should just implement their own sharding based on user activity. Maybe a few SSD drives on their Postgres server would solve they issue. They through the issue out there, if nothing else works tell us why.

-----


Some informative links, in case you haven't seen them already:

* http://www.quora.com/What-caused-Foursquares-downtime-on-Oct...

* http://blog.foursquare.com/2010/10/05/so-that-was-a-bummer/

* https://groups.google.com/group/mongodb-user/browse_thread/t...

Someone on this thread suggested that Foursquare's performance problem is related to the calculation of badges. I'm not sure where this idea came from. I haven't seen any mention of the issue being related to badges in first or secondhand sources.

That said, Mongo DB's map/reduce operation would not be a reasonable solution at this time. Mongo DB's map/reduce performance is, at present, somewhat lacking because it runs via the javascript engine which is currently single threaded. I know there are plans to improve performance of Mongo DB's javascript engine by switching to V8, but I don't know if V8 is multithreaded.

Often design decisions that look bad in hindsight get baked in early. By the time you realize that an alternate design would yield better performance, there may be too much data to migrate so you just have to live with it.

-----


harryh mentioned it here: http://news.ycombinator.com/item?id=1769909 Computing the badges online (ie at each checkin time) requires having the whole db in ram for acceptable performance.

-----


I am not sure if badge calculation is the bottleneck. Foursquare did say the calculation is why they have to keep everything in memory though. I just assumed that they sharded by user to keep all of the user's check-ins in the user document and that they are doing calculation with that set of data.

-----


I find this sort of uninformed armchair analysis to be unfulfilling.

-----

More

Guidelines | FAQ | Support | API | Lists | Bookmarklet | DMCA | Y Combinator | Apply | Contact

Search: