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?
Many parts of the world get humid, yet don’t need to obsessively wrap everything in plastic. Especially when you have modern infrastructure like refrigerated shipping, air conditioning, etc.
It’s not as bad as Japan, but when it comes to produce in supermarkets, the UK shares this “wrap everything in plastic” mentality.
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).
Thanks, I had not seen that before. Interesting trick: Call a "registration" function with a string array (of dependencies) and an anonymous function (IIFE) with parameters for each dependency which the registration function injects. Thus, the dependencies are accessed as closures over the outermost func's params, rather than as globals.
where the 1st elipses are all the private/setup code, and the second elipses are whatever methods/properties the module exports. (this dummy only wants jQuery, but the list can be longer)
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...
> but there's just something weird about reusing package names for totally different projects...
Not only is it weird but it is inherently insecure.
Even NPM's solution:
> "If a package with known dependents is completely unpublished, we’ll replace that package with a placeholder package that prevents immediate adoption of that name. It will still be possible to get the name of an abandoned package by contacting npm support."
seems susceptible to social engineering. All it takes is for one heavily depended upon package to become compromised by a malicious actor, and the entire dependency graph is poisoned.
I'm not sure of a great solution, but it really makes you question the soundness of the NPM ecosystem.
I really see no good reason not to employ namespacing with immutable packages. If a package is dropped, all is well still. If readoption is needed, people can use the new package, similarly named. It obviously also allows for similar but different named packages to exist, which I don't see as a problem. I can usually find the top repo on github for instance, even with multiple forks. I worry about Rust since they have decided against namespacing, even though some suggested otherwise, early on..
I've had one of my package names transferred away from me with no warning, presumably after some period of inactivity. Npm as a repository seems to have gone totally insane, and I don't think I'll be publishing there anymore. I'll recommend people install my modules from a tag in the repo.
There should be at least some warning on the page that an earlier project with similar name was replaced with this package.
People make fun of Java's namespace conventions [1], but it goes to show the advantages of not having to have a central authority to decide on these matters.
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.
For nearly all cases (except some you can specify manually and/or discover through deep learning), you can throw away positioning which is why I didn't mention it.
As for the order of actions, I did mention that. The basis of my argument is that you shouldn't consider an entire player's turn as a "turn"; instead, consider each action as a turn.
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 guess this just doesn't carry over into the charts used in the financial sector?