pattern (github, p on npm) is a way to iterate javascript collections with asynchronous functions using a technique called pattern matching.

Command-line interfaces (CLIs) are an often overlooked, but extremely important part of every developers workflow. Think about how different your day-to-day life would be if git functioned differently? Or (gasp) incorrectly or inconsistently? At Nodejitsu, we know CLI applications. The CLI for our public platform jitsu is designed to be quick to get started, highly portable and above all: consistent and robust. With these principals in mind we took extra care designing Flatiron to be adaptable to our production-quality needs.

Flatiron is an adaptable decoupled framework for both node.js and the browser. An adaptable framework enables users to build multiple types of applications. In Flatiron we are focusing on:

• Web applications (http and websockets)
• Command line (CLI) applications
• Front-end applications

This article will focus on the tools at your disposal when using Flatiron to build CLI applications as well as how many existing Flatiron CLI applications are structured.

• Getting started
• To the code!
• Configuring your Command-line Application
• Composable Command-line applications
• Flatiron Command-line apps in the wild

You may know about SPDY, an experimental protocol for a faster web http://www.chromium.org/spdy/spdy-whitepaper announced by Google in 2009. SPDY is now supported by two major browsers (Google Chrome and Mozilla Firefox) and it’s running on most of Google’s servers (also soon to be supported by nginx).

The main goal of SPDY is reducing the latency of web pages by multiplexing multiple http streams into one TCP connection and compressing http headers.

So instead of creating a TCP connection for each http request (like styles, scripts, images, or even ajax), SPDY-enabled browser will hold only one connection with the server.

Github: https://github.com/flatiron/blacksmith
Documentation/Example: http://blacksmith.jit.su

Blacksmith is a static site generator. It uses weld, jsdom and marked to turn json, markdown and 100% genuine HTML and CSS, on the filesystem, into awesome sites like the one you're looking at right now. Moreover, it includes a command line interface for quickly building, editing and testing blacksmith-built websites. Here's a short list of features:

• Easy to use
• Can be hosted anywhere, since it generates static HTML/CSS
• Write and Edit articles on the file system using github-flavored markdown
• Based on JSDOM and Weld
• Easily create custom themes using plain HTML and CSS ( no micro-templating ! )
• Default theme is a port of scribbish by Jeffrey Allan Hardy
• Ships with a robust node.js static server suitable for production

Blacksmith may remind you a bit of jekyll and octopress, and in fact it is influenced by these projects. However, whereas jekyll is "blog-aware" and uses liquid for templating, blacksmith uses the DOM for its templating needs and can easily generate not just blogs, but documentation sites and more. Plus, you don't need ruby or rake since it's all written in node.

As part of my ongoing quest to develop Skynet, I've been thinking a lot about the decentralized storage and distribution of small amounts of state in a peer-to-peer environment. With new privacy laws, the internet is fundamentally changing in a way we have not seen before. It's up to us, the developers to make sure the internet remains a fair and open place.

In software application development we usually store application state in volatile and non-volatile random access memory. We also use network devices to communicate state between our application and a central provider or server. We store state in things like databases, the file-system and cloud hosting providers. This approach is recommended for most applications, but when we start to think about the implications of building large, distributed, and decentralized applications, we begin to rethink about how these applications are going to store and maintain state.

In some way or another, almost anything can store state. Any device that can be written to, then read from later can be used to store state.

Think of it like this:

There are hundreds of thousands of endpoints on the web right now that you can post some sort of data to, and read it back later. Why not make a database out of that?

As part of my ongoing quest to develop Skynet, I've been deep diving into distributed computing.

At Nodejitsu, our node.js hosting platform deals with 1000s of live servers spanned across multiple data-centers. As scale increases, minute statistical probabilities become very real problems. The network is unreliable, disks become unwritable, streams break, unexpected input is unexpected, and entire data-centers can go down.

Think of it like this:

If you have 1,000 servers each individually rated at 99.9% uptime, on average, one of those machines is always failing.

npm is the node package manager.

It helps you manage your node.js modules and dependencies.

Previously, we created a npm cheat sheet describing various NPM commands.

Now, here is a package.json cheat sheet for exploring various properties of npm's package.json format.

Enjoy the package.json cheatsheet!

If you watch flatiron repositories on GitHub, you may have started noticing these:

These are Travis CI build status images. We started testing our code at Travis CI and we want to tell the whole world about it!

npm is the node package manager.

It helps you manage your node.js modules and dependencies.

Here is a quick cheatsheet of all my favorite npm commands:

