I guess this just doesn't carry over into the charts used in the financial sector?
101 karma · joined November 14, 2011
I guess this just doesn't carry over into the charts used in the financial sector?
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).
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...
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.
"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?"
Check out https://github.com/scriby/browser-harness-bootstrap-tests for a full example. Browser harness itself is just a conduit between node and a browser - you need to provide the test framework yourself (mocha, vows, etc.).
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.
The purpose of this question isn't to tell you whether the candidate can program chess boards or not. It could be used to help find candidates who:
* Have experience with search algorithms
* Specifically have experience with backtracking solutions
* Can reason through a complex problem (and communicate while doing so)
* Paid attention in school / knowledge retention (for recent grads)
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.
(I maintain a library built on top of fibers: https://github.com/scriby/asyncblock)
See here: http://stackoverflow.com/questions/9254632/how-to-stop-knock...
Also note that you can configure it as a virtual element, so you can use the <!--ko stopBindings: true--> syntax.
I'll just leave this here. It's been my pet project for the last couple years, and is a fully featured version of this concept.
There's also https://github.com/0ctave/node-sync, which is the same concept.
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 think you'd have to both create a file that passed the hash check and was valid javascript, which seems somewhat more difficult.
SELECT @id = id FROM table --Oops, forgot where clause. This selects a "random" row
DELETE FROM table_2 WHERE id = @id
So the recommendation is to restart the process - but let's not forget that hundreds+ of other requests could currently be in the pipeline - are we just going to abort those too?
Ok, we'll clearly the solution is to wrap all our callbacks with try/catch! Shoot me now...
For large, sprawling applications used to support a business, something like https://github.com/scriby/asyncblock can resolve most of the headaches with async code, including error handling. It's worked out well for my team at work, which is building a "very large" node application.
Disclaimer: Asyncblock is my pet project.
I don't think there really needs to be a fibers based ecosystem. Isn't it best if modules don't rely on fibers such that they can be reused in either context?
var queryResult = getDatabase().sync(). getCollection().sync(). fetch({ query }).sync();
Assuming all those are asynchronous operations.
Chaining wouldn't work with .defer() right now. It only supports syntax like "var x = something().defer()".
https://github.com/scriby/asyncblock
(My pet project, a flow control library built on fibers that gives you all the benefits of async programming without the callbacks)
At least in my own apps. Model instantiation being a bottle neck practically implies that you generate models in a tight loop and do nothing else with them, such as persisting them.