webdevRefinery Forum: Kyek - Viewing Profile - webdevRefinery Forum

So in my couple free hours at night, I've been entertaining an obsession called Toady.

Toady is an IRC bot. Big whoop, right? Sure. Until you change Toady's code and it takes effect without a restart, or even reconnecting it to the server. Or until you go to install a new third-party Toady mod, and you realize that Toady's entire public package manager for mods is only about 200 lines long, and half of that is jsdoc.

Obviously, Toady is written in Node.js, but recently I've been digging deeper into the core to see what I could make Node do that hasn't been widely explored yet. Things like editing the require() cache in a running application, resolving module keys, selectively rerouting stdout and stderr, and using npm programmatically to turn it into a package manager just for Toady mods.

It's nothing Earth-shattering; I mean, it's all in the Node.js docs, so it's not like I'm hacking the node source or anything. It's just that so much of it hasn't been touched in mainstream Node applications -- ESPECIALLY the concept of reloading modules without restarting the application -- that I had to play with it. And it's turned into a pretty solid and easily extensible IRC bot, to boot . Right now there aren't a ton of third-party mods to make it fun (actually, at the time of this posting, there's exactly one), but I hope to write a few more once I can convince myself to stop tweaking the framework ;-).

Check it out: https://github.com/TomFrost/Toady

I haven't gotten a ton of time to peruse this yet, but so far it seems like a pretty epic information repository for people who have used Javascript without really knowing javascript.

http://superherojs.com

Node 0.10.0 was released last week, and is generally awesome. Isaacs put together a nice blog post for the changelog here but I think the most important thing to note is how very seriously they screwed process.nextTick().

According to the docs for versions previous to v0.10, calling nextTick() with a callback function would cause that function to execute in the next pass through the event loop -- the next "tick". This was never accurate. When you called process.nextTick() before, it added your callback function to a 'nextTick' queue, and it would empty that queue TWICE in a single trip through the event loop. Once before preparing the IO callbacks for that iteration of the loop, and once after the callbacks were run. As a result, it was hard to rely on it, because consider this code:

process.nextTick(function() {
    doSomething();
    process.nextTick(function() {
        doSomethingElse();
    });
});

Will doSomethingElse() run after any queued IO is taken care of, or will it execute immediately after doSomething()? With process.nextTick() as it was, you would never know. That needed to change.

So the thinking was this:

• the nextTick queue needs to be emptied just once per loop.
  
• nextTick alone is a bad solution, as people were using it when they DID want immediate execution, as well as when they wanted something to happen on the next tick.
  
• To address the above, we need TWO functions. nextTick(), and setImmediate().
  
• Ideally, if you set a function to execute immediately, PLUS if that function also sets something to happen immediately as it runs (and so on and so on until a set cap is hit) it will all happen at that moment, while the queue is being emptied.

So for Node v0.10.0, they did exactly that. The nextTick queue empties once per loop, and there's now a way to set something to happen on the next tick, as well as a way to set something to happen immediately in the current tick.

The way to set something to happen immediately is called process.nextTick().
The way to set something to happen in the next tick is called setImmediate().
I am not joking.

I understand why the decision was made -- it's a really hard call. setImmediate is on the window object and is already documented as a way to break up long-running logic by having pieces of the logic execute after events have been handled. So if you're on the Node team, do you continue this loosely-documented proposal as-is, or do you use your weight to push a more sensible naming convention and keep your codebase logical? I would have gone with option 2, since the only entity behind setImmediate() in its current form is Internet Explorer and this hasn't stopped the greater standards community from realizing better versions of those concepts in the past.

So if you make any use at all of process.nextTick(), it's best to read that blog post and decide whether you want your code to actually execute on the next tick, or as immediately as possible in one lump. And once you decide that ... call the function named the exact effing opposite of what you want. What a ridiculous decision.

Regardless though, this is important because if you were using process.nextTick() to break up any potentially heavy processing so that it doesn't block your IO handlers, you need to use setImmediate() now or you WILL block your IO (which steams me even more, because if the functionality matched the name, no one would even have to change their code). For example, the following function will complete ALL of its loops before the tick completes:

function lotsOfTicks(count) {
    if (!count)
        count = 0;
    if (count < 1000000) {
        process.nextTick(function() {
            lotsOfTicks(count + 1);
        });
    }
}

lotsOfTicks();

Happy fuming!

Normally, open source means putting your project up on a public repo, making sure it doesn't contain security credentials, the code is sane/safe, etc. But recently, another company has taken a different approach to open source:

http://phone.directo...o-36256851.html

(If they happen to fix it before you see the link... screenshotted xD http://i.tomfro.st/3IjUe.png . There's even more code further down than that, but advertising that you're susceptible to easy SQL injection is probably as bad as it gets xD)

Then please do your best not to show up in these search results.

https://github.com/s...sults&type=Code

Ouch, devs. Ouch.