Digital Tumbleweed

• phonon (1)
• ssjs (1)
• tutorial (1)

You're a contributor here (Edit)

This is your Space (Edit)

Follow by email »
Get the latest updates in your email box automatically.

While posterous will not allow me to add JS to blackout my site, I figured I'd use this space to throw up some information for those unaware of these two bills.

Please, if there is one thing you do today. Educate yourself on SOPA and PIPA. It is extremely important.

https://www.google.com/landing/takeaction/sopa-pipa/

www.blackoutsopa.org/

sopastrike.com/

en.wikipedia.org/wiki/Main_Page

theoatmeal.com/

fightforthefuture.org/pipa/

PROTECT IP / SOPA Breaks The Internet from Fight for the Future on Vimeo.

If you do something else, get in touch with your congress people.

Posted

0 Comments

I've seen questions for this topic come up repeatedly so I figured I'd throw something down to refer people to. :)

If you're interested in NodeJS, and I'm betting that you are, then you'll be wanting to make a project. There area few things you can do. Many, not all, people in the NodeJS community use Git and Github for source control and hosting respectively. You'll do fine hunting around there for things people have made on Github. Alternatively, the NPM repository hosts stable versions of each module and provides some conveniences for installation.

At the start you may be tempted to just something like:

npm install module

I'd recommend against this. While it will work in a pinch. But, a better approach would be to use the package.json file. At first it seems strange to do so, but it becomes natural very quickly. With this approach you get the benefit of having a file you can check in. This means that you can throw it in your versioning system and once done, type:

npm install .


This will install your current project and all of it's dependencies. It makes it really nice when moving around machines. I usually work on two machines and then deploy on another. Having a file that makes installation easier is really nice. The file itself would looks something similar to this:

Note that you do not need to put your project in NPM. We're talking about managing your dependencies and other project information. However, one caveat is that this file needs to be proper JSON.

If you're interested in more, take a look by typing:

man npm-json

Hope that helps. Happy Hacking.

Posted

0 Comments

If you're looking for a coding tutorial you're in the wrong place, but if you'd actually like to learn NodeJS then stick around. This will cover the basics so that you can understand why things work the way they do. A base understanding is what you should start with. So, lets get into it shall we?

A Brief History - SSJS in the Making

Over a few recent years a handful of projects has tried to bring Javascript to the world of serverside programming: RingoJS, Axiom Stack (which I was involved with), Jaxer, and NodeJS among others. There are also a few javascript virtual machines out there: Rhino, V8, and Spidermonkey. This abundance of tools has allowed for those who really love Javascript to dive head first into server side development.

The project that has gotten the most attention for bringing SSJS is NodeJS. The attention it has received is largely due to two things: the way with which you write Javascript and the speed at which you can do so. You see, NodeJS set out to work through events and callbacks. What this means is that your traditional concepts around procedural programming were just thrown out the window. And, while functional programming has been around for some time, this is a wonderful blend of functional and evented development. There are arguments for and against this asynchronous approach, but I'm not interested in discussing that here. The point is to get you understanding it so that you can form your own opinions. So I'll explain why this works the way it does.

A Look at the Internals - The Event Loop

Events and callbacks are used because the core of node is an event loop. This means that you have a loop processing all of your code. If your code is procedural, step-wait-step-wait and so on, then you will eventually take up the entire event loop with your code and nothing else will be able to be processed. This would normally be fine, but most applications are complex that require some database interaction or writing to files. Additionally, you may need to send data across a network. This is where things get a little hairy. When you block the event loop you stop other code from executing and thus waste CPU cycles. The traditional example with node is this: if you make a database call then you have to block until you get a response from that database. This means that you cannot do anything else until that initial call has returned. This is known as blocking and will halt the event loop until it has finished.

var db = new DB();
var rows = db.getAllRows();
console.log(rows.length);

But, imagine this. You create a function that would take the result of your database call. Then you pass that function to your database call such that when the result set is returned, your function is fired off.

var db = new DB();
db.getAllRows(function(rows) {
    console.log(rows.length);
});

I'm affraid that this alone is not enough to keep the event loop uncloged. There are two things to note. The first is that the db library you're using needs to be using events. And the second thing is that you can still make enough calls that you reach the system limits for your event loop and clog it, but in most cases this is either bad design or a good problem that you solve with more hardware.

Evented Libraries

Libraries don't event themselves. The developers need to be cognisant of that approach when creating the library. For node this can be in either C/C++ land or in JS land. Either way the approach works using the notion of events. For instance, lets say that I have a database library. In this library I make a request for all the rows in the db using the connection. This could take some time so I want to make sure I'm not blocking other execution and thus take a callback as the parameter. In the getAllRows api I set my code up such that when the result returns from the database itself your callback is fired with the response from the server.

function getAllRows(cb) {
    conn.on('results', cb);
    conn.getRows(0, conn.length);
}

Although this is obviously a contrived example, you can see that what I've done is used an api such that when the results event happens, we fire the callback. Then, we make a call to the conn, db connection, object to get rows 0 - the size of the rowset. Although this isn't the most powerful example, it shows the essentials of an evented architecture. We just hang onto the callback in memory allowing the event loop to continue on with it's other tasks until we get a response from the database call, which is when we make our move. I've stated this point about 5 times by now I'm sure, but I hope it's really clear. This approach is asynchronous. That's 6. :)

How Does That Connection Become Asynchronous

If you look, there is an implicit assumption in the code above, that assumption is that conn itself is asynchronous. That works for my example, but it doesn't really explain anything. So, how does the connection become asynchronous? This comes back to node.

In node, we have something called an EventEmitter (refer to the link for the API). This is the backbone of eventing in node. The EventEmitter is a module whose backbone is libeio. This library provides the functionality needed to make your code asynchronous in NodeJS. The EventEmitter as a module provides you with publish and subscribe features so that you can make any code you write use events. So, the connection module would be required to use an EventEmitter in order to provide that asynchronous functionality.

A simple event emitter might look something like this.

Setting NodeJS Apart

What sets node apart from the competition is that there wasn't a set of libraries pre-built using other design paradigms. So, people have built a massive collection of libraries from the ground up to give you your chance at embracing the power within node. Hopefully by now you realize that you can do some awesome things using NodeJS. Armed with your new understanding here are a few links to get you started on codifying it.

• NodeJS Site
• How To Node
• Node Wiki
• NodeConf
• NPM - A Nod