The later versions of Flash supported a Stage3D object, which was basically a Flash version of what you’d expect today from WebGL. It was hardware accelerated (with a software rendering fallback, if I remember correctly) and supported anti aliasing and shaders and all the things you’d expect. Performance was pretty wonderful. If you wrote things using this, you wouldn’t notice much of a performance difference for Flash.
A common solution is to have the server track which state frames that the clients have acknowledged receiving. The server can then delta compress from that client’s frame, for each client. It’s a bit more costly on the server side, as it means you need to maintain state frames back to the oldest acknowledged frame across all clients, but it guarantees you will be sending a packet a client can understand. Usually this is combined with some sort of limit which kicks a client off as timed out if its acknowledged frame strays too far from the most recent one.
You're correct. The spec only specifies that "onFulfilled or onRejected must not be called until the execution context stack contains only platform code." This doesn't require that the implementation use the same macro-task scheduling mechanism that setTimeout might use.
The earliest concepts for the game were quite different than Doom. You were supposed to be playing a Thor-like character named Quake, who wielded a giant hammer.
I've experienced quite a bit of nausea from goggle only VR products like GearVR. Even the menu was enough to get me sick -- moving my head forward without the menu changing distance with me seemed to make my body think I should feel movement but didn't, or something like that. The nausea in these situations was quite bad and lasted for 30-60 minutes or more after taking off the goggles.
But I have to say that the experience was quite a bit different with the room scale VR like the HTC Vive. The only time I experienced any nausea in there was in Hover Junkers. The game has you riding a vehicle with frequent changes in direction at high speeds. This again seemed to be related to the perception of motion without corresponding sensations.
But the teleportation used in games like Budget Cuts didn't affect me at all. (There were some disturbing bouts of claustrophobia when I teleported too close to a wall, but that didn't induce any nausea.)
At the time that I tried the Vive, I spent about 20 hours total playing with it, spread across probably 4 sessions. I think my longest duration without a break was 6 hours. It was exhausting but not nauseating. The others with me had similar experiences. In fact, one of them normally gets so nauseated by things like this that they have prescription medication for nausea for use while riding in the car -- and they didn't experience any nausea at all.
Just wanted to point out that that isn't the JS you know because that's just typing information -- it isn't generating any code at all, it's telling TS what the types look like for Underscore's external methods. This would be stripped out completely in the compiled code. The actual code that results in JS just below that is much more typical.
This is really cool! If you look at the source, it appears that the images themselves are defined as JS code, almost like a vector image. For example, Zeus: http://essenmitsosse.de/pixel/scripts/zeus.px
The author then has a renderer to turn these into pixel data. It seems to render them down to an actual pixel image on the fly.
Unfortunately, nginx doesn't allow you to set custom headers for error responses by default. You need to add something like the ngx_headers_more[1] plugin for that.
After a cross country move to a remote coastal town, my wife and I were left at our destination with only a small portion of our possessions. The rest of our stuff was making its way there with the hired movers.
I got into a strange situation where I needed my Mac Mini for something, but it was still trying to connect to an old wired connection instead of the new wireless one. I didn't have any of my cables or display adapters -- just a keyboard.
Long story short: the Mac Mini has an internal speaker, and OS X comes with a vocoder shell program. I managed to boot into the OS and launch terminal, and blindly typed commands into it, piping the output to the vocoder app until I got things working.
I personally have been using it to document the more complex code that I write -- that is, the code that I have the most trouble explaining to others. I'm quite happy with the results for my collision detection library. [1] The library itself serves as a basic tutorial on collision detection, and I've used it myself for reference when I step away from the code for a while.
Definitely feels like an improvement on Cuba! I'm not a huge fan of the `is` method here, though. I feel like you could get the same thing from a terser DSL if you treated HTTP methods as terminators and only allowed `on` to filter the path.
This is a great way to explain it. My wife used to suggest that I work on a side project of mine when I had a few free minutes here or there. I had a hard time explaining why it wasn't really worth the effort unless I could work on it for at least an hour. She trusts me on that, even if I didn't do a great job explaining why, but it seems like this explanation would make the reasons easier to convey.
In my years of mentoring and tutoring, I've run into a number of students of programming (and, indeed, teachers) with the same problem.
Programming is about problem solving first, and teaching programming is about teaching someone to look at a problem analytically, and how to use an abstract flow of logic to solve a problem, and how to diagnose issues with your own logic when things go wrong. It's about critical thinking. It's about attention to detail.
It's about all of these things first, and about slapping keys second. But too many people see learning programming as learning the act of typing code, and focus too much on rote memorization of syntax, or teaching tools instead of thinking. Someone should come out of a course saying that they learned how to think in this new way as programmer, not that they learned a new programming language.
> Indeed you can hardly do many things at once - not in a single pure Python process. One thread doing something takes the GIL and the other thread waits.
> You can however wait for many things at once just fine - for example, using the multiprocessing module (pool.map), or you could spawn your own thread pool to do the same.
This paragraph is a bit deceiving. The multiprocessing module does spawn subprocesses by default, so it can indeed be used to workaround a GIL issue and do many things at once. It's not the same as a thread pool (although the multiprocessing module does offer a compatible interface which uses threads).
I see arguments about whether or not Amazon Instant Video is worth the money, but I think that's beside the point, isn't it? The important part of the discussion here is that Amazon Instant Video is not of interest to a large number of existing Amazon Prime subscribers, and they are likely paying the price for those who use it.
It's a bit of a frustrating trend to see companies bundling new technologies like this, often at the expense of their loyal customers. I am an Amazon Prime subscriber, and will continue to be one, but I would love it if Amazon Instant video were a separate subscription that I could choose to pay for on its own merits.
Both? I've been in situations where a company implodes like this, and employees at the company are often already being head-hunted by previous employees (who departed during a prior round of lay-offs, or who left of their own volition before the company fell apart) before they are fired.
While it's often something of a surprise when you finally do get the axe, you usually have a sense of impending doom, and a feeling that bad things are going down, before it happens. Projects stop getting traction. Upper management stops caring as much about what you're working on. Everyone becomes very apathetic. You get a rash of invites on LinkedIn, and people start updating their resumes.
So, it's rarely a complete surprise, and people often already have some idea of where they're going to go, or are ready to start looking.