• Installing npm
• Update npm
• Search for npm packages
• View details of a npm package
• Installing a npm package locally
• Installing a npm package into an application
• Understanding Global versus Local installs in npm
• Global Package Installation
• Uninstalling a package locally
• Uninstalling a package globally
• Installing a specific version of a package
• Cloning a module from Github
• Linking any npm package locally
• Linking local npm packages to multiple applications
• Unlinking a npm package from an application
• Unlinking a npm package from your system
• Create a new npm package
• Creating a new user account on npm
• Publishing a npm package
• Unpublishing a npm package
• Managing owners of packages

This post was originally written for my personal blog, http://jesusabdullah.github.com, while writing documentation for the Flatiron framework. Flatiron's documentation is not 100% up-to-snuff yet, but we're following standards and guidelines very similar to these as we fill in the gaps.

---

So you're writing a module. Cool! Are you ready to document it? I'm here to help.

I'm no expert on readmes. I have, however, read a lot of readmes (both good and bad), written my fair share of readmes and documentation, and---most importantly---have formed strong opinions on what I should see in a readme.

This post focuses on the "first pass" for your readme. These PROTIPS are applicable, however, to readmes of all ages.

What is product? At Nodejitsu our definition is simple: product is what our users are consuming every day. It doesn't matter if it is our Platform-as-a-Service, nodejitsu.com, or if it is one of our many open source libraries. This definition is why from very early on at Nodejitsu we decided to treat our open source libraries with the same level of attention and care that we do our public Platform-as-a-Service.

Successful open source libraries and initiatives require the same kind of attention to branding that many think is reserved for profit focused products. In other words, Open Source Doesn't Just Market Itself. Lets explore how discoverability, time to start (i.e. how long it takes to use what you've built), community, and some good old fashioned hustling can help build Open Source brands.

Web development is all about choices. What language do you want to use? What database? What libraries? No matter how you develop web applications these choices have to be made. When using large frameworks in other languages such as Ruby or PHP most of these choices are made for you. In Node.js we have npm, which has allowed a diverse ecosystem of modules to develop. This has fostered a philosophy of creative experimentation, but not made it any easier to make these choices.

This is the motivation behind flatiron. At it's core flatiron is two things:

An initiative to build a collection of decoupled tools with the same standard of quality and performance that you would expect from anything built by Nodejitsu.

A full-stack web application development framework which packages these tools together to make isomorphic and stream-based application development easier.

This article will introduce you to the components that make-up flatiron as well as how the core flatiron project.

You're smart. You know your way around your laptop and your iPhone. Maybe you spend more time in excel and powerpoint than on the command line. You're not an engineer but you've played with some HTML and CSS. Maybe not. Point is, you've been hearing about this Node.js thing and you want to know if it's for you. Maybe I can help.

First, just a little about me... in July I joined Nodejitsu as COO. What's that mean? For the purposes of this discussion, not a whole lot. What's more important is that I'm an application developer and I'm new to Node. In this post, I'll discuss a lot of the things that attracted me to Node.

Take a minute and think about how often you've heard the phrase "Model-View-Controller" (or MVC). Do you really know what it means? At a high-level it is about a separation of concerns between the major areas of functionality in presentation-centric applications built on retained graphics systems (i.e not-raster graphics, such as games). Dig a little deeper and it becomes obvious that it is just a bucket term for a lot of different things. In the past, most development communities built-out an MVC solution that worked well for their most popular use-case and moved on. Great examples of this are the Ruby and Python communities with the MVC-based architecture Rails and Django both embody.

This approach has been acceptable for other languages such as Java, Ruby, and Python it is simply not good enough for Node.js for one reason: Javascript is now an isomorphic language. By isomorphic we mean that any given line of code (with notable exceptions) can execute both on the client and the server. On the surface this seemingly innocuous property creates a number of challenges that are not solved by current MVC-based patterns. This article will explore some of these existing patterns, how both their implementation and concerns vary across languages and environments, and how they are not good enough for a truly isomorphic Javascript codebase. In conclusion, we will explore a new pattern: Resource-View-Presenter.

• Site: http://docs.nodejitsu.com
• Github: https://github.com/nodejitsu/docs

A few weeks ago we released http://docs.nodejitsu.com, just in time for Node Knockout! docs.nodejitsu.com is a collection of community written tutorials and how-to articles for node.js. There are over fifty articles so far, from the basics all the way up to more difficult topics. We like to think of it as our unofficial, non-competing entry into NKO. We also, of course, hoped that the actual competitors would find it useful.

