Filequeue supports Streams
Filequeue, the module I wrote to fix an issue I was having while trying to open too many files at once in Node.js, now supports Node 0.10.x, and has support for the new
WriteStream methods that were included with the 0.10.x release.
Adding streams support required that I rewrite most of the module to be more flexible in terms of method signatures allowed (previously, a callback as the final argument was required for the module to function properly).
While doing the rewrite, I also changed the way new methods were added to pass the Grep Test. The actual logic of what’s happening when the methods are called is much clearer now, which should make maintenance and extension much easier, both for myself and other contributors.
Filequeue is available on NPM.
You learn something new every day. (As is to be expected, this is well-documented on MDN. But when something works the way you expect it to, you don’t always look into why.)
Testing IE with OS X
We test the site in IE8, but didn’t expect that anyone would be visiting using IE7. Unfortunately, the rumors about corporate America’s IT departments are true, and a good portion of our users were having a terrible experience.
After googling around for a bit for a way to test in an older version of IE without booting up a 5 year old box, I came across ievms, an excellent tool from xdissent which allows you to install a virtual machine for IE6, 7, and 8, in a (nearly) painfree process. A single
curl command is not bad.
I was concerned about being able to boot a VM on my 13-inch MacBook Air with all my other applications, but so far, I haven’t had any problems.
So now I can finally test in IE7! Except that also means I just found a bunch of IE7 related bugs that I now have to spend the rest of the night perusing Stack Overflow to find answers for. Ahh, the joy of web development.
 Some people will take exception to the use of this term. For those people, I suggest you read “behaving differently”.
 By this of course I mean, “a significant enough portion of the population to justify the development time.”
On the Bleeding Edge of Node.js
Developing with new tools is a lot of fun. They’re usually new because they allow you to do something that you couldn’t before, or in an environment that you couldn’t before.
However, Node is very young, and very immature. There are tons of modules out there, and more coming every day, but the fact is that you will encounter situations that no one else has encountered before (or at least documented). Coming from Rails and PHP, that’s quite the change of pace.
For starters, how do you store passwords securely in a database? Well, you use bcrypt of course! And there is, in fact, a bcrypt module for Node that is excellent…if you’re not using Windows. One of our developers was using a Windows box, and despite trying to figure out how to get it to build for about a day and half, it just wasn’t meant to be. At some point, it’s faster to boot up a Linux VM than to embody the definition of insanity.
Last I checked, the issue was still being actively worked, with an update from the bcrypt author as of about two weeks ago. The community is there, the ecosystem is just young.
But it’s not just Windows. We work with MongoDB for storage, and on Node, you can’t do better than Mongoose. But as I said, it’s young. So the findAndModify behavior wasn’t available in Mongoose. Taking a closer look at the source on GitHub, I found that the edge version of Mongoose did support findAndModify (in the form of findOneAndUpdate for all you Mongoose users). So I did what any overconfident dev might do: I switched to edge in order to take advantage of the new feature.
Unfortunately, there is a reason that it is not a complete release. While findOneAndUpdate works, there was at least one very nasty bug that I encountered in the Mongoose source. That, and the changes to functionality make certain design patterns much more attractive (namely, passing a Mongoose document as the update argument) that aren’t currently supported in Mongoose.
And these are just the issues I’ve found. And I’ve barely scratched the surface of what Node can do.
But that’s a good thing. That’s what makes it fun. Everything has pro’s and con’s, and to me, the pro’s of what Node can do, and what I see for the future of Node are well worth some time spent here and there digging into the source code of a newer module.
After all, some people find debugging fun.
 I’m still working adding tests to my pull requests to get both of these complaints addressed upstream.
PayPal could explore Node.js (and TechCrunch needs to change its name)
Silly mistakes (and the fact that half of the article is regurgitating Crockford’s Wikipedia page) aside, what irks me the most is the total lack of both technical understanding and journalism. Lunden has a gem in the article: Edwin Aoki specifically mentions to Lunden that “[Crockford] will be partnering with [Aoki] on more ways to utilize JS both in the server and on the browser for PayPal.” (emphasis mine).
PayPal could very well be exploring/expanding their use of Node.js, a significant move in the technology community, and Lunden totally missed it!
Regardless of the poor reporting, this is an exciting time for Node developers if another big player like PayPal is putting some resources into the area.
And TechCrunch, if you’re not even going to try to report on the technology side of things, please change your name to something more suitable, like SiliconValleyGossipCrunch.