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!
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.
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.
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 firstname.lastname@example.org 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"
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.
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.
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.
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.