When the Node HTTP Proxy was built, its purpose was performance. The concept of a stream in Node lends itself beautifully to working with HTTP requests - HTTP requests are, after all, TCP streams in the first place. One of Node's strengths is its facility for streaming data, and a great deal of performance can be achieved simply by piping the request and response streams to other destinations, and back again. This, therefore, was how the HTTP Proxy was designed - and it does its job well.

The problem here is that the extremely popular middleware style of web application development is often incompatible. If you use a body decoder middleware, for example, every request will need to be buffered in full before the body can be properly decoded. This increases memory usage and reduces performance, compared to simply relaying un-altered requests and responses to other destinations - it all has to be waited for, read into memory, possibly altered, then sent again, adding to both the time and resource cost of each request.

In a follow-up to my previous blog about getting started with hook.io, I created five additional video tutorials on how to spawn hook.io hooks and child processes in your hook.io cloud. I've also created a youtube account you can subscribe to for more videos.

You can also find a mirror of these videos @ https://github.com/hookio/tutorials

Enjoy!

Exploring the Core API

1. #12 A quick lesson in fault tolerance Part 1
2. #13 A quick lesson in fault tolerance Part 2
3. #14 Spawning child hooks Part 1
4. #15 Spawning child hooks Part 2
5. #16 Full-featured child hook spawning with Haibu and Haibu-Carapace
6. #17 Using Hook.io to Install NPM Packages Anywhere

hook.io is a full featured i/o framework for node.js. hook.io allows you to create clouds of node.js processes which seamlessly communicate with each other to form fault-tolerant distributed systems.

hook.io is a radical departure from how web applications are currently being built. hook.io itself is very easy to use, but the concepts behind it can be hard to understand from only reading the documentation and unit tests.

For this reason, I have created eleven short video tutorials for explaining the basic usage and functionality of hook.io

You can also find a mirror of these videos @ https://github.com/hookio/tutorials

UPDATE: 6 more videos on Spawning hook.io Hooks

DOUBLE UPDATE: Due to popular demand, I have converted and uploaded all videos to youtube. You can subscribe here: http://www.youtube.com/maraksquires

Enjoy!

1. The Basics Part 1
2. The Basics Part 2
3. The Basics Part 3
4. IRC Hook Configuration Part 1
5. IRC Hook Configuration Part 2
6. 3 Minute IRC Bot
7. Hook.io Libraries
8. HTTP Webhook Server
9. Socket.io Bridge to Browser
10. Emit events from CouchDB _changes feed
11. Extending an existing application

I'm happy to announce that Nodejitsu will be available as an official option for your Node Knockout entry. You will need a Nodejitsu account, so if you haven't gotten one yet, you can try joining #nodejitsu on irc.freenode.net to get your account activated...

In my ongoing quest to make lists with my name on them, I've setup a site to view the top 100 NPM ( Node Package Manager ) module creators. In this article I will go through the current top ten and give a quick bios for each person.

Warning: These numbers should not be used for anything meaningful, and are possibly wrong. The data is pulled from http://search.npmjs.org and uses SubStack's nifty tool: npmtop

Hourly tallies can be found here: http://npmtop.nodejitsu.com

  Generated: Fri Aug 19 2011 08:41:16 GMT+0000 (UTC) 

  rank   percent   packages   author
  ----   -------   --------   ------
     1    1.85 %     62.00    James Halliday
     1    1.85 %     62.00    TJ Holowaychuk
     3    1.59 %     53.00    AJ ONeal
     4    1.05 %     35.00    Dominic Tarr
     5    0.90 %     30.00    Isaac Z. Schlueter
     6    0.87 %     29.00    Marak Squires
     6    0.87 %     29.00    Nickolay Platonov
     8    0.72 %     24.00    Charlie Robbins
     8    0.72 %     24.00    Felix Geisendorfer
    10    0.66 %     22.00    George Stagas

This is Part three of a four part series leading up to Node Knockout

At Nodejitsu we believe in sharing knowledge. We believe that open source software fosters innovation, relationships and offers in return something better than the sum of its parts; a continuous growth cycle. If we tell you our good ideas, you'll make them better. Now go back two steps and repeat this process.

Passionate open source projects, we understand that they should be both engineered and crafted. A patient attention to detail and refinement in our products and platform remains our methodology. These characteristics: open, crafted, and connected have evolved into the current incantation of the Nodejitsu brand.

I remember when I had no open-source projects and I had never even heard of Github. To me, the maintainers of open-source projects were mystical beasts who only existed in ethereal form over the internet. If I needed to get support for a library, it required hours of Googling, disabling the client-side gateway for ExpertsExchange, and begging random friends over AIM for help. Usually, I would wind up either giving up completely, repeating the process by picking a new library, or applying an awful hack to make the library work for my specific situation.

It was only after I had begun to heavily use Github and Node.js that I realized these mystical beasts were actually real people, who work very hard on their projects, and generally strive for quality feedback so they can improve on their work.

Unfortunately, as I now help maintain and contribute to over 100 open-source projects, I've seen a lot of inappropriate behavior from developers trying to seek support. I think much of this behavior is unintentional. There are not a lot of guidelines for developers to follow who are new to open-source. In this article, I will dive into many of the common issues open-source project maintainers encounter and I will help developers better understand how they can file for a refund on the open-source project they are using.

We're very happy to officially announce we will be hosting an NYC location for Node Knockout 2011 at General Assembly (902 Broadway, 4th Floor) in Union Square. For those that don't know, Node Knockout is a 48-hour, team coding contest featuring node.js. There will be beverages and snacks on hand as well as team Nodejitsu and a few other tech startups to help you out in the usage of their APIs and tools.

This is Part one of a four part series leading up to Node Knockout

The distillation of a philosophy to coding in a particular language (or environment) takes time, trial and error, and above all a group of extremely talented and dedicated professionals. Most of the ideas central to this philosophy are not new to the practice of Software Engineering or the study of Computer Science, but merely the selection of choices that appear often in the community with motivation from choices made in node.js core. With best efforts, sources and references will be supplied to support the arguments made here.

You first may ask "has there been enough time?" Node.js is still very much in its infancy as put so eloquently by Isaac Schlueter (author of npm) earlier this year at NodeConf. That is, Node.js has barely been around for two years. It may be therefore premature to write this, but there has the immense growth seen in both node.js core and in the ecosystem surrounding it. Nodejitsu has been intimately involved in this growth and thus, in the opinion of the author, enough time has passed for a few granules of truth to trickle through.

Node.js is best known, of course, as a tool for building and serving awesome webapps. After all, that's what Nodejitsu is all about!

However, if you talk to Node.JS users you may hear something along the lines of, "Javascript is actually pretty nice for writing command line apps." As it turns out, node.js is a great platform for writing command line applications, and with npm they are as easy to install---nay, easier---than similar programs written in ruby or python and installed with rubygems or pip. In addition, node.js has all sorts of helpful libraries for writing command line apps, such as prompt, optimist, and cliff, that make writing command line interfaces easy!

Here, I hope to showcase a few of the command line apps written in node.js. Many of them are still written with web development in mind. They are all written in javascript, and they are all used from the command line.

This is Part two of a four part series leading up to Node Knockout

Nodejitsu is very happy to announce the latest stable version of hook.io. This release marks a combined effort from the Nodejitsu team working across six time-zones and four countries. But what does this mean for the application developer and what is hook.io anyway? Hook.io is a full-featured I/O framework for node.js that enables a simple way to distribute your application across multiple node.js processes using the new EventEmitter2 API and leveraging the power of Crash-only software.

In a nutshell, hook.io allows you to split your node.js program into multiple worker processes, that will be automatically restarted upon any user-generated faults, allowing you to increase performance and fault-tolerance. Interested in learning more? Read on!

Nodejitsu is looking to hire a systems engineer with expert knowledge in Linux server administration and systems programming. At Nodejitsu, we deploy 100s of servers at a time in seconds from our node.js command line tools. We then monitor, manage, and heal these servers in real-time using...our node.js monitoring and deployment framework. We also write a lot of open-source software. see: http://github.com/nodejitsu

Hi, I'm Dominic Tarr. I am a Mad Scientist from New Zealand. I live in a tree, sail around in a boat and hack Node.js. Historically, I've only worked for ninja themed companies, and recently I have started contracting for Nodejitsu. Here at Nodejitsu, there are always a couple of Mad Science projects on the go. Normal people might call these "side projects", but Mad Scientists don't do "side projects".

We do Mad Science.

Hey, I am Nico Reed and I work as an intern at nodejitsu. I am majoring in math with a minor in computer science at BYU. I have been hacking on several of nodejitsu's projects in the last two months and here are some of the things I have done:

Right off the bat on the very first day, I got assigned to modifying the blog code. If you go to the blog homepage and look at the very awesome RSS feed button on the right, that was my very first thing I did for nodejitsu. It took a few hours to do the very simple two line change, but in the process I learned Wheat, Haml and more about Github and I got the change pushed to production the very same day!

http-server is a simple, zero-configuration command-line http server. It is powerful enough for production usage, but it's simple and hackable enough to be used for testing, local development, and learning.

Here at Nodejitsu, we believe strongly in supporting the thriving open-source community around us, and one of our more popular open-source tools is node-http-proxy. It is full-featured, robust, and extremely easy to use - not to mention battle-hardened by ongoing production use at nodejitsu.com. The request that loaded this page, for example, was routed to our blog by http-proxy.

This guide is geared toward beginners and people who are unfamiliar with reverse HTTP proxying, websocket proxing, load balancing, virtual host configuration, request forwarding, and other web proxying concepts - those who already know what they're doing and just want to see the syntax should skip down to the sample code.

At NodeJitsu we know how important it is to build quality open-source software and when there is a problem with one of our projects, we want to fix it. We also know that often the right solution involves reaching out to the community and helping contribute to other people's libraries. When we found out there were bugs in our STMP client library, node_mailer, we wanted to find what was best for both ourselves and the community. We decided to research the current landscape for node.js mailers and try to make an informed descision. Since our library is mostly concerned with creating an easy API for sending mail, we wanted to look at alternative solutions for a solid SMTP implementation.

In this article I will discuss our approach for fixing the node_mailer library and how we actually helped fix issues in another mailer project along the way.

This is part one of a three part post on npm

Dependency management. Need I say more? Entire developer ecosystems live and die by how dependency management works. Ask a Ruby developer what they would do without RubyGems, or ask (most) Java developers how to get things done without Maven. Most importantly: ask a node.js developer how to get things done without npm.

Npm recently received a pretty serious makeover in Version 1.0. If you haven't read up on what changed between 0.3.18 and 1.0, you should read Isaac Schlueter's (or simply @isaacs), the author of npm, blog post now.

Npm installs modules and applications based on an interpretation of the package.json specification. The most important part of this is how it determines the which version(s) of your dependencies to download. In this article I will examine:

1. How npm works with dependencies in a package.json manifest.
2. Best practices for specifying modules and node.js dependencies.

While I was at nodeconf, I caught some of Henrik Joreteg's b-track talk which was an introduction to Single Page Apps. Node.js is a great platform for Single Page Apps because of it's real-time capabilities. This is a subject that has been obscured and confused by buzzwords and FUD. Henrik had a limited time to talk, so let's revisit this subject.

I've been working with and contributing to the node.js community since 2009. I've authored a lot of modules, I've help recruit a lot of good people into the community, and I'm fortunate enough to have regular communication with all the core members. I remember when node's FS module required three nested asynchronous calls with insane arguments to actually read or write a file. I remember having to beg people like Ry, Isaacs, Polotek, Mikeal, binary42, inimino, Jan, and Tim Caswell ( to name a few ) to teach me the basics. I remember when node was an obscure project with little support or documentation. Since my first days in 2009 I've done everything I can to help promote and improve the usage of node.js.

For all of these reasons I list above, I become considerably disappointed when I see an article like this appear on IBM Developer Networks. I can understand that node.js is still a relatively new technology ( it's not even v1.0.0 as per SemVer yet ), but that is no excuse for an industry leader like IBM to allow such a blatantly misleading article to appear on their site. It's not my intention to single anyone out, but it's apparent that the author of the article has a limited understanding of node.js, has performed a trivial amount of research, and most importantly has no understanding of how open-source projects work in the age of Github.

Normally if I encounted such an unresearched and misleading article on the internet I'd just ignore it. Unfortunately, I can't ignore this. IBM is a serious name that people trust. To have an article on IBM.com spreading misinformation about node.js is wrong. IBM needs to update or remove this article. In this blog post I will distill and address the main points which are "wrong" in IBM's article

Dependencies are the careful balance between modularity, reuse, and ease-of-use. When working with Nodejitsu (and node.js in general) dependencies are managed through the package.json dependencies property. Creating a package.json is an important step in node.js application comprehension. For more information on this checkout npm and our CLI tool jitsu, both of which will help you understand creating package.json files.

Making sure your package.json has all the right ingredients is important! Nodejitsu is happy to announce the release of a simple and elegant tool for determining and analyzing your dependencies, aptly named: require-analyzer. This post will walk you through how to use the library as well as outline our jitsu integration and upcoming npm integration.

Beyond all of the hype that you might be hearing about node.js these days at it's core it has always been about one thing: fast network programming. This aspect of node.js is why we created and have maintained node-http-proxy for almost a year now. The project has matured with contributions from notable members of the community and a lot of maintenance from yours truly; we have been working on this since node.js 0.1.98 afterall.

This article marks the release of node-http-proxy v0.5.0 which has some breaking changes to make the API more extensible for the next WebSocket and HTTPS support. We'll be reviewing changes since v0.3.0, which is still in use in many environments. tl;dr? Checkout the Changelog for the project.

If you have been following our blog, you might have noticed I've been posting a lot of "amazing news" entries. This entry is no exception.

It's a JavaScript Trampoline Party at the House of Air!

We'll be giving out 25 free tickets!

There is also Trampoline Dodgeball!

4/28/2011 between 7pm-9pm

Nodejitsu is sponsoring a small kick off party in San Fransisco the week before JSConf and NodeConf. Our team will be at both conferences and we'll sponsoring / speaking at NodeConf. We are doing training sessions before and between JsConf and NodeConf, so please be sure to sign up if you haven't' already.

So back to the Trampoline Javascript Party....where is it going to be? What is the House of Air? Who will the lucky 25 be that get to go...

It seems like every developer has their own (passionate) opinion about how software should be tested:

• "I would kill myself without BDD"
• ZOMG! How could you write software without TDD!?!
• "Testing? Meh. I try to have unit tests..."

I think more developers than not fall into the mindset of the last quote; we want to test our software but we don't have the time, or resources to make 100% test coverage a reality. The underlying fact behind this dirty secret is that testing can be quite difficult and requires the utmost dedication to flesh out completely.

This excess of verbosity and difficulty was the motivation for writing APIeasy: a simple tool for writing BDD tests for any REST API. This article will explore a sample API written in node.js and how it can be tested with APIeasy.

As part of my ongoing series of amazing news, I'm proud to announce Nodejitsu, in conjunction with the fine folks @ Bocoup, will be hosting three upcoming training workshops about our favorite technology...Node.js!

These workshops will be in: New York, Boston, and Portland ( before NodeConf ) on the following dates:

• April 23 : New York, New York
• April 30 : Boston, Massachusetts
• May 4th : Portland, Oregon

The training workshops will feature members of the Nodejitsu development team walking through a full day program that will take you from the basics of async programming in JavaScript all the way to running an entire Node.js stack in production.

Morning

• From the Browser to the Server
• Characteristics of Async Programming
• Buffers, Streams, and EventEmitters
• Speaking HTTP like a Native
• File System
• Assertions
• Async Iteration

Afternoon

• Getting started with npm
• Lets build a Web Service
• Routing with Journey
• Relax! with Cradle and Resourcer
• Serve Static Assets with node-static
• Handle session and cookies
• Logging with Winston
• Get Real-(time) with Socket.io
• Testing with Vows
• Go Prod with Forever and Cluster

Nodejitsu is looking to hire three individuals for paid internship positions in the following locations:

• On-site @ Nodejitsu Corporate offices in Union Square, Manhattan ( at General Assembly )
• On-site @ Nodejitsu's West Coast Hack Haus in Lower Haight, San Francisco
• Telecommute ( international may apply )

Nodejitsu is a platform as a service and marketplace for Node.js applications. We build a lot of cool and complex software using cutting edge technologies and we maintain a lot of open-source projects. Check out our github page or hop into #nodejs on irc.freenode.net to find out more. Compensation will be a competitive hourly rate based on experience. Full-time and part-time are available.

Responsibilities:

• Become a master of Node.js and JavaScript
• Help maintain and contribute to Nodejitsu's open-source projects
• Build your own open-source projects
• Work directly on Nodejitsu's platform and production stack
• Help promote Node.js through informative blog posts and tutorials

So you're thinking about using node.js: awesome. If you're new to the community you're probably thinking "what's the best node.js module / library for X?" I think it's really true when experienced language gurus say "80% of your favorite language is your favorite library." This is the first in a series of articles will give you a high-level overview of some of our favorite node.js libraries at Nodejitsu. Today we'll take a look at these libraries:

1. cradle: A high-level, caching, CouchDB library for Node.js
2. findit: Walk a directory tree in node.js
3. node_redis: Redis client for node
4. node-static: RFC2616 compliant HTTP static-file server module, with built-in caching.
5. optimist: Light-weight option parsing for node.js
6. xml2js: Simple XML to JavaScript object converter.

Good news everyone! As part of a series of amazing upcoming news, I'm proud to be reporting from Nodejitsu's brand new West Coast Hack Haus in San Francisco! Our main corporate headquarters will remain in Manhattan at the very awesome General Assembly, but we just couldn't resist getting a West Coast presence. Anyone from the original NYC.js days at the old Pivotal Labs offices will remember some of the JavaScript parties we had in New York and I hope to continue this tradition in San Francisco.

Don't like that title? You probably disagree. That's because "micro templating" is a subject of contention. Everyone has their own idea of how it should work. People argue about which engine is N milliseconds faster than the next, or why one should use curly braces instead of angle brackets. A divided community rearranges the deck chairs on the titanic. In this article, we explore the ineptitudes of traditional micro templating. As well as demonstrate how Node.js can untangle the mess.

ends up getting parsed, evaluated, and regurgitated as... Even worse. lets say you are a front-end developer or maintainer. You're inspecting the DOM, trying to find out why a style is only sometimes wrong. You deduce there are conditions in the HTML! Now you need to look at the file on the server. Goodness! There's some cryptic syntax in that markup! You could trace hundreds of lines of Python or Java, but you're a front-end developer, so forget that. Consider it a wild goose chase and file a bug. you can go node.js FTW. Code...

I've been studying the node.js ecosystem for a little while now and while the pace of library and module development has been astounding, the pace of application development has been a bit slower. The primary reason for this is simply that node is young and until recently the API has been a fast moving target. As node and it's many libraries start to mature, a lot of people have been asking, "What are the killer node.js applications?" In this article, I create a list of what I feel are ten "killer node.js applications" and then dive ways in which they can be implemented.

1. An instant message application that can be included on any webpage with one line of JavaScript
2. A chat room application that can be included on any webpage with one of JavaScript
3. A real-time multiuser sketchpad
4. A file and media drop box
5. A streaming Twitter client
6. A blogging / Content Management System
7. An online project management tool with Vows / Cucumber integration.
8. A social bookmarking application
9. A browser based hackable and family friendly massive multi-player game.
10. A Micro-wiki application with distributed version control

I recently gave a talk at ADICU Devfest 2011 on node.js. The talk was aimed at Computer Science students who did not know anything about node.js and more importantly, how to get started building simple and elegant web services from scratch. The slides (and code) from my talk are available on GitHub.

This article will walk through the code that I presented to build a simple RESTful bookmarking API using node.js and:

• Journey: A liberal JSON-only HTTP request router for node.js
• Cradle: A high-level, caching, CouchDB library for Node.js
• Winston: A multi-transport async logging library for node.js
• Optimist: Light-weight option parsing for node.js

Before trying any new technology, the first thing I do is try and find it's IRC room. If you don't know what IRC is, consider it a chat room for weird computer programmers. My first day trying node.js was also my first day in #node.js on irc.freenode.net. I was greeted by several friendly node enthusiasts and got lots of help getting my first node code working. Coincidentally, also on my first day, November 23, 2009, Debuggable starting running logs for #node.js.

In this article, I will dive into the #node.js log files, find out who the most active users are, and then follow their online handles to reveal who they are.

# Notable Top 25 Most Active Users Part of what makes node.js great is it's community. The most active people in the #node.js IRC room are some of the most talented and prolific contributors to the project. I've taken the liberty to match up some of the most active online IRC handles to their real-life equivalents. The results are pretty amazing.

This is Part Two of a two part post on logging in node.js — In any language there are a lot of options when it comes to logging. The issue that we saw at Nodejitsu, was that all of these libraries coupled their storage mechanism of choice (files, databases, etc.) to the API that was exposed to the programmer.

This was the motivation behind winston: a multi-transport logging library for node.js. A transport is essentially a storage device for your logs. Each instance of a winston logger can have multiple transports configured at different levels. For example, one may want error logs to be stored in a persistent remote location (like a database), but all logs output to the console or a local file.

This is Part One of a two part post on logging in node.js — I think every developer has a love/hate relationship with their log files. They love them when they have to debug, optimize or fix a problem, but they hate setting them up and later distributing, aggregating and searching log files. There are a lot of utilities out there for managing your logs, but one caught our eye at Nodejitsu: Loggly. That's why we're happy to announce the release of node-loggly: A library for interacting with the Loggly API.

Building Nodejitsu has been a lot like building a house, or a spaceship, or maybe even a synthetic super human. But let's use an analogy that everyone understands: it was kind of like building a house. The first step was to lay a solid foundation. In the same analogy, branding could be thought of as house paint, and house paint was the last thing on our minds.

Well it's that time of the year again and as the gifts are being given out I thought that it was time to give a gift of our own: a slew of updates to a few of our open source node.js libraries. There are some breaking changes in these updates, so check out the changelogs here, here, and here. Also, you can read the rest of this post for a quick summary of what's new.

One of the great benefits of using node.js is the reduction in dependencies needed to run a production web application. By using the 'http' module we can run a stand-alone web server in node.js without the need for a separate server like Apache or nginx. The caveat of not having to use these servers is that their concerns are now the concerns of the node.js application developer. The concern that we will discuss in this article is that of fault tolerance, or how to automatically restart your server when it crashes or enters an invalid state.

# Stopping and restarting with Forever To illustrate that Forever will automatically restart a child process that exits, lets kill the process ourselves:

Session management is a major piece of any serious web application. When building a site, it is likely you will want the ability to persist a user's identity over multiple requests without having to have them re-login again and again. A common method for persisting a user's login over multiple http requests, is called setting a "cookie". Now almost all web developers have some idea of what a cookie is, but in this article we will dive into the specifics of actually implementing a cookie / session persistence system from scratch in node.js through exploring the session.js library and the response library.

After countless test servers, long nights of coding and a laundry list of open source projects the Nodejitsu private beta is officially live. It is a welcome coincidence that today is the 20th anniversary of the World Wide Web because we believe that node.js is the future of the web and web development. We are excited to share this initial look into our product.

Sending emails is a classic software development problem. At some point, your application will need to send an email to someone. node.js has the ability to open arbitrary tcp sockets, so with node_mailer, we can easily connect to an existing SMTP server and start sending out emails.

With over a million members, there is an amazing pool of open-source developers on Github across a wide range of projects. More amazing is how Github has changed the technical recruiting game. The day's of resumes and references for developers are slowly dying. All the work I've gotten in the past year has been a direct result of my github account. I send potential employers my Github account first. They can see a history of the work I have done, the influence that work has had (followers / forks), and my coding style and abilities. Github introduces a transparency that has never been available before.

In my ongoing obsession of finding top tier developers I came across an article by Matt Biddulph called "algorithmic recruitment with github". He released some basic code for calculating the social influence of a user based on a geo-graphical location. I immediately was hooked. I got the code running with a few minor modifications and ran: "New York"

the top 5...

1. thoughtbot
2. nakajima
3. webiest
4. marak
5. enormego

Awesome! I placed 4th, but I noticed jashkenas was missing from the list. I had figured he would have placed in the top five as well...

I decided further research was required and ran the script against the following locations: Chicago, Boston, California, San Francisco, Los Angeles, San Diego, San Jose, Palo Alto, Portland, Oakland, Seattle, Florida, Alaska, Montreal, Toronto, Canada, Russia, Moscow, Ukraine, Uruguay, Chile, Japan, Taiwan, Korea, India, China, Israel, Argentina, Brazil, England, London, Germany, Spain, France, Switzerland, Sweden, Australia, New Zealand

UPDATE: Due to high demand, webservice.js is now under active development. You should also visit the Github to get the latest documentation code

Creating easy to consume web-services is a common problem in modern day computer science. Many web developers have had some experience either creating a web-service or building a client to consume a web-service (such as the Twitter API).

Using a node.js router like Journey, we can easily define maps for a basic JSON web-service. We can hard-code a few routes, assign each one a different request handler, and then write integration tests between our new Journey router and our business logic. The problem with this approach, is that it requires writing a lot of code, which requires a lot of development time.

If we enforce some very reasonable conventions and draw on a concept from Coldfusion, we can start creating robust web-services with one line of code.

Whatever your opinion of prototypical inheritance in javascript, from a marco level it is clearly important when one considers DRY throughout a given codebase. The node.js 'sys' module exposes a simple way of accomplishing inheritance through sys.inherits. In this article we will explore how this method works and how you can use it to create more robust and modular code in nodejs.

A question that often comes up to me is: 'How do I get started with Node.js?' The first step is to setup your local developer environment, which is a little different depending on your platform of choice:

• Linux: Installing Node.js on Ubuntu 10.04
• Mac OS X: Installing Node.js on OS X 10.6
• Windows: How I got started with Node.js on Windows
  
  

Screen scraping has been a focus of engineering for quite some time. Every major language out there has their own library of choice for performing these tasks:

• Ruby hpricot, nokogiri
• Python beautiful-soup, scrapy
• Perl pQuery
• PHP PHP DOM

The challenge with using these libraries is that they all have their own quirks that can make working with HTML, CSS and Javascript challenging.

We got the chance to compete in a 48 hour node.js programming competition last week called "node knockout" and it was amazing! we've launched two open-source projects kyuri and prenup, which were very well received by the community.

I recently ported an IRC bot that I wrote from Python to node.js and took the opportunity to try BDD for the first time. My results were very positive. BDD seems to play out a lot like a unittest, but with much more readability.