Well ambient brightness matters, but actually analog cinema projectors use a frame rate of 48 fps (they "flick" every movie frame twice), so it's still way above 30fps.
Plus, with CRTs the problem is exacerbated, because they scan top to bottom, and need higher refresh rate to hide this effect.
"30 fps flicker" - that's not a CRT, it doesn't flicker, because unlike CRTs, a flat display doesn't have a ray refreshing the display top to bottom.
And 30 fps on a CRT wouldn't be enough to produce stable image in the retina at all, which is why CRT TVs used to refresh at a minimum of 50Hz, and that still flickers (it stops "flickering" at around 75Hz).
With flat displays frame rate is about display responsiveness and animation detail.
So I wonder where are the claims about eye-strain coming from. Maybe because people just want better display responsiveness and they like to borrow from the problems low refresh CRTs used to cause, because it sounds scientific and legit as a problem.
> "The more CEOs are paid, the worse the firm does over the next three years, as far as stock performance and even accounting performance"
Yeah well this entire study is invalidated by using stock performance as the lazy way to measure CEO performance.
Expensive CEOs are typically expensive, because they're hired to fix a company that everyone knows is going down. The riskier the company, the more the stock is expected to go worthless, the more you get paid in cash for taking on the job.
So it's expected that if you look for expensive CEOs you'll be seeing stock/accounting performance going down in short to mid term, because recoveries, whether successful or not, take time. They take years.
Also are you honestly counting CEOs who get millions in stock and $1 pay as... just getting $1 in pay? How stupid are you.
The problem with FlatBuffers and Cap'n Proto is that while in-memory rep matching serialization formats are much faster (infinitely faster as Cap'n Proto says tongue in cheek) for languages with unsafe direct memory access (like C/C++), they're actually slower and more cumbersome to use in any language without unsafe direct memory access (like Java, Rust, Python, Go, JavaScript/Node, Swift and... well, most languages).
The other problem is that Google tends to release random stuff as open source and then modify it (breaking BC) or abandon it without regard for the people who are using it.
> "The most well known simulator to any Android developer is probably (and ironically) the one that iOS developers use from Apple."
I get it. Ironically Google didn't copy Apple for once, and their solution turned out bad. So now they need to ironically copy it, please, Google, pretty please. But the real irony is that Android developers both get to boast about Android being open source, yet when they need something, they go beg Google implement it for them.
And Google really can't implement an efficient iOS simulator for them, because there's no Android desktop operating system.
You see, while it's getting a bit old to hear Tim Cook brag at every keynote about how "only Apple can make everything work seamlessly together", truth is, they indeed share a kernel and over half their APIs between their desktop and mobile operating systems. This is why the iOS simulator is that good. Tim Cook knows it.
While a supposed "thin layer" Android simulator has to interface all its APIs with Windows and then do it all over again for OSX, and then again for Linux (common POSIX APIs notwithstanding), every version with its unique quirks and bugs, not matching the platform it's simulating.
So instead of that ball of pain, Google chose the easier task of virtualizing the actual hardware and then running the whole Android stack on top of that.
In their particular circumstances, this was, and remains the only feasible way of doing it, and no amount of blog whining will change that.
Turns out you really can't copy some things so easily.
First of all calling it "JavaScript cryptography" only to immediately correct itself "oh, we mean browser client-side scripted cryptography, not JavaScript in general, say Node.JS".
Then calling it "cryptography", when all the article talks about is hashing passwords. There's more to cryptography than hashing passwords, and not all of it is susceptible to the attacks described.
So the real title of this article is "Client-side scripted password hashing in browsers less than ideal". I know, doesn't roll off the tongue as sweetly as "JavaScript eats babies", but what you gonna do.
Third, the faulty logic of "this new technique has a bad edge case, so we should completely reject it, despite any benefits".
The article just glosses over the situation where the script is served securely and yet you hash at the client. "We already have a secure connection, anyway" the author claims. Sure, but the server still gets the plain text password, because TLS doesn't hash, it encrypts (and you can decrypt). If the server is passing the login request to a third party to check the hash, turns out it's still a good thing to hash at the client so the intermediating party can't abuse its role, without the horrid UX of OAuth. Has the author thought of that? Nope, just dismissed the potential outright.
Plain old-school TLS/SSL connections have exploitable edge-cases as well. Should we "consider them harmful"?
Intelligent conversations about security require nuanced opinions that go into when something is useful, and when it isn't, and let us make the call if it's harmful or useful for a given project.
Calling something "harmful" outright and only listing the cons without the pros isn't this kind of intelligent conversation. It's just counterproductive scaremongering.
Part of being an intelligent person is the ability to make the best call based on all available information.
There's no general rule.
I'll just say that fast iteration is key. You iterate quickly and show users prototypes, and incorporate their feedback (or not), depending on the case.
You can see the "Fake it till you make it" WWDC session on Apple's site, it speaks exactly about how Apple does prototyping and user testing.
I don't know. The top two most frustrating things I encounter on modern web sites are: "infinite" scrolling effects & badly done responsive designs.
While adaptive UI can be done right (and yes, that's the correct name for it, "responsive" typically refers to reaction lag, not screen size), and is definitely a nice tool in the designer's toolbox, it's very telling that various "responsive evangelists" keep popping out of everywhere talking about the virtues of "responsive" where no one asked them. Say like the poster I was replying to here.
This behavior is typical for something at peak hype. They're just so excited about it, they can't comprehend why everyone isn't getting a boner about "responsive" so they have to talk about it non-stop to clue us in on the awesomeness we're allegedly missing. It's like Ruby on Rails all over again.
Which is to say the "responsive" movement right now is 80% bullshit and 20% useful technique (when used in moderation). And I have examples to support that.
Part of "responsive" is the horrible practice of rolling menus into obscure hamburger buttons, outright hiding panels with useful content and functionality, or presenting bizarre interaction patterns that some harebrained designer thought are more smartphone-ey.
This is not helping your users, it's pissing them off and making them spend a lot of time hunting for the "desktop version" link on your site.
I'm sure you can make your trivial point about the intricacies of web design without having to piggyback on Jonathan Ive's interview.
For the record, a lot of the UI prototyping at Apple is done in Photoshop.
It's also done on paper napkins, in Keynote, in Illustrator, in Xcode and with whatever works.
Good designers don't judge you based on what tools you use, and they're not picky about what tools they use. They'd use anything. The important part is how you think.
You can think about all sorts of screens and devices and do it in Photoshop. You can also produce unusable trite crap in static HTML.
Plus, with CRTs the problem is exacerbated, because they scan top to bottom, and need higher refresh rate to hide this effect.