HN user

noonat

161 karma

I'm a developer. My website is http://nathanostgard.com/.

[ my public key: https://keybase.io/nathanostgard; my proof: https://keybase.io/nathanostgard/sigs/X7uv7WgUDYi93m9cGVZBhR865_G9ovZzAulRfq2NSI4 ]

Posts0
Comments50
View on HN
No posts found.

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.

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.

[1] https://noonat.github.io/intersect/

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).

Worse 12 years ago

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.

It could be that the ranking prior to the swap is continuing to have some lasting effect on the sites after the swap. It would be worth doing the same test on new domains (with new content), to be sure there weren't any side effects from the swap itself.

If you want to allow undefined to be passed as a valid non-default value for a trailing parameter, you can also use arguments.length to determine how many arguments were explicitly specified.

    var foo = function(a, b) {
        if (arguments.length < 2) {
            b = 'some default value';
        }
        // ...
    };

The fact that the user was logged into Facebook after giving Facebook credentials to Spotify is not the problem. The login screen communicates that this will occur. Maybe it doesn't communicate it as well as it could, but it does communicate it.

The problem is that Spotify added itself to the user's list of apps and granted itself access to the user's data without any communication that this would occur. I guess you could say that permission for Spotify to do that is implicitly granted by giving them your Facebook credentials. But these days, federated authentication and authorization are two different things for end users -- especially so for Facebook apps. Spotify should at least prompt the user before making these changes on their behalf. Very underhanded behavior.

In my mind, this usage of parenthesis is less ambiguous. Parenthesis are used in C-like languages for both function calls and order of operations. That is to say, they are used in these two ways:

    foo(a, b, c)  // functions
    (a + b) * c   // order of operations
Making parenthesis optional for function calls means parenthesis are used instead for just controlling order of operations.

In practice, CoffeeScript can't always guess when something is a function call (such as a function call without arguments), so you end up mixing in some function call usage no matter what.

Although a site may have a primary color palette, colors will often look very different in context. Our vision is full of tricks and assumptions that can cause the same color value to look drastically different in different situations. The color in your swatch might look different when used on a different background color, or might not appear as bright when used as a link color, and so on. It's reasonable to expect some variation in the color palette to deal with these issues. Some of these counts seem a bit excessive, though.

Programmers are often asked to accurately estimate tasks that are too large to estimate. The smaller or larger the task, the more likely it is that there will be errors in the estimate. The larger a task, the more likely there is a detail that has been missed during estimation, the more chance that you will encounter a surprise during development that greatly increases development time.

Most successful estimation methods boil down to refusing the estimate larger tasks, and instead breaking them down into smaller tasks. The process of breaking them down forces people to think through them in more detail, and you flush out many of the surprises early on. Similarly, most of the successful systems require you to apply a minimum amount of time per task (e.g. one hour). This removes the problem of programmers underestimating simple tasks.

The best estimates come when you continue to use that system over several iterations of work, and analyze the accuracy of previous estimates. This gives you (and other developers) a better sense of how to make good estimates.

Sadly, even when you have a reliable system of predicting how much work a development team can get done in a given chunk of time, many managers bow to pressure from above to hit deadlines, and expect the team to accomplish more than the data says they are able to accomplish.

Yes. iTunes on your desktop machine can store (and update) apps that you are not currently syncing to the device. Then, when syncing the iPad, you can check a box in iTunes to indicate that the app should be included on the device.