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.

source: http://www.igvita.com/2011/10/20/faster-web-vs-tcp-slow-start

Your server can tell the browser that it supports SPDY in two ways: setting the ‘Alternate-Protocol’ header, or by using a TLS handshake extension NPN (Next Protocol Negotiation). In the second case the server will send the supported protocols (i.e., SPDY/2 HTTP/1.1 HTTP/1.0) to browser before any data transfer will be performed, and the browser will choose the protocol that is preferable for the client.

You can learn more about SPDY by examing the protocol specification: http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2

Node.js and SPDY

The growing interest in both the SPDY protocol and Node.js created the need for a stable Node.js SPDY module when the first version was released last year. There were a number of issues with this first implementation: it was buggy, it did not support the default node.js builds, and it was incompatible with popular frameworks (only partial express support, and no socket.io support at all). Despite all of these issues it still attracted considerable some attention from the Node.js community.

Before continuing development on node-spdy it was clear that node.js core needed to be improved: the tls module was lacking NPN support, and there was no zlib functionality. While adding NPN callbacks to node was quite simple, I found that almost every OS has old SSL libraries without support for it. That’s why latest node version bundles openssl in it’s deps/ folder. Thanks to Isaac Z. Schlueter, zlib module was added in 0.6.0 version of node.js, and required only a little patching: it was missing stream dictionary support.

With all that working out of the box (only in 0.7.0-pre version of node now) I decided to start developing a completely new stable node-spdy version. You can take a look at what I’ve done so far at https://github.com/indutny/node-spdy . Note that to test it you’ll need to build v0.7.0-pre of node.js (currently at github’s master branch):

  git clone git://github.com/joyent/node.git
  cd node
  [sudo] ./configure
  [sudo] make
  [sudo] make install

I have one running SPDY server running at https://spdy-twitlog.indutny.com/. It’s demonstrating socket.io + express support of node-spdy module.

Features & Roadmap

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.