Daddy, what's a stream?
At dinner tonight, I was discussing that I've been thinking about streams and how to simplify them in JavaScript. My 7-year-old perked up and asked me:
Daddy, what's a stream?
I explained that a stream is like a line of water along the ground. If you dig a trench on a hill and fill up the high end using a water hose the water will run down the hill along the trench. This is one of his favorite hobbies in the back yard, so he understood completely. I explained that when new water is added to the top, it eventually makes its way to the bottom of the stream. The end where water comes from is called the upstream and the other end is the downstream. Gravity pulls water down.
Read more...Content Syndication with Node.js
Web syndication is a must for any Website wishing to share some entries easily to other systems. Better known under their format name like RSS) or Atom), they can be quite time consuming to generate without a module handling all their formating. Thanks to the power of Node's package manager NPM, you can generate yours in no time.
Read more...Session-based Authorization with Socket.IO
Finding a decent article about session based authorization in socket.io is more difficult than one expected. This article will show how you can take advantage of Express session middleware and socket.io authorization middleware to create a very simple authorization mechanism when establishing new socket.io connections.
Read more...Make Your Tests Deterministic
Non-deterministic issues like race conditions or thread deadlocks are very difficult to test, because they are by nature hard to reproduce. Fortunately, in the JavaScript world, we only have a single thread, so we are safe, right? Well, not really because...
Execution order of callbacks can cause the same race condition issues that plague multi-threaded environments.
Read more...Sending e-mails with Node and NodeMailer
Sending e-mails with NodeJS is almost a breeze. Almost. First, you have to plug-in the NodeMailer module than set up a transport type, load the templates, add attachments and finally send...
Read more...Node.js and MongoDB - Getting started with MongoJS
It won't be an exaggeration if one claims that in the past few months Node.js and MongoDB have literally taken the software and web industries by storm.
Not just bleeding-edge startups but even medium and large enterprises are leveraging these two technologies to deliver a better experience to their users by build more capable, performant and scalable apps.
So what is Node.js?
Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
..and what is MongoDB?
MongoDB is a scalable, high-performance, open source NoSQL database.
This post will cover the basics and get you started with your Node.js + MongoDB app. Make sure you have Node.js installed and MongoDB setup on your developer machine.
Let's verify your Node.js installation and start the MongoDB server:
$ node -v
$ mongod
Read more...Really simple file uploads with Express
Few days ago I was working on a fairly typical web application and I faced the challenge of implementing a fairly typical web application feature - file uploads. It was the first time I was implementing file uploads with Node (and Express) and I did what anyone else would do - I googled it.
Unfortunately all the articles / posts out there are either outdated, too complex or plain wrong. So I did the next most obvious thing - post a question on the mailing list. As always Mr. Holowaychuk was incredibly quick to respond. His answer lead me to do what I should have done in the first place - read the docs.
Read more...Understanding process.nextTick()
I have seen quite a few people being confused about process.nextTick(). Let's take a look at what process.nextTick() does, and when to use it.
As you might already know, every Node application runs on a single thread. What this means is that apart from I/O - at any time, only one task/event is processed by Node's event loop. You can imagine this event loop to be a queue of callbacks that are processed by Node on every tick of the event loop. So, even if you are running Node on a multi-core machine, you will not get any parallelism in terms of actual processing - all events will be processed only one at a time. This is why Node is a great fit for I/O bound tasks, and definitely not for CPU intensive tasks. For every I/O bound task, you can simply define a callback that will get added to the event queue. The callback will fire when the I/O operation is done, and in the mean time, the application can continue to process other I/O bound requests.
Given this model, what process.nextTick() actually does is defer the execution of an action till the next pass around the event loop. Let's take a simple example. If we had a function foo() which we wanted to invoke in the next tick, this is how we do it:
function foo() {
console.error('foo');
}
process.nextTick(foo);
console.error('bar');
If you ran the above snippet, you will notice that bar will be printed in your console before foo, as we have delayed the invokation of foo() till the next tick of the event loop:
bar
foo
In fact, you can get the same result by using setTimeout() this way:
setTimeout(foo, 0);
console.log('bar');
However, process.nextTick() is not just a simple alias to setTimeout(fn, 0) - it's far more efficient.
More precisely, process.nextTick() defers the function until a completely new stack. You can call as many functions as you want in the current stack. The function that called nextTick has to return, as well as its parent, all the way up to the root of the stack. Then when the event loop is looking for a new event to execute, your nextTick'ed function will be there in the event queue and execute on a whole new stack.
Let's see where we can use process.nextTick():
Testing Private State and Mocking Dependencies
During Christmas I've been working on Testacular and found some tricks how to make my testing life easier. It's nothing special at all, just a simple way how to access private state of a module and how to mock out some dependencies. I've found these two techniques pretty usefull, so I believe it might help someone else as well...
Why would you need to access private state of a module?
Private should be private, right? Yes, for sure. But during unit tests, it can be very helpful to have access to private state of a module - I always try to cover functionality or bug at the lowest possible level, because it's simply cheaper:
- faster test execution
- less code is required to bootstrap the test
Let's say we are building very simple static web server, the skeleton might look something like this:
var http = require('http');
var handleRequest = function(request, response) {
// read file from fs and send response
};
exports.createServer = function() {
return http.createServer(handleRequest);
};
This module has only one public method createServer, so unless we make it public, we can't get
hold of anything else but this method. That sucks, because HttpServer doesn't have any public
method to call the handler, so we would have to send some data through socket to test it. That's way
too much effort, especially when you realize that the only code we really need to test is the
handleRequest function - everything else is just Node and we trust Node, because it's awesome. We
need to test our code - that's where all the bugs are.
Why would you need to mock out dependencies?
Some dependencies are cheap, some not. When our code uses modules like util or path, we are
fine. Nothing bad happens there. But when it comes to some other modules like fs, net or http,
it's totally different story. We simply don't want to deal with real filesystem in unit tests. There
are many reasons for that, such as:
- accessing file system is slow
- it requires seting up some state of filesystem
- there is only one instance of filesystem, so conflicts between different unit tests might happen
So we want our module to use something different - we call these objects test doubles (I actually like using mock/stub/dummy definition from G.Meszaros). The question is, how can we persuade our awesome module, to use a different instance during testing and different instance in production?
Dependency Injection is great for this - it wires all the pieces together (yep, it saves us lot of work) - and more than that, it does allow us to use different instances during testing. Yep, DI is just awesome! I actually think, that new languages such as Dart should support DI natively - in the same way as they do support memory management.
Unfortunately, there is no DI in Node, at least I haven't found any sufficient implementation. Writing a Dependency Injection framework is definitely a solution, but I was looking for something faster...
Read more...Asynchronous Control Flow with Promises
A Promise is an object that represents the result of an asynchronous function call. Promises are also called futures and deferreds in some communities.
Read more...Easy HTTP Mock Testing with Nock and node-tap
One of my first node.js libraries was nano: A no fuss CouchDB client based on the super pervasive request. In foresight that was a good idea, even though there's a ton of clients for CouchDB none of them is as simple as nano, and the fact that its based on request is great.
When you are writing a HTTP client you need to test with one (or several) HTTP endpoints. I was lazy about it so I choose to point nano to iriscouch and run the tests on real HTTP requests. This was a problematic but overall ok approach.
Then some weeks ago I started automating the tests using travis. And builds started to fail. To make this work and fix all the shortcomings of a direct connection to iriscouch. I needed a HTTP Mocking module.
By the way Travis is super cool. You should test all your node.js libraries with it. All you need to do is go to the site, sign in with github and place a .travis.yml file like this one in the root of your lib:
language: "node_js"
node_js:
- 0.4
- 0.6
Read more...Managing module dependencies
Following this discussion on the node.js mailing list about managing module dependencies, I thought it's worth sharing some pointers on that here.
Read more...A Simple Blog with CouchDB, Bogart, and Node.js
Update: By request I have posted a gist of the app.js using MongoDB instead of CouchDB. This gist also serves as a beginning example for how to use non-promise-based APIs with bogart.
In this article, you will learn how to use Bogart and CouchDB to create a minimal blogging engine. The Express with MongoDB article was a huge hit. This article has similar goals but shows a different way of using Node.JS.
Read more...Fun Putting Node on Mobile Devices
This article will walk you through creating an Ubuntu image that can be chrooted inside a mobile device like the recently released TouchPad. Once the Ubuntu environment is setup we'll learn how to compile and install node for fun and/or profit.
Read more...How To Module
UPDATE:
This article was written for Node v0.4.1 and is no longer applicable. As of node.js 0.6.3 NPM comes pre-installed.
These are some basic steps for writing a NodeJS module.
Most of the suggestions in this document are optional. You can definitely write your program however you like, and many in the node community enjoy trying out new creative ways of doing things.
This is merely a set of patterns that noders have found to work for them and their projects.
Read more...
