Today Nodejitsu is excited to announce that we have acquired IrisCouch along with its suite of Database-as-a-Service and npm products. This acquisition continues to enhance our toolset for our Enterprise and Public Cloud customers. There is a related press release available on nodejitsu.com.

There are a number of reasons we are thrilled to bring IrisCouch into the Nodejitsu team:

Last October, Nodejitsu got together with our partners, Joyent, 10gen, Clock, and MongoLab, and brought you Nodestack. It was a one day online conference with the goal of examining the technology stack emerging around Node.js, and answering critical industry questions about adopting and maintaining this technology in your own company. The conference was a great success so we're back, and we're bringing you a series of smaller webinars to delve deeper into more specific technical matters.

Join us on Tuesday 9:00 AM - 10:30 AM PT for Nodestack: State of the Stack, where Charlie and Nuno will be holding it down with Isaac Schleuter and Aaron Heckman:

In our April 30th blog post, Nodejitsu announced price increases for customers running on Individual Plans on our hosting platform. You can find the new numbers and details of additional platform changes here. This post is a reminder that these changes are taking place, and a response to a few questions from our customers.

Initially we gave two weeks notice, and scheduled price changes for Wednesday May 15th. Many customers have felt this was not enough time. My team and I heard your feedback, and have pushed the changes out one more week. Wednesday May 22nd is now the day that our new prices will go into effect.

We also received questions regarding the ascending price of our plans. For example, some people have wondered why a Micro plan (1 drone) costs $9 whereas a Small plan (3 drones) costs $33 dollars. This is because our Micro plans (our lowest hosting tier), are being slightly subsidized. We want to continue encouraging experimentation on our PaaS, albeit at a higher price point than before.

In the same spirit of experimentation, Nodejitsu is upholding our commitment to offer a free drone, the equivalent of one Micro plan, to host an open source app to any node.js developer. You simply need to apply through opensource.jit.su.

Nodejitsu's success thus far is due entirely to the support of the node.js community. We understand these price changes have upset some of our customers, but these changes allow us to serve our community sustainably and continue contributing open source software to the node ecosystem. These changes also provide our small but talented team with an opportunity to improve our PaaS, dealing more quickly with production incidents and fixing underlying issues. The goal is to provide our customers with a better product. My team and I are excited to move forward towards a strong future for node, and we look forward to doing so with many members of the node community on our platform.

We are extremely proud to announce that as of May 9th, Ken Perkins is a new pkgcloud committer.

Ken has been putting great amounts of work into pkgcloud, including fixing Rackspace integration and a huge internal refactor which corrects mistakes we made when designing some of the low level APIs. We are extremely thankful for his help and dedication, so we decided to give him push access to our repository.

As of today we are announcing a new pricing structure for our Individual Plans that will take effect on Wednesday May 15th, 2013. The Nodejitsu platform has grown significantly since we launched our Public Beta last year and even more since we launched our Paid Individual and Business Plans. This growth has put us in a position where we need to make some decisive choices in order to create a sustainable future for our Public Cloud product.

Last week we announced OpsMezzo, a complete solution to provisioning, orchestration and configuration management geared towards enterprise customers. That annoucement reflects our commitment to OpenSource and the node.js community. In fact, more than 80% of the nodejitsu stack is now Open Source.

Our prices are the lowest in the Platform-as-a-Service market. Last year when we announced our pricing model we thought we could make this model sustainable, but this was built on several assumptions that turned out to be wrong. With this new model we will be able to keep our Public Cloud sustainable for years to come.

Please note: the changes we are about to discuss apply only to customers using Individual Plans on Nodejitsu’s platform and will not affect Business Plan customers.

After more than 18 months of work, Nodejitsu announced the release of OpsMezzo at TXJS this week, a complete solution to provisioning, orchestration and configuration management.

The majority of OpsMezzo is now available as Open-Source. A related Press Release can be found at nodejitsu.com.

Cloud computing has matured dramatically since Amazon Web Services launched in 2006. A dizzying number of vendors have emerged in the market to solve a wide spectrum of specific problems.

These products have matured over the years, but they are built on a fundamentally flawed thesis: the parts are more important than the whole. In others words: organizations are on their own to integrate individual products into a complete system. Yes, there is a large amount of source material available through blogs, tutorials, and training, but the manual integration work remains.

