jasonmccay

Yes! The ability to be outside, pull out your phone, and get an almost-to-the-minute awareness of when it was going to rain felt magical, right out of Back to the Future 2. I used this countless times.

So much of weather forecasting, at that time, was about trends and probabilities. DarkSky was about events, certainty, and action.

It was truly ahead of anything else and forced a new standard.

For me, in college, it was Age of Empires. We'd have late-night LAN sessions with roommates and friends and when I eventually crashed into bed, my brain would continue strategizing for battles, determine necessary resources to mine, etc.

Interesting ... curious what the replacement cost of these membranes are as compared to installation and ongoing maintenance of wind turbines.

Also, as always, curious how having these membranes in the water would affect the local ecosystem.

If Deis was that valuable, one could assume that EY agreed to this arrangement because they are low on cash and needed the money.

How often is a company, in effect, acquired twice?

Perhaps. My experience (a data point of one) wasn't like that. Why would you risk team productivity until the deal is signed?

If you are interested in the Jekyll / Github approach, you ought to check out Octopress (https://github.com/imathis/octopress) by Brandon Mathis.

It includes all the benefits of this approach, but with a nice out-of-the-box theme as well as useful helpers to make the blogging experience much better.

This may be true, but it also makes the common assumption that your time (or the time of your team) is somehow worth $0 dollars. But, I imagine that you would be the first to say that your time is worth much more than $0 dollars.

Put another way, hardware stores sell paint and paint supplies all day. Buying those and painting a room yourself is certainly cheaper, but it assumes you have the extra time to paint and don't mind you being the laborer. Hiring a painter costs more, but saves you a ton of time, energy, and elevates the level of expertise you are bringing to the job.

Getting started is one thing. The ease of how you maintain and grow is another.

You realize that was resolved 1.5 years ago, right? Also, it was a driver-level implementation. Comments like this make you sound more troll and less informative.

"Every single time we went from the 2-node primary site to the 3-node secondary" ... Can you explain what this means in terms of MongoDB?

Yes, this. It is really stretching it to say that you can effectively "game" on your TV when airshare'ing from your iPad /iPhone to your Apple TV. It sucks.

Sort of ... but there are pretty serious limitations.

1. You are locked into Rackspace as your provider. MongoHQ provides multiple cloud providers.

2. They force you to shard. This increases operational and application complexity ... and may not offer any real advantages for the amount of data that you have.

Isn't this just a link to an advertisement?

Considering MongoDB has only been around for the "last few years", I think it is maturing well. You are certainly free to call it the PHP of Databases, but there are a lot of developers that have learned to use it and are quite happy with it. Seems like most on Hacker News spend more time telling them why they are stupid than actually understanding the tool.

(Also, some guy by the name of Zuckerberg made a TON of money with PHP.)

Also, the tool is still in its toddler years ... and it is constantly compared to tools that have been around years longer (PG/MySQL). Comparing it to other NoSQL databases is just as silly (Riak, Cassandra) because they are completely different, have different constraints and are solving different problems.

There aren't better choices ... there are just different tools that are better for different jobs. It would be like looking at your toolbox and chunking everything but your saw or your hammer. Too many people are looking for the "technology to rule them all", but that doesn't (and shouldn't) exist.

People who swing hammers all day look at screwdrivers as the most confounding things. Why would you ever use a screw when you have nails?

Man, I need to go break the news to our customers that are successfully inserting millions of documents per hour (and their apps running nicely ... probably an app you have used) to inform them that, in all reality, they are "failing miserably."

They'd be shocked(!) at the news. ;)

Slower than Postgres ... ha.

Aphyr did the same "Call Me Maybe" posts for other databases as well, highlighting their shortcomings. MongoDB has issues, but other databases have their rough edges as well. It all depends on how you use them.

For a group of people that know nothing but hammers, screwdrivers don't make much sense. This feels often what these "bash Mongo" arguments sound like.

There is no silver bullet. Just flippin' understand the tool you are using and how to use it.

Th oplog is probably the most underrated feature of MongoDB. There is all sorts of neat/useful stuff that you can do with it. Using it in Meteor and with River for Elastic Search are just a small part of what all it can do.

Again ... you are jumping to conclusions. The statement did not specify when the person was put on leave.

This is really cool ... while all the YC partners are amazingly talented and giving, you were always the person to go to in the trenches ... wise beyond your years and extremely tactical in how you communicate.

Thanks for everything you've contributed to all of us.

Have you ever tried Screen Hero? We use that from time to time here and it works nicely.

Indeed ... Hipchat has proven to be a great way for our teams to communicate. Also, it creates a nice log of conversations for historical reference.

Secondly, Hipchat is a great central posting ground for all your apps, both internal and external services. The same apps that we have created to increase internal transparency on work being done are set to be relatively spammy in Hipchat, which allows the team to receive passive updates on activity with no extra work from individual team members.

Works nicely.

KTVU is borderline comical ... they were making wild assumptions that, even using basic logic and common sense, could be dismissed. I was really surprised how unknowledgeable they seemed.

Much better to just report what you know and not try to make up information (even just claiming it as conjecture). Online sources were far more valuable.

The guys at Tokutek are solving that problem with MongoDB. Pretty interesting stuff ... you should check it out.

I really like the term "schema-ish" and I think that most people probably want something like this. They will inevitably still have a defined structure for their data, but they need that extra bit of flexibility to keep the overall data structure simplistic and sensible.

I am curious about this. No doubt the Amazon small is quite the laggard, but as price and capability scale on each platform, I would be curious to know what the results look like.

Secondly, if you wanted to get truly accurate results, doing this same test over an array of provisioned instances would be good, as quality can vary.

Still, interesting information nonetheless. Really surprised how much faster Linode was than DigitalOcean.

Right ... this scenario is far more likely as, at the moment, it is very much in vogue for larger companies to snatch up the engineers around smaller, flailing companies that did not have enough revenue to sustain and could not attract funding to keep the engine running longer.

Many acquisitions that I saw this year were either starving engineers or soft landings.

Congrats guys on the big news. In the brief opportunity that I had to get to know them, they were incredibly intelligent and super-nice and helpful guys.

I sat next to Fred at Startup School a couple of years ago and his encouragement was a big reason that I decided to apply to YC.

Keep doing great stuff!

Yep ... in interacting with many developers, setups like this are almost commonplace.

You can also use the MongoDB Profiler to get a historical view of the performance of your queries and can easily separate out results based on scanned documents and query time.

http://docs.mongodb.org/manual/tutorial/manage-the-database-...