3,647 karma · joined April 23, 2016
I have been doing this for years. I don't have problems with my back or wrists like I did years ago in an office, even though I had an office chair, desk, and keyboard drawer.
The same director, Robert Zemeckis, made Cast Away. There's a scene where Tom Hanks has removed the tape from a videocassette and tied strips of it to a tree, as streamers, to tell him when the wind changes direction. The strips of tape are blowing in the wind, and slowly they start blowing over to the other side, to show that the wind has finally changed direction. (He needs to know this as part of his plan to sail away.) Anyway, the tape was all computer animation! I guess they couldn't get it to act how they wanted with real tape and some fans. So they painstakingly animated it, and I would have never known, had I not heard it on the behind-the-scenes commentary.
What?
> with rounding up it's even worse resulting in 1:01:51
Huh?
If you are making some kind of timer, you first should convert the time to pure seconds, or in whatever the smallest unit is that you care to deal with (milliseconds?). It is only at that point that the data is ready for any kind of arithmetic (for example, to subtract 1 second). Then, when you wish to display it, you first convert it.
For example, if the user sets your timer to 2 minutes, you would convert "2:00" to 120 seconds. Then you subtract 1 second. Now the internal value is 119. Then you convert back to the display format: "1:59". But be sure to keep "119" in some internal variable, for the next change.
<form name=f>
<input type=number name=h min=0 max=99 value=0>
<input type=number name=m min=0 max=59 value=00>
<input type=number name=s min=0 max=59 value=00>
<input type=submit value=Start>
<output name=r></output>
</form>
<script>
document.forms.f.addEventListener('submit', function (ev) {
ev.preventDefault();
let f = ev.target,
s = Number(f.h.value * 60 * 60) +
Number(f.m.value * 60) +
Number(f.s.value);
function show(f, s) {
let h = Math.floor(s / 60 / 60);
s -= (h * 60 * 60);
let m = Math.floor(s / 60);
s -= (m * 60);
m = String(m).padStart(2, '0');
s = String(s).padStart(2, '0');
f.elements.r.value = [h, m, s].join(':');
}
show(f, s);
if (f.timer) { clearInterval(f.timer); }
f.timer = setInterval(function () {
if (0 === s) { clearInterval(f.timer); return; }
s -= 1;
show(f, s);
}, 1000);
});
</script>Rounding is something I learned in elementary school. If someone in elementary school was unfamiliar with rounding, it would be mean to take them to task about it. But this writer is an adult, a professional programmer, and presumes to be a teacher, by taking the time to publish an article about the subject.
In fact, the writer has even less excuse, because he knows about rounding. Twice he mentions "rounding down". So it is all the more baffling that he did not call what Apple was doing, simply, "rounding up". Instead he wrote a multi-paragraph blog post about adding 500 milliseconds of "fake time", then having to duct-tape over that by making the timer say "0" when the timer reached 500 ms.
Suppose a man bills himself as a car salesman, but every question you ask him about the car, he says the wrong thing. He says the car has 3 wheels when it has 4. He says it is red when it is black. He says the engine is in the back when it is in the front. Would it be mean for you to mention his title, by saying something like, "You say you are a car salesman, but you don't know about this car on your lot." It is right to call someone out for being less than what they say they are.
As for random blog posts on the internet, this isn't so surprising. What's surprising is that it wound up on Hacker News with over 100 votes.
A stopwatch counts up. Therefore, it makes sense to use the floor (4.99 is still "4", not yet "5").
A timer counts down. Therefore, it makes sense to use the ceiling (3.01 is still "4", not yet "3").
In fact this was a turning point in the original article: "rounding down . . . makes a lot of sense when counting up. . . . But for a countdown timer, this is counterintuitive."
That's a good point. Thank you
This sounds like a database. Or if that's too slow for you, a Redis cache.
I try not to make blanket statements about software infrastructure, because we all work on a variety of systems. However, I'm having a hard time thinking of scenarios where session cookies are too hard or too slow.
Someone may say, this would bother others, who saw something interesting but didn't click it this time. For me, it would train me to open those in a new tab or save them to my Watch Later list. Or just make it an opt-in feature, this aggressive renewal of the home page.
For example, in Basic Authentication, you still have to check the username and password against a database, whether that be a file, a relational database, LDAP, etc. For JWT, to verify the signature you must look up the issuer's pre-shared or public key.
Is it even possible for a request be stateless if it requires authentication?
The server's hardest work is usually in the database: scanning through thousands of rows to find the few that you need, joining them with rows from other tables, perhaps some calculations to aggregate some values (sum, average, count, etc.). The database is often the bottleneck. That isn't to say I advocate NoSQL or some exotic architecture. For many apps, the solution is spending more time on your database (indexes, trying different ways to join things, making sure you're filtering things thoroughly with where-clauses, mundane stuff like that). A lot of seasoned programmers are still noobs with SQL.
Anyway, if rendering is lightweight, then why does it bog down web browsers when you move it there? I don't think it does. If all you did was ship the JSON and render it with something like Handlebars, I think the browser would be fine, and it would be hard to tell the difference between it and server-side rendering.
I think what causes apps to get slow is when you not only render on the client but implement a single-page application. (It's possible to have client-side rendering in a multipage application, where each new page requires a server roundtrip. I just don't hear about it very much.) Even client-side routing need not bog down the browser. I've tested it with native JavaScript, using the History API, and it is still snappy.
I guess what it is, is that the developers keep wanting to bring in more bells and whistles (which is understandable) especially when they find some spiffy library that makes it easier (which is also understandable). But after you have included a few libraries, things start to get heavy. Things also start to interact in complex ways, causing flakiness. If done well, client-side code can be snappy. But a highly interactive application gets complicated quickly, faster than I think most programmers anticipate. Through careful thought and lots of revision, the chaos can be tamed. But often programmers don't spend the time needed, either because they find it tedious or because their bosses don't allot the time --- instead always prodding them on to the next feature.
Usually software would protect you with a confirmation pop-up: "Are you sure you want to __________ ?" Instead, GMail just let you do it. Then it added a yellow strip at the top, "Message deleted. [Undo]". So, instead of double-confirmation, GMail implemented Undo more thoroughly.
This was better in two ways:
(1) It wasn't a pop up! I hate pop-ups. I don't think anyone likes pop-ups.
(2) A computer asking you "Are you sure?" is as annoying as a human being questioning everything you say. It is nice every now in then, when it really was an accident. But most of the time, it isn't. Another metaphor is a mechanical device that is failing. You press the button, and it doesn't work. You have to press it again.
The whole approach breaks your flow, implies contempt, and by definition is frustrating.
The approach of "just let you do it and provide an undo" isn't recent anymore, and sadly, Google seems to be drifting away from it. I see more and more pop-ups and "Are you sure?" messages.
Learning a second language, likewise, is best done the same way as the first: through immersion, if you can swing it. The high school student who spent a summer in Mexico came back far more fluent than I was even after three classes in high school and one in college. The plasticity, though, of this area of the brain will decrease over time. It is easiest to pick up a new language before adulthood.
Most people don't appreciate this or don't believe it. For more information, read The Language Instinct, by Steven Pinker.
Programming? Yeah, I guess it spins the CPU more than any specialized chip. I hate how I can't be interrupted while doing it, and for a few moments trying to come out of it, I am in some kind of daze.
In your 30s and 40s, you stop caring what other people think about you.
In your 50s and 60s, you realize that no one was really thinking about you after all.
It doesn't answer the question. The questioner is asking for your help in making a decision. If you are completely neutral about the two, then most people answer with the phrase, "Either one is fine". Saying just "yes" sounds like you misunderstood the question --- unless you say it with a wry smile, showing that you mean to be funny in your answer.
(I suppose occasionally someone could ask the question with a different inflection, with the last word at a higher pitch, meaning, "Are either of these fine with you?" rather than, "Please pick one.")
> Similarly with the boy or girl question, "no" may be stillborn.
The sex is set at conception.
The figure on most keyboards is G. Yet when you press it, it puts on the screen, g. Chromebooks are better in this way. Their keyboards are labeled in lowercase.
I actually went back and forth between saying Shift-G, or just G, for this very reason. So I erred on the side of clarity.