At it's core, this means that organizations running in "the cloud" are dealing with too many vendors to solve simple problems. Vendors using multiple languages, databases, operating systems and other operational internals. While we live in a polyglot world, the operational calculus of running these multi-vendor systems is challenging to even seasoned professionals.

At this point you are probably wondering: "What about PaaS solutions?" PaaS is great for individuals and organizations who do not have (or do not want to have) an operational competency. This concept of "NoOps", while attractive to some, is also fundamentally flawed:

1. Too simple for larger organizations: In order to present users with a set of APIs that are simple enough even for novices massive operational details are hidden. Larger organizations (especially those running their own datacenters) already have an operational competency, so the PaaS abstraction is just too simple.
2. Still too many vendors: Heroku pioneered the concept of "add -ons" and since then every PaaS company has been quick on their heels to copy that model. This leaves their customers paying too much to too many vendors with little-to-no visibility behind the scenes.

We saw these problems two years ago in the early days of Nodejitsu and set out to make OpsMezzo a complete solution built entirely on a single platform: Node.js + CouchDB.

Keep reading to learn more about how OpsMezzo can streamline and simplify your devops workflow. Or if you're interested in trying out OpsMezzo in your organization send an email to sales@nodejitsu to get a free evaluation!

On March 6th - March 8th, Nodejitsu experienced our worst service disruption to date. Following this series of outages, we immediately reallocated our Engineering and DevOps resources so as to properly assess the damage done and to fix some of our core infrastructure to ensure it never happens again.

In the time in between our outage and today we have overhauled our entire load balancing architecture, also known as Conductor. Below is a detailed look at our old load balancing system and our newly implemented solution.

Hi, earthlings! I'm Nathan Zadoks. I live in the Netherlands, not far from Amsterdam. I'm a self-taught programmer and electronics and chemistry enthusiast. I build small things and put them together. Functions. Programs. Objects.

From a young age, I've been fascinated with making systems do what I want. I fiddled with electronics and I learnt to program at age 7. I left VB for Perl, Perl for Python. I taught myself Linux, discovered the UNIX philosophy of simple, composable parts forming a powerful whole. I found node.js two years ago and loved how working with streams and composing small things was so very natural. Unfortunately, node wasn't as mature and thus I stuck with Python. About half a year ago I rediscovered node.js, the freedom of JavaScript and found the wealth of easily composable small modules in npm. This time, it stuck. (I do my best to help out with npm by triaging GitHub issues, patching small things and merging pull requests, occasionally frightening isaacs in the process.)

Over the course of Wednesday, March 6th through Friday, March 8th, Nodejitsu experienced its most serious service disruption to date. A significant number of users' applications were rendered intermittently unreachable due to load balancing and routing issues. Furthermore, a variety of circumstances combined that both increased the prevalence of the issues and prolonged the amount of time it took to reliably fix them. We consider the situation to have been completely unacceptable, and since then, the majority of our team has been working hard to ensure that it never happens again.

At this point, we'd like to take the time to explain what went wrong, and give some insight into some of the things we've been doing to make sure these issues don't repeat themselves.

At Nodejitsu we focus on providing our users with the best developer experience possible -- something we can't achieve if our sites take too long to load. This is why we focused on front-end performance when we rebuild our new front-page. The best front-end performance can be achieved by loading a minimal quantity of resources as fast as possible. So having a good static server is vital! Unfortunately serving static files isn't something Node.js is designed for. For example it's missing essential sendfile bindings which allow you to transfer files over sockets with minimal context switching. The only way to create a high performance file server in Node is to cache aggressively.

Today we're pleased to announce the release of my latest open source project, versions.

Since we announced our paid Individual Plans in October of 2012 (5 months ago), thousands of you have deployed to Nodejitsu, gotten in touch with us in IRC, and tested our platform to see what its made of. We’ve gotten to see what horizontally scaled 256MB slices of virtual machines can do, and how far node can take us in the world of DevOps. But our Individual Plans were always intended for small, lightweight apps. We all wanted more.

Today, we’re very excited to announce the launch of our Business Plans, fueled by a new partnership with Telefonica. Business Plans deliver greater reliability and selection for small to medium companies who are looking to host mission critical applications.

What makes Business Plans different?

Flexible VM sizes for increased reliability

Business Plans give you the ability to select the size of the VM that you’re deploying to. Business Plan customers will be able to choose between 256MB, 512MB, and 1024MB VMs. This significantly increases reliability, and reduces the complexity and degree of horizontal scaling required to handle increased load.

It'll look a little something like this:

