scriby

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?

Not sure about bananas, but in general products are individually wrapped due to the high humidity in Japan.

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

The .ts files will be compiled to AMD modules, so none of the declarations will be in the global scope.

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.

https://github.com/scriby/asyncblock-generators

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 think simply not using Safari will mitigate most of the impact for most users on OSX.

The whole paragraph can be translated like this:

"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?"

Good point.

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

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.

http://www.blackboard.com/sites/xplor/index.html

I don't see anything fundamentally wrong with this programming question, except that it might be a little involved for a short interview.

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)

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.

(I maintain a library built on top of fibers: https://github.com/scriby/asyncblock)

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.

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.

https://github.com/scriby/asyncblock

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.

Express does return a 500 on exception by default. This article showed details about how to customize the error page.

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 don't think the attack as described would work in practice, because the modified javascript file would no longer be valid javascript and would just break the site.

I think you'd have to both create a file that passed the hash check and was valid javascript, which seems somewhat more difficult.

Depends on the flavor of SQL. But also, might not be a totally missing where clause, but just an incomplete one.

This kind of bug can happen when you have code like this in SQL:

SELECT @id = id FROM table --Oops, forgot where clause. This selects a "random" row

DELETE FROM table_2 WHERE id = @id

Will these examples protect you from thrown exceptions? Null reference exception? Oops, your callback isn't getting called -- and you're probably leaking resources or leaving things in an inconsistent state.

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.

Not sure why I would use this when other solutions like LABjs are rock solid, fully featured, and small (~2k zipped).

http://labjs.com/

For those interested in the fibers way of doing things, I recommend checking out https://github.com/scriby/asyncblock. It provides an easy-to-use abstraction to get the best of both worlds (straight-line code without blocking).

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?

Chaining blocks works, for instance something like:

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

This problem was solved in SQL 2005. The solution in SQL 2000 was pretty terrible. You had to select from the start of the table to the end of the current page, reverse it, take a top of the page size, then reverse again.

Don't like callback hell? Use fibers.

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)

Yes.

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.