They said during the key note that they are lighter than many sunglasses. Many of the team were wearing them when taking orders as well. So they are trying to show off they are natural and easy to wear.
Brin also said they do a lot more than share and view video feeds, but it is tough to show. I imagine they at least replace your mobile phone and headset, at the minimum. Consumers gave up cameras for their new smarter phones, and this can be positioned as just an even smarter phone doing more.
The reason cloud streaming is so important is because wireless streaming from a device eats the battery alive. Amazon recently announced that battery and then price are the primary drivers for users buying tablets, and battery is amazingly import for phones as well.
Cables are a little iffy, a lot of non-techies simply aren't going to go plug their cable in to show off their pictures or music. A simple enough UI, though, can bring them in. Successful consumer mobile products generally prize being ridiculously simple because that's the only thing many people will use and media oriented, because that's the thing most people do with the smart part of their phones, nothing more.
Put me in as a nut job then. I've seen plenty of users who make no distinction whatsoever re case of characters in passwords. One day their password is working, the next day it isn't, and the organization ends up spending the custom care money to deal with it just because they started typing "af" at the end of their password instead of "Af" or whatever.
If you need more complexity in a password, better to just encourage them to use a phrase with the words being the individual complexity rather than the characters. Like it or not, we live in a world where 80% of end users can't turn their wifi radio on and off on their phone, and we need to make systems that are a pleasure to use for them.
Even if 80% of users don't use capitals in their passwords, the 20% who want that added security don't get it. Even if you believe this made-up statistic due to your condescending attitude towards "normal" users, the password should be case sensitive.
A (very stupid) alternative would be to notify the users that their password isn't case sensitive so that those who mind can use a more secure password.
The argument that "most" users won't be affected is absolutely negated by the fact that some are.
Blizzard takes a lot of steps to ensure your password can't be bruteforced. Even with the (imho unnecessary) limit of 16 chars on the password, you can have all the security you could need, and then some. On top of that, you can get two-factor auth for free in most cases. The "added security" that those people want is in practice not significant at all, and Blizzard had other priorities driving their choices.
If I had to make an auth system I'd probably still opt for case sensitivity, no length limits, and other such best crypto practices, simply because that's the path of least resistance. But my biggest security concerns would be elsewhere.
If you care about the security of your account at all, you should be using an authenticator, and even with a poor password proper two-factor authentication is far more secure than even the best password.
How is breaking backward compatibility simpler? If you don't support legacy commands and options you are forcing countless programs to be rewritten. Many aren't even actively maintained any more and businesses will avoid upgrading to your new 'simple' platform due to the huge cost, complexity, and risk of the rewrite project not succeeding, like many software projects. That's why OpenGL has so many old methods and commands, they are used by old, expensive CAD programs.
Speaking of OpenGL, more efficient memory routines he claims are worthless have probably saved me months of optimization programming real time games. If you don't have sufficient frame rate there for a good experience you end up doing enormous optimization work.
Agreed. Was very impressive seeing Googlers respond, and respond helpfully which is not always easy in tech esp to outside parties, and have forums and regular G+ hangouts so it isn't a one time thing. Not to mention other people with similar problems point out the delay in reapplying the signal, etc..
I've run into multiple situations at work where someone I was working for knew how to code, even if it wasn't their job, and it made things so much easier. I probably shouldn't reveal the details, but in general they were able to identify situations where just writing a quick app would help a lot vs. not having one, even tried writing it themselves, after when I ended up writing it and sent the source code along (they didn't have source control access) they were able to modify it as needed to be much more usable without bouncing it back and forth to me over and over, etc..
In another situation the person again figured out when an app would deliver really awesome results over the bog standard 60's way of doing things, and during the meeting to see if we could help out and all the subsequent revision communication, they just knew a lot about how apps get written. They'd suggest things that made it 10 times easier to write, understood that throwing in an option for everything instead of having a set functionality makes testing and code branches and maintenance a real pain in the ass, approved slight changes that made things a lot easier to write ahead of time instead of demanding meeting the requirements exactly as they were written, etc..
It's sort of like when you hear about someone trained as a doctor and who can also code doing all this awesome stuff. Except in a large organization we already have a ridiculous amount of skilled people available, so it's closer to you just need to know about people's capabilities and how they work to get really close to a similar situation where you can take advantage of both fields. So anyway, even if it isn't someone's job to code, it can be very valuable for them to know how to, and it can make them a lot easier to work with for those of us who do code professionally.
Make sure you have clicked on a story before you try to scroll, that got me for quite a while too. There was nothing to tell me to click on stories to read them. I only figured it out because I tried to click on an image and got a story instead...
You sound dead on to me. Java tooling is basically light years ahead of JavaScript, just because it's so much easier to write for a static language. Most people don't learn all the advanced features of Eclipse and other IDEs and debugging until they are stuck writing in them for years and years anyway. I know how to do things in hot keys in Eclipse that I don't even know how to do otherwise. Hot code replace and debugging and all the other stuff is similarly an advanced topic, even for many Java coders, so it is no surprise JavaScript programmers think it is something new.
I've done development in Eclipse off and on for a few years. Some Python (PyDev extensions), some Java (Android, school assignments, a desktop app). I haven't tried it all that recently, but one of my biggest complaints has been performance. I end up turning off a significant number of the features that people talk about for Eclipse, simply because they make the environment run too slowly. It's not as if I'm using underpowered machines either...
I hate to break it to the guy, but I can't remember the last time my browser was at 100% zoom, so his perfect pixels will never look perfect on my screen anyway...
Brin also said they do a lot more than share and view video feeds, but it is tough to show. I imagine they at least replace your mobile phone and headset, at the minimum. Consumers gave up cameras for their new smarter phones, and this can be positioned as just an even smarter phone doing more.