$ jitsu deploy joyent us-sw-1 --drones 2
info:    Welcome to Nodejitsu jitsuka
info:    jitsu v0.12.0, node v0.8.19
info:    It worked if it ends with Nodejitsu ok
info:    Executing command deploy joyent us-sw-1
info:    Fetching app nodejitsuftw
info:    App currently deployed to
data:    {
data:        datacenter: 'us-east-1',
data:        ram: 256,
data:        drones: 1,
data:        provider: 'joyent'
data:    }
info:    Deploying application in cloud with:
data:    {
data:        datacenter: 'us-sw-1',
data:        ram: 256,
data:        drones: 2,
data:        provider: 'joyent'
data:    }
info:    App example is now started
info:    http://nodejitsuftw.jyt.us.sw1.nodejitsu.com on Port 80
info:    Nodejitsu ok

Choose your infrastructure provider, and datacenter

You now have the choice of Telefonica and Joyent, and a variety of datacenters to deploy to. As of today, we have support for Joyent’s datacenters in Virginia, Las Vegas and Amsterdam, and Telefonica’s datacenter in London.

For example:

$ jitsu cloud list
info:    Welcome to Nodejitsu jitsuka
info:    jitsu v0.12.0, node v0.8.18
info:    It worked if it ends with Nodejitsu ok
info:    Executing command cloud list
info:    You can use one of the following providers
data:    jitsu cloud joyent us-east-1
data:    jitsu cloud joyent us-sw-1
data:    jitsu cloud joyent eu-ams-1
data:    jitsu cloud telefonica eu-london-1
info:    Nodejitsu ok

This means you can choose your location, and reduce your app’s latency to your customers that matter.

$ jitsu cloud joyent us-sw-1
info:    Welcome to Nodejitsu jitsuka
info:    jitsu v0.12.0, node v0.8.19
info:    It worked if it ends with Nodejitsu ok
info:    Executing command cloud joyent us-sw-1
info:    Fetching app example
info:    App currently deployed to
data:    {
data:        datacenter: 'us-east-1',
data:        ram: 256,
data:        drones: 1,
data:        provider: 'joyent'
data:    }
info:    Deploying application in cloud with:
data:    {
data:        datacenter: 'us-sw-1',
data:        ram: 256,
data:        drones: 1,
data:        provider: 'joyent'
data:    }
info:    App example is now started
info:    http://example.jyt.us.sw1.nodejitsu.com on Port 80
info:    Nodejitsu ok

High Performance Webops

All of these new features are also available in our Webops dashboard which has gotten a complete overhaul to engine.io.

Full support for Europe!

These new features, and our partnership with Telefonica mean one more thing: we now have full support for Europe. Telefonica, one of the world’s largest Telecommunications companies, has recently launched its Instant Servers, offering Joyent’s cutting-edge cloud technology to users from its own, growing selection of datacenters. Combined with Nodejitsu’s unparalleled Node.js PaaS, this will enable Node-based sites and apps to server users in the European market like never before.plans

Ready to take your hosting to the next level? Let's do this!

Wait...did you think that was it?

Just in case that’s not enough for you, we also launched a new, improved version of our frontend website, Nodejitsu.com. Our rebranded site is meant to make it easier to understand how our product works, and who we are. We also think it looks a whole lot slicker.

Thanks for hosting with us! We’re glad to have you on board.

Monitoring sucks, right?. At Nodejitsu, we run a large distributed system with next-to-zero external dependencies. Designing a monitoring solution that met our needs of:

• Able to handle thousands of messages per second.
• Scaling to accommodate the dynamic needs of thousands of applications.
• Flexibility to make decisions based on various criteria.

was challenging. In fact, it is something we've tried to address in several implementations. Over the past two years, it was clear the team that we needed something new. Today we are happy to announce that we are releasing this new solution, godot as Open Source software under the MIT license.

The team at Nodejitsu knows what its like to maintain open source software. We all want to see a thriving OSS community, so as part of our service, we'll provide you with a drone to host your open source app on Nodejitsu for free.

We first discussed this when we launched our Paid Individual Plans, back in October. Now we've streamlined the process!

Meet opensource.jit.su:

As we say on the page, just fill in your info, and our team will get back to you soon. Big thanks to Julian Duque and Karolina Szczur for the design and code. We're looking forward to hearing from you!

