To be fair, the portable devices are not yet monitoring all conversations due to battery life constraints. If it were a wall powered device, I would be very wary of it, but until then it seems highly unlikely it can achieve that behavior and not drain the battery in a noticeable way.

Well two of the three mentioned (XBox One & Amazon Echo) are wall powered devices so I am not sure of the point you are making?

You could use the conky-cli build (without the X dependency). You could then run it and pipe the output into some file that you serve statically. Hmmm may spend some time investigating.

To follow up with this. You could add `conky -c json.conky | while read json; do echo $json > /opt/http/monitor/info.json; done` to your start. Then just static serve the `info.json` file and it should update at whatever interval you set for conky. No dynamic execution though (hard part is that lack of interaction).

Great read! Upon finishing, the two sides seem to be opposite solutions of a good problem (that is getting a non singular path to guarantee code quality). It seems that the best solution is a mixed approach. Using pairs to gain the benefits of knowledge sharing and sort of check ups (that is having a second pair of eyes to achieve the intermediate commit/review issue). But also using a large amount of solo coding with code reviews to ensure overall quality without missing out on the non-pairing types.

Has anyone ever tried a balanced approach like this? Such as spending 2-3 days each week pairing on a part of a project to help with knowledge sharing, best practices, or possible bad paths, and then the rest solo coding with some final code reviews?

Also, what is the best form of code review? Is it having a single developer be assigned to perform a code review for each pull request or for it to have some gestation period for crowd comments to come in, or even some voting quota/discussion until a simple consensus is reached? There seems to be some room for a variety of time/quality trade offs (in theory, more eyes == higher quality, more time).

I am curious if this has any relation to their recent acquisition of Braintree Payments. If they are instead using Braintree as the payment gateway, it could work out very well for the participants.

Reminds me of this: https://news.ycombinator.com/item?id=6455951

I also like using argparse. Nice utility library to "power up" helpful scripts.

Argument parsing is an essential utility and part of the standard library in all major programming languages, though. Dating back to getopt becoming a standard in C (or earlier?)

Or do you find Python's argument parsing to be especially notable for some reason?

For a language whose motto is "There should be one - and preferably only one - obvious way to do it", Python has at least four ways to handle command line arguments out-of-the-box:

* sys.argv

* argparse

* optparse

* getopt

There are, of course, additional third party modules (like opster) that also handle arguments.

sys.argv is part of the interpreter. The other three are abstractions over it.

optparse is deprecated (kept around for obvious backward-compat reasons)

getopt is just a different API for people who feel more comfortable with C's getopt API and don't want to learn something else

argparse is the CLI option parser for the future.

tl;dr: There is one way to parse command line arguments: sys.argv. But there are a few abstractions of doing that available in the stdlib.

Is getopt part of the C library? I think it only is POSIX, not C.

My friend that works at Motorola says there were frictions in having Google brand their own company's flagship phone as a Nexus device. Probably a lot of hard feelings still between Google and Samsung (among others).

Well it came out with the latest one (the CF exploit) that they were gagged on it when the FBI got involved. They eventually came out about it when the gag was removed, but only so much. When the FBI gets involved, usually the transparency get tossed out the window, at least if the company is not one of the giants.

It is more a combination of the small and vocal user base and the message it sends to them about Google being open to cutting any product that has a usage they don't think is significant. Those people who see Google cut a product that they have adopted into a regular usage will probably add an asterisk to any recommendation for adopting a new Google product. There is no certainty that the lifespan of that Google is dedicated to that product. With the shutting down or Reader, it sends a clear message that almost no product of Google's is safe and that we should all be wary of what of theirs we adopt into daily usage.

> cutting any product that has a usage they don't think is significant.

Curiously, some products that are moribund for more time still alive (e.g. Orkut).

Orkut is big in Brazil and India, so it makes sense that Google wouldn't kill the only social media platform they own with an actual mainstream userbase (modulo YouTube).

LOL, check out http://www.bonkersworld.net/usual-suspects/ by a googler.

nothig else to add , you sum it up perfectly.

This is something I view along with the "Ship it" idea. When I work on any project, I try to think of what the minimum is for the project to reach the real alpha stage. Where it is at least usable. Only then do I begin to entertain the various notes I have made on additional features or details.

I always go back to the sentence: "The best camera is the one you have". Finishing something and getting it out, no matter how much it lacks in terms of features, is important. The best way to finish is to keep it simple (or small).

Interesting idea, the interaction would get very difficult with more pictures in the stack. Also lacks a way to work in mobile. But you are really onto something here, would be interesting to see how this can be improved!