The Japanese language actually does have an idiom for "in the red". It's written as 赤字, which literally means "red letter" or "red text". The opposite is 黒字, or "black letter" / "black text" which is equivalent to English's "in the black".
I guess this just doesn't carry over into the charts used in the financial sector?
I learned Dvorak in high school and was proficient in it after a couple weeks. In addition to actual practice, I found it helpful to just practice mentally during downtime.
I used Dvorak exclusively and lost the ability to type on qwerty keyboards. This became pretty inconvenient, so I re-learned qwerty, but then I couldn’t type in dvorak any more.
A while later I practiced dvorak again and have been able to switch back and forth without issue ever since (even though I don’t use dvorak very often now).
I found that dvorak wasn’t actually that good for programming due to the positioning of punctuation, math, and auxiliary keys. It’s also annoying for gaming or using hotkeys in general (especially copy + paste).
I used to use a project called now on npm that was abandoned a few years ago (https://github.com/Flotype/now). I was curious how this new project was using the same name on npm as the previous now that I had used.
Looking at the npm release history, versions <= 0.8.1 are the old project, and the new project picked up at 0.9.0 (should have been 1.0.0 I guess). This is consistent with npm's statements about package name transfers during the leftpad debacle, but there's just something weird about reusing package names for totally different projects...
I think the branching factor is somewhat higher given that the order of actions makes a big difference. Also remember that when playing a card you have to choose where to place it, which can multiply the branching factor by up to 7.
If both of you have 3 minions on the board, each of your minions has a choice of 4 targets, which is already up to 4^3=64 choices. Then considering each order of attacks, and the fact that you can play any card of your hand before or after attacks, and the branching factor has the potential to explode.
That's a control flow solution I wrote on top of generators to make it a little easier to manage parallel tasks, timeouts, error handling, and so on.
I originally made asyncblock, which was based on fibers a few years ago. This module uses the same underpinnings as asyncblock, just based in generators instead of fibers.
The browser's built-in same origin policy will prevent the iframed content from being able to access cookies in the containing frame because it is being hosted from a different domain.
"I didn't really think I'd be able to write this [program], but somehow I was able too. Ruby is scary, isn't it? I wonder if you could write this in another language?"
I'm working on https://github.com/scriby/browser-harness. It's a little different in approach because it doesn't use selenium at all (rather it uses a websocket connection with the browser to control it).
It's considerably more lightweight and compatible with all browsers you care about, but you can't do everything you can do with selenium.
We've been using it for about 6 months at work and having good results.
It would be tough for Fibers to be totally abandoned, as http://www.meteor.com/ relies on it.
I don't think it's really needed any code updates recently, as it works on Linux / OS X / Windows and all recent versions of node.
I think it's somewhat hard to tell what the adoption of fibers looks like, as it typically wouldn't be used by other modules in npm. You don't want to force people using your module to use fibers. So, it would mostly see its usage in applications.
It will be interesting to see what happens to fibers once generators ship with core node (available now under the --harmony-generators v8 flag). The most compelling reasons for using fibers can also be met by using generators.
In response to your #4, check out the stopBindings option. It provides a pretty simple pattern where you can wrap your knockout bound components in a stopBindings, then you don't have to worry about other binds on the page interfering with them.
It's probably because their free plan already didn't require a CC. I think there's a big difference between "no access" and "CC required", but less of a difference between "free access" and "CC required for upgrade".
Japanese is generally more compressed than English. For instance, consider "dragon" vs "龍". The exception is when polite/formal language is being used, in which case it can get more lengthy. Instructions and descriptions would generally use more polite language, where navigational elements would be more pithy.
If I was to offer a theory on why the Japanese tolerate more text, I would say it's related to higher "skimability". It's easier to pick out symbols within a block of text and get a general feel for what's there vs. words in western alphabets. If this is the case, we would also expect Chinese websites to be similar, and I think that's the case.
Or, it could just be a design trend. For instance, usage of the color pink is much more prevalent in Japanese design.
I guess this just doesn't carry over into the charts used in the financial sector?