ealing with files and handling uploads is an ugly reality in web applications. It can be even more unpleasant if you application is driven by REST APIs. In days passed, it often came down to flash uploaders talking outside the api and someone having to link multiple data sets together. I was always partial to the fantastic FancyUploader Library. Fortunately, things have gotten better. Node, and Hapi make dealing with incoming files much easier. More over, Tastypie & Hapi make this exceptionally easy to do this in a single Api Endpoint. To illustrate this we are going to build up a small Api to store and save some binary data.

To accomplish this, we need to do 4 things:

ommand Line tools are an important component to development, administration and maintenance of most all software projects - large or small. A good command line tool greatly speeds up repetitive operations through simple and flexible abstractions.

The Node.js community has a number of tools out there for quickly building out a command line interfaces, commander being one of the more popular. However, most all of them suffer from the same set of problems, making them difficult to integrate into applications in a clean an re-usable manner. Primarily speaking, there is no way to separate general functionality, from a command, from the argument parsing, or a command from the command line tool itself. This makes building for code re-use

oggng is one of the those things that many developers don't put much thought towards until it is a little too late. Having some kind of audit trail of what the application behavior, state, and any errors that may occur is critical to developing and maintaining complex systems. However, javascript developers are typically accustomed to just peppering `console.log` when ever and where ever they see fit. During development this may seem like a fine idea, but this quickly proves to be a insufficient logging solution.

Firstly, the console interface in Node writes to one of the standard outputs in the host system, which may or may not be captured so you may inspect it. There is also no

ode.js ( and more recently io.js ) has put javascript as a programming language on a fast path. We have seen more improvements and advancement in the last 2 years that we have seen in the previous 2 decades. ECMAScript version 6 ( ES6 ) or `harmony` bring a lot of interesting and very useful features. One of the more useful, and oddly enough, confusing features is the introduction of generators and iterators.

The idea of generators and iterators are not unique to javascript. In fact that are fairly common in other programming languages. The Python language is very well know for it wide support for generator / iterator support. In fact it ships with module dedicated to creating and dealing with

onfiguration is an important piece to not only making your application deployable, but flexible and accommodating to change. We can't predict how an application will need to accept configuration between a local setup, build servers, staging and production. More over, if any of those things were to change, large parts of the application would need to change how it handles configuration. Some systems prefer files, some prefer environment variables some prefer command line arguments.

The Basics

A production ready application should be able to collect configuration from multiple sources and reconcile them into a single entity that is referenced throughout the application. We're going to walk through a sensible way to do this. The first thing we need to

n previous installments of Summer Of Sockets, we took a look at the basic messaging socket types in [ZeroMQ](http://zeromq.org), **PUSH**/**PULL**, **PUB**/**SUB** and **REQ**/**REP**. Each of these types provides different patterns of messaging between their connected peers. Up to now, we have been passing simple message around to illustrate the patterns. In larger, more complicated applications, the message will need to carry more information.

In JavaScript, that typically means constructing, passing and parsing JSON objects, as well as accounting for missing fields, and event embedding message types and meta data about usage into object. This quickly becomes messy and overly complicated.

JSON is a fine data format, but ZeroMQ provides a very handy facility

ode is still pretty young platform and people are still trying to figure out the best way to build large projects with it. With its highly modular core, and an even more modular ecosystem, it is easy to get lost in the variety of ways to go about anything.

I'm starting this series of articles about my experience in building production ready node projects. We'll be talking about structure, conventions, packages, and all around good things to do. To start, let's talk about one of the less talked about topics in the ecosystem, but in my mind, one of the more important - Project Structure.

Project Structure

The biggest step for new Node.js developers is to think in

one of the things that makes ghost great is it's almost forced simplicity. However, with that comes a bit of rigidity. If you want something more than the provided simplicity, you might find your self pulling your hair out. Search is one of the thing that is lacking from the default ghost set up. The last incarnation of my blog had everything indexed in a Xapian search index. I really wanted to bring back a local search index. Luckily, in the 0.5.x series, they pulled some string so that you can use ghost as a plain npm module. This means you can build your own app around ghost. This should make search possible.

Xapian is a search

t has been about 3 years since I launched my blog. At the time the tech was pretty interesting. It was a Django project on mongrel2 app server backed by ZeroMQ and xapian as the search engine. I built out a modular Web UI with a WYSIWYG editor using mootools. But it was rather clunky in how it actually generated HTML and usually required some manual tweaking.

Out With The Old

The WYSIWYG Editor was probably the biggest problem. It took serious liberties in cleaning the HTML and usually resulted in me editing the code by hand in the end. Interesting code blocks with highlighting was a 3 step process and was almost always formatted wrong.

Managing Images was

o far we have looked at PUSH/PULL and REQ/REP. One of the more interested socket combinations in ZeroMQ is PUB/SUB. PUB/SUB has multitude of real world applications in distributed systems, Ranging from remote Work Queues, Push notifications for real time web applications, inter-application communications, etc. Like other socket types found in ZeroMQ either each the pub and sub socket types can either bind or connect to an endpoint. It is really a matter of your applications use case. In general, the part of the application that will have the greatest up time would bind to a port and all others would connect.

There are two primary difference with the PUB/SUB sockets over the previously