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.
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).
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.
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.
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.
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!
I disagree, jQuery is more of a compatibility layer. Think of it (in a way) like an ORM for various SQL backends. They allow you to change between different SQL implementations without needing to learn the various nuances of each engine. The same can be said for jQuery, allowing you to modify classes even though browsers implement that DOM property differently.
I actually attended the talk this is from, the concept of recipe writers vs abstractioners is not aimed at the actual developers but at the tools and how they are developed. His idea is that the tools should be built around aiding developers in their need to abstract the data (Bret Victor talked a lot about this as well).
It isn't the information they can view, it is the things they can do impersonating you. Any application installed on your phone can probably access the two authenticating pieces of information. Then they can impersonate you in messages to, say, your parents and say something like "Hey mom, I need to order something, can you send me your credit card?" and then your mom, under the illusion that WhatsApp is secure, will send it right over.
You may like dwb[1] It uses webkit and handles what you mentioned. Written in C++, so you don't get the Haskell learning part, but it doesn have the javascript extensions thing (albeit not fully finished yet).
While this is (from my experience) incredibly inaccurate of the programming community at large. My fear is that it will encourage a perception of people looking for a career to embrace this stereotype. People who read this article may think "This is awesome, I definitely want to do this!" and a new wave of people who think that "brogramming" is the norm will begin to seep into the industry. Maybe the numbers will not be that much and it will allow a more diverse culture.
Oddly, in the age of the internet, it is easier for someone to do open source at least part of the time for their employer. With the internet, a lot of the money for web based companies is not from the software itself, but the services the software provides. This allows for the company to open source a large chunk of the code base and still make money to pay the developers. (see things like 37signals/RoR)
I use a Macbook Air (Mid 2011) and run Arch Linux on it. Works fine, only thing that doesn't work is the Thunderbolt port. I picked the Air because the model was on its second year and had a history of people having Linux run on it. The touchpad works fine with xf86-input-mtrack, which lets you customize some of the finer details on the trackpad.
... Just my two cents.
I think the biggest thing he emphasized is the fact that you can never be "The Best Programmer" because there is always something to learn and ways to grow. That is probably one of the keys to a good developer, they know that there is still plenty for them to learn.