dajobe

There is also the (impossible to google) https://github.com/harelba/q that lets you SQL over CSV and is unix pipeline friendly.

Things it doesn't support: symlinks, posix acls (xattrs). The first one makes it a certain failure for archival use. The hardcoded link to an external crypo service keybase makes it a failure for long term use.

Even better, it's from the future: Posted 25 Mar 2015

I liked the comment: "I’m a big advocate of remote work culture even if nobody works remote."

That really works: respect people's time even if you are in the shared, no-cube, open office world.

There's no way to point from one part of a JSON doc to another without inventing a terminology or convention for marking the start (anchor) and end of the arc (href). People use 'id' for one end but there's no way to say a json value is actually a reference (href) not just a string. XML has that built in (ID IDREF) and so does HTML, but I didn't say XML was better, I said JSON sucks at markup and graphs. JSON's handy for serializing trees of data with no loops.

You have good taste, since I invented Turtle. To keep this on topic, I've been using JSON for data web APIs since that's what it's best at. It sucks at: markup and graphs of course.

How do I vote this polling crap down? Pointless and subjective and if this was stackoverflow, would be deleted.

I partially agree with a slight modification. I write a lot of free software / open source software. This relies on copyright of course, to enforce the freedoms. I don't want an onerous registration environment, but if it was "copyright terms to 4 years after last publication without registration" but registration with a fee after that. So if I continue to make the software, it gets the copyright and if I get bored, it turns into PD - and that's fine.

This article / talk is a collection of relatively random python things of which only a few are unarguably good advice such as not using deprecated terms or checking for exact types. The rest is not a good basis for pythonic best practice that I would recommend.

It is not open sourced, at least not yet. Putting something on github generally means it can be openly distributed. The source code says "all rights reserved" and there is no license file.

What a pathetic rant. I was totally not surprised that day #1 of a total codebase rewrite would not have all the features of the old version. AVOS hinted enough at this too. At least they are innovating and responding to users. Having said that, I do hope 'networks' returns since that's the feature I miss, so far.

I'm rather skeptical at this stage; the article could have been titled "Google+ could be the social backbone" but that isn't so provocative. When the APIs appear and we see how easy it is to get data in AND out via them, then it'll be clear.

That's true, but it's still an interesting read, it hasn't really dated.

I assumed the submission software would notice dupes of existing stories and point at them. The URLs seem the same.

Looks like it is still ongoing: http://dockets.justia.com/docket/massachusetts/madce/1:2009c... reports news from Nov 2010. Can't decode the legal language.

I submitted the blog post, I am not the author of it.

It also doesn't explain how if they don't trust EBS they are going to replace their MySQL on dedicated servers. Sounds like they are considering the Cassandra route. Which gained a query language last week.

True, and it isn't the full story of system dependencies. Data dependencies aren't really shown here and they are also tricky, although Cassandra is the the primary ("source of truth") for most things. So for example, if a user does something on the site such as Digg a story, you mainly write Cassandra (several times) but in some cases have to write Redis, as well as flush some caches. Meanwhile async jobs can be writing to HDFS and ultimately MySQL.

Boy, a lot of questions. I already mentioned that the different stores have different features. I wouldn't see Redis or Cassandra replacing each other for anything. HBase is a potential replacement for bigger MySQL-like things such as big joins across all user data, actions. M-R inputs are logs in HDFS, copied from scribe. RabbitMQ isn't involved in logging those.

You think this diagram is complex? You should see the one that describes the full details. Things I missed out include the tiny Java bit. No Ruby though.

I'll see if we can include some figures in tech posts that follow.

Thanks, we hope to go deeper in areas people are interested in. Let us know.

I'm the author of this article which was about the technology we use. Your comment doesn't seem to be about tech at all.