mlmilleratmit

Neat. I like the fresh take on validation. It’s not necessarily unique, but it may be cleaner / more efficient than previous attempts. The mixing of backend processing and the http layer reminds me of my CouchDB days. @stream seems potentially tricky to implement at scale but very useful. And a few nits here and there (eg maybe return a 202 instead of a 200 on accept), but overall pretty slick. Any numbers on performance and/or scalability in production?

Normalization matters. Well put.

Congrats! That's a big war chest to go to market.

Awesome news. Was very happy to invest. I wish this existed for onboarding when we were scaling Cloudant.

It's also popular to price a seed round (from 500k up, in my experience) using the "Series Seed" legal documents that are close to boilerplate now. As a founder turned investor, it seems that those docs could be streamlined into software easily. Most of the terms are standardized at this point, aside from board seats.

That part is, in my experience, vanishingly cheap if you're not doing high rate DB transactions. The whole thing could clearly be moved to other managed hosting providers or private servers, and I'm sure ultimately you can run a somewhat constrained version on the device itself. That said, launching in the cloud seems like the right choice temporally (time-to-market) and economically. Focusing (sorry) on building the actual device seems like a reasonable choice to me.

I think the pro is 'feed-able', wonder if that's it.

Take a look at the specs -- you can either vent them out a window or buy the air filter (which I'm guessing is a fancy charcoal scrubber, don't know for sure).

Good question for somebody on the GF team. My last company was Cloudant so my biases are pretty obvious.

This one I actually know -- biohazards depend on more than just wattage -- spot size, wavelength, pulse characteristics, etc, all go into it. I think you really compare them based on the Poynting vector. Disclosure: I'm a GF backer and am a card carrying physicist who had this question on his qualifying exam in grad school. https://www.rli.com/resources/articles/classification.aspx

Good question, I _think_ the ideas is the exact opposite -- you're not depending on Glowforge UI to be backed by a startups servers, the software runs on google cloud instead. Pros and cons, obviously, but I think the main pro is (like a Tesla) the machine's performance and usability can be improved without you installing any new software. As far as dependencies go, google's probably the best possible choice.

I ordered one, wish I could pick it up in person instead of paying the shipping. Particularly interested in seeing what one can do with just a pen and skipping the computer design stage...

Will give it a spin.

Good points.

Hey, that's a million times prettier. Maybe you could drop some of that UI goodness onto the public hind-cite dataset?

Good thought. I've been trying to think of how to do that without crawling the comments, too.

In our spare time, we're researching this dataset in detail. Here are some questions that we're interested in. Would love to hear other ideas and to have folks dig into the data. I think this dataset may be of interest to hackers, researchers and marketers.

1. Are the trajectories (e.g. rank vs time) for all popular posts of the same shape? They look ~logarithmic.

2. Are there identifiable clusters when you look in 4d space for rank vs points vs comments?

3. How does the impact of a post depend quantitatively on its respective cohort. I.e., what's a good model to normalize performance based on what else was happening that day?

4. What fraction of posts have comment threads that are "hijacked" by the first comment? Is their a quantitative way to find this, perhaps by looking at (2) above?

5. What are more detailed metrics to collapse "performance" of a post onto a single number?

6. How does performance on HN compare to reddit, etc?

7. How is the HN community different than other communities, if at all?

8. Given the time-dependent data, can we create a good estimator for the number of active HN users per day? Or can we at least create a relative ranking of the number of unique users between different days?

Actually, the majority of our servers have been on SL bare metal since ~2010.

Very cool. I like the way that you show 'means vs time' on the left panel and then you can dig into the actual distribution on the right panel. FYI, I think that, e.g., http://weather-explorer.com/history/country/US/state/WA/city... should read "Daily High Distribution", not "Average Daily High" or something. The mean trend line is on the left panel, and the right shows the the entire distribution. I'd be curious to see also what the 2nd and 3rd moments look like vs time, to see if the weather has an equal 'spread' month over month or if it tightens up for certain periods of the year.

Also, you need to drop in a full post with commentary, analogous to what you did with your "learning python" post. More feedback about tools, resources, learning sites, etc.

Sure, nobody claims that CouchDB is the first to have replication. MVCC was invented decades back, and hash trees have been around forever. I believe those two combined are compelling, and if you follow, e.g. risk, you'll see they're heading down the same path.

I agree with some but not all of what you write.

0) CouchDB will never lose your data. Period. Not many other stores are 'append only, copy on write'. If you're data is transient, you may not care about that, but many apps expect the DB to never lose or corrupt data. Take it down with 'kill -9'? no problem, it's guaranteed to be consistent on disk.

1) I think document DB's are as good or better than a key value store like riak. It's great to have the choice, at a later point in time, to reach inside your documents, build indexes, etc.

2) The biggest wart with couchdb from a scaling point is the single server, master-slave, and master-master. There is no dynamo style clustering, ala cassandra, risk, etc. We added that in our own stack in '09 and it's finally hit the Apache CouchDB repo in a refined state, you'll see it in Apache CouchDB 2.0

3) Finally, the biggest wart from a usability standpoint is the need to build materialized views. Ad hoc queries are painful. In Apache CouchDB most folks use Elastic Search in conjunction. In Cloudant we embedded lucene into each cluster node so you can do the the obvious things: 'GET http://...?q=name:"Mik*" AND age:[25 TO 34] & sort...'

There is indeed a deterministic but arbitrary choice of the "winner", but there is a big difference with other systems -- no data is discarded. The hash tree branches and both edits are saved. You can choose which branch of the tree you want to start editing, and you can listen to a feed for documents that have conflicting edits and resolve them according to your application logic. The real choice is to never discard data.

High level -- what's it like writing for windows mobile vs iOS/android?

Ask and you may receive. Stay tuned.

And jchris jumps in with the couchbase marketing, love it. You're right, though, about how rad it is that so many things speak the Apache CouchDB replication protocol. I'm eager to hear Max talk more about syncable because I thought that may be a more minimal protocol for sync than the full Couch dance.

I'm pretty syched to see developers taking on the interface of offline and f2f courses.

Nice work -- that's a hard problem. I've felt some of this pain as I helped Cloudant customers make hot migrations from mongo to into Cloudant. Your first two figures make it clear just how challenging hot-replications are (especially master-master), not to mention handling failure scenarios. For all of the great things about Mongo, there's something very awesome to be said for CouchDB's MVCC replication model. Glad to see that you're open sourcing those tools. Maybe they could be extended to make a MongoDB <==> CouchDB replicator.

can...not...wait

err, 'your', not you're.

I'm actually interested in a more technical discussion of you're experience using couchapps. Did that model of packaging html/css/js into a design document work well? How do you handle deployment? Did you get constrained by cross-site-scripting and our (Cloudant's) lack of CORS support?