Please allow me to introduce myself, my name is Julián Duque and I'm from Medellín, Colombia, a beautiful city also known as the "City of the eternal spring". I'm a Telecommunications Engineer and a Software Development Specialist, but most importantly, I consider myself a Developer by Passion. I chose this title because coding is what I enjoy doing in my life on a daily basis. I believe that software should be made by passion, not by obligation.

Say hello to Nodejitsu's new Status Page!

On the Status Page you can get info at a glance on how the cloud is doing. We wanted to give everyone a central place to go where they could check on the status of Nodejitsu services. After all, no one wants to spend valuable time debugging an issue that's actually caused by problems that Nodejitsu is experiencing. Is there any better way to blame someone else than through a beautiful web page? I'm joking. Kind of.

Last month we announced Continuous Deployment with Github and Nodejitsu. Since then we've had thousands of people using this new feature and the overall feedback from our community has been amazing.

Today we are announcing Deployment Status Badges. When you're using Continuous Deployment on Nodejitsu, these let you know instantly if the deployment is in progress, has been successful, or has failed.

Today, we would like to announce that from now on you can deploy your open-source Github repositories directly to Nodejitsu.

How does this work? By implementing a Github service for Nodejitsu, you will now be able to deploy your open-source application anytime you push a commit to Github.

But that's not good enough Continuous Deployment you say? We have also added an integration with TravisCI so that you can also deploy your open-source application only after a successful test run.

Open-source is a core value at Nodejitsu. We all maintain several open-source modules that make the node.js community a better place, and promote high profile projects like flatiron and http-proxy so we want to make sure that Open Source developers have the best experience available for deploying their application.

Keep reading to learn all the details about getting setup with Continuous Deployment on Nodejitsu!

You may have noticed some changes to the Nodejitsu Handbook on Github. That's because we've completely revamped the entire handbook thanks to the new version of blacksmith.

During the play.node() conf earlier this week in Korea, Charlie took the stage and released our newest open source module. We're excited to introduce pkgcloud!

Pkgcloud is a node.js module that allows interaction with multiple cloud service providers. With the help of this module, you're able to manage a variety of cloud resources from within your application. You can provision compute, storage or database instances with ease.

IaaS providers have each chosen their own vocabulary for describing the resources they provide, leading to inconsistencies in terminology from one to the next. One of the objectives of pkgcloud is to maintain a unified vocabulary and use a regular terminology for applications without users needing to know which term was chosen by which provider. This is part of our ongoing efforts to be Infrastructure Agnostic.

Node Knockout is just a few hours away and Nodejitsu is proud to be the official contest deployment platform! As everyone is gearing up to get into the ring, here are some helpful reminders.

Don't want to hack alone?

Take a look at the NKO locations page for hosted backspaces around the world.

If you're in NY, the Nodejitsu team has partnered with Levo League to provide a chill, comfy space with healthy meals and drinks just south of Union Square. RSVP here.

Node Knockout Deployment Instructions!

As you’ve probably heard, our partners at Joyent are expanding their PaaS efforts with Nodejitsu! This means that if you're an No.de user, Nodejitsu is stepping in to continually support all your deployment needs.

Nodejitsu offers newer versions of node, great customer support, features like WebSockets and multi-cloud options (coming soon!) all on the best operating system to run your node.js application: SmartOS Joyent SmartMachines.

If you want to ensure that your application keeps running continuously, you should follow our upgrade instructions before October 30th.

Here’s what you’ll need to know.

Nodejitsu is happy to announce our Paid Individual Plans are now available.

When Nodejitsu entered public beta, we shared our approach to Platform-as-a-Service pricing, and our commitment to changing the way that Platform-as-a-Service companies incentivize developers. Today's announcement reflects that commitment and we're pleased to have you try Nodejitsu today for free in our Development Sandbox. And when you're ready you can upgrade to one of our Individual Plans starting at just $3.

(Please note: at this time we are only introducing Paid Individual Plans. Our Business Plans will be available for purchase soon!)

Here at Nodejitsu, we live for the node.js and Javascript community. Honestly, without them this company wouldn't exist. This commitment often results in many members of the Nodejitsu team speaking at events around the world. I was privileged enough to be invited to two such events in China and Lisbon this past month. In booking my travel I actually circumnavigated the globe and I thought a few of our users might be interested in stories of the JS community worldwide!

As of this past Tuesday, Marak Squires is no longer an employee of Nodejitsu. As one of the founding members of the company, Marak has been an integral part of what Nodejitsu has built so far, and changes like this are never easy.

Over the last two years, as the business and team have grown, the founders’ ideas about management and policy grew to be at odds. Starting a company takes passion and strong personalities, but eventually company disagreements spilled over into being too personal. In order to maintain a healthy, respectful work environment, we felt we needed to separate ourselves.

To clarify, Flatiron is a Nodejitsu initiative. While Marak has been one of its key architects and proponents, his departure from the company does not mean the end of Flatiron. Quite to the contrary, the Flatiron framework and associated tools are used to power many key parts of Nodejitsu’s cloud offering. Flatiron will remain open-source, and our commitment to free open source software with non-restrictive licenses remains steadfast. We will continue to collaborate with the node.js community to build and innovate Flatiron.js.

Marak’s contributions to Nodejitsu, as well as node.js in general, have been innumerable. His evangelism in the early days was instrumental to helping many people find and embrace node.js - including several key members of our team. Perhaps most importantly, his unique and outgoing sense of humor has been an important part of our team morale, as well as the spirit of the node community in general.

This has been a very difficult decision, but one which had to be made so that we could continue to build and grow Nodejitsu into what we believe it can be. We will always be grateful for Marak’s contributions and we hope the node.js community will continue to benefit from his talents.

In computer science, reflection is the ability of a computer program to examine and modify the structure and behavior (specifically the values, meta-data, properties and functions) of an object at runtime - Wikipedia

The Flatiron framework is designed to help with the rapid development of robust isomorphic JavaScript applications. Flatiron is built on the node.js philosophy of small, distinct, usable components. Every component of the framework can be used independently, for it's own distinct purpose.

A couple weeks ago we discovered that a little site called now.jit.su was absolutely blowing up on Nodejitsu. The project, entitled This Is Now, is a real time Instagram feed from 8 different cities around the world. It was crafted by Lexical Gap, a Sydney-based team of creative technologists made up of Marcio Puga, Mauricio Massaia, and Per Thoresson.

Recently, many things changed at nodejitsu, including the introduction of several long-awaited features. Here's a brief overview of what happened and how it affects you.

We love encouraging hackers to push their skills to new heights. That's why we've decided to help out with the js13kGames competition as the official deployment platform and prize sponsor.

Last week Nodejitsu CEO, Charlie Robbins told the audience at Nodeconf that we would be moving into Public Beta very soon. I am happy to announce that public beta has arrived!

Nodejitsu is now available for all. You can sign up for Nodejitsu and will immediately be placed in the Development Sandbox without having to wait for an activation.

Node.js has grown so much since I started working with it sometimes I can't believe it. Not just the awesome community, but the core APIs.

Maintaining software is no walk in the park: writing modules is at once the most rewarding and most difficult thing you can do. I'm often reminded of what isaacs once said on the nodejs mailing list:

It's like having children. Seems like a lot of pointless busy-work, and then you do it, probably without meaning or wanting to, and then suddenly fall so in love, you can't understand why everyone doesn't go as nuts over this little food-to-poop converter as you do. If you're not careful, you'll end up writing 3 or 4 more.

This article represents the lessons learned from writing node modules since node@0.1.103.

Last weekend Charlie Robbins and I ran Hack Your Way to NodeConf, a 17 hour overnight hackathon to give away our last ticket to the sold out conference. The winner would receive the ticket for NodeConf, airfare, and hotel (bonus: the chance to party with us). It was a huge prize and there could only be one winner.

Hi, my name is Farrin Reid. I love developing awesome software, tinkering with open source hardware, and trying out new hobbies. I am most intrigued by automation, strong AI, and all fields of science. I am excited to be working at Nodejitsu as one of the team.

Not so long ago we've blogged about conferences we're planning to attend. But since face time with the community is really important to Nodejitsu, there's another batch of events we'll be visiting and organizing.

Today Nodejitsu is happy to announce our Public Cloud Pricing, which will become widely available in the next few weeks.

It has been a long time coming. We have been working on making Nodejitsu the best-of-breed Node.js platform with outstanding cloud orchestration and infrastructure tools to back it up for over two years. In that time, the Node.js community has grown organically into a vibrant group of dedicated professionals from all over the world. They are focusing on the right problems: creating and improving software and tools that set the standard for innovation.

Our commitment to the community remains steadfast and the pricing for Nodejitsu is designed to only further the goals of the community and our customers.

Our plans are designed to service both Individuals building non-critical applications or experiments and Businesses who need dedicated resources for hosting mission critical applications.

Individuals

Businesses

It may be surprising to you that Nodejitsu is not offering an unlimited free tier. This is intentional. The choice represents our deeply held belief that competing Platform-as-a-Service pricing models are doing damage to developer communities everywhere. We do not want to be part of the same problem.

Logging seems like it should be simple enough, but when you're dealing with multiple machines, multiple nodes, and multiple apps which all need to log in some kind of organized fashion, things can get complicated very quickly. To make things more interesting, not only do these things need to log, but they need to manage and access the logs as well.

---

A year and a half ago, Winston was created in an attempt to unify all potential logging transports. While winston serves its job well, another project needed to be added to the equation to help solve the problem mentioned above.

Winston's success has been defined by it's ability to instantiate loggers and add multiple different transports to each one.

I'm sure it would be easy enough to whip up your own logger which simply creates and writes to a file stream, but, obviously, there is more to winston than just a single transport. The portability is key, along with the extensibility of any transport imagineable.

While the logger above is great, and winston carries all the extensibility in the world, you're still stuck with one logger inside one process. Kind of like an in-process database: it's great, and simple, until it becomes its own obstacle, and gets in its own way.

One day you're using sqlite, and everything just works, until you need massive amounts of webscale; direct intravenous injections of pure webscale. All of the sudden, in-process doesn't cut it, and you need a server. This is what led to the creation of winstond.

Hi, my name is Elijah Insua. I have a deep interest in node and javascript in general. In my free time I build computer controlled machines and make my own pcbs for hardware projects. I enjoy playing / building games, experimenting with the countless modules on npm, and keeping up with web standards. I have been acquainted with the nodejitsu co-founders since before nodejitsu and this is my story!

Lately, I've noticed quite a few people asking to see examples of flatiron apps in #nodejitsu. Now, there are actually quite a few of our projects that use flatiron extensively. Unfortunately, there are a few problems, chief among them that no two flatiron projects do quite the same things or are organized the same ways.

Now, this isn't necessarily a problem when it comes to building tools. In fact, I think it's a great demonstration of flatiron's flexibility. Each project can use exactly the libraries and organization that make sense for their applications, even for apps as different as haibu and jitsu. It can be confusing for newcomers, though, that are used to frameworks that enforce stronger conventions, or those that are trying to figure out how to get from "hello world" to something more profound.

I thought what would be helpful for flatiron newcomers is an in-depth tutorial, which iterates on a "hello world" flatiron server (like those in the project's examples) into a relatively complex webservice that uses some of flatiron's more complex functionality.

In this tutorial, I'm going to create a webservice for browserify, a popular client-side code framework for node.js. All of the code is on github, and every section of this tutorial corresponds to a code commit. In early parts of this tutorial I will show all the code, but as it gets longer I will typically explain the code with links to the relevant files/commits on github.

At Nodejitsu, we are always on the lookout to find great javascript conferences that revolve around awesome communities.

We are also co-hosting two events in April: The Node Philly Conference and the NYC MongoDB Hackaton and speaking at three more!

Here's our schedule: be sure to say hi and hangout.

At Nodejitsu, we spend a lot of time and resources on open-source software development. Before founding Nodejitsu, the three of us were all active open-source enthusiasts and developers. Tools like Github helped bring us together to better understand each others techniques and technical skill-sets. Events like NYC.JS, Music Hack Day NYC, and the first Node Knockout helped solidify the team.

Now, after three years of toiling away on Github, we have now expanded our engineering team to over fourteen strong and every Nodejitsu developer is an active contributor to the open-source community.

• How to become an open-source developer?
• How do you get recruited as an open-source developer?

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

Over the last few months I've been using flatiron and by extension broadway.

I like broadway a lot, so I'd like to take this opportunity to explain how it works and why you should be using it.

Here are a few phrases and bits of jargon that tend to pop up when discussing broadway:

• Inversion of Control
• Dependency Injection / Feature reflection
• Application extensibility

In this post, I'm going to explain what the mean, how they work in broadway, and why they're a good thing.

More after the break!

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.

So we research...

Fault tolerant system
Fallacies of Distributed Computing
Properties of distributed systems
High availability Percentage calculation

and we research more...

Shared nothing architecture
Byzantine fault tolerance
Paxos

Eventually, we hit the The Halting Problem:

Given a description of a computer program, decide whether the program finishes running or continues to run forever. In 1936, Alan Turing proved that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist.

to summarize all of these links in the context of this blog post...

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.