Plotting Good Things in Portland :: pdxbridge.js / WTF Databases /

Several people got together yesterday to start planning things for 2014 in PDX. It ranged from coding workshops to PDX Node to Node PDX to what kind of food to eat at for lunch. Ya know, daily tactical things that come along with the big picture items. đŸ˜‰

bridge.js badge.
bridge.js badge.

Two things that I want to bring up to the community out there. One is a workshop that I’ll likely lead efforts to organize and the other is something I’ll just call pdxbridge.js for now. The workshop will cover the topics of which and what databases to use for what data and how to implement. The pdxbridge.js project is about determining the raised or lowered state of the bridges here in Portland.

Some of the other projects, workshops and other topics we discussed included getting a workshop put together around unit, integration and testing code from a behavioral, test driven development or other approaches. This workshop we don’t have anyone to teach, but we’d (ok, so I really really would love to attend a workshop on this) really like to find somebody who would be willing to teach a workshop of this sort, with a focus on Javascript as the language. On that same topic however, if you’re into Java, Erlang, Scala, Haskell or others and would like to teach a TDD, BDD or related testing workshop please get in touch with me. We will work on making that happen! Ping me at adron at composite code dot com. đŸ˜‰

Workshop: Intro to Databases & Data

(Relational, Key/Value, Distributed, Graph, Event Series, etc.)

This is a course I’ll lead and others will work with me on to put something extra useful together. We will then teach the workshop as a group, kind of a team paired programming teaching workshop. If there is anything in particular that you’d like to learn about, any questions that you have about data and usage in applications or otherwise add your two cents on this blog entries comments. Over the next month we’ll be putting together the material and have the course available sometime early this year. So if you’d like to attend, jump in at any time with the conversation or just keep a read here and I’ll have more information about the course as we get it put together.

Let’s Make pdxbridge.js Happen!

The pdxbridge.js project is all about determining if a bridge in Portland is up or down. Right now there are  several bridges that matter, that are on this list;

If we add other information to track about the bridges we might add the other 3 that exist and the new bridge that is being built. however the five listed are the only bridges that have a raised and lowered state, and in one case the Steel Bridge has a lowered, partially raised and fully raised state. As shown on the pdxbridge.js badge I threw together (shown above).

To get involved with pdxbridge.js go add your input on this issue I started to discuss our first meet, plan and hack.

2013 Dies, 2014 Lives… To a New Year!

My feelings on new years resolutions is pretty dry. Namely, I think they’re rather stupid. The main reason being this, if one is only checking their life, place and accomplishments once a year they’re forgetting most of them and remembering little if any accomplishments. It reminds me of the hierarchical nonsense of western European derived management culture. Something that is horribly out of space, time and element in today’s world. It has really shown it’s age but refuses to let go and disappear.

But, in humor of the past, to humor the age old hierarchical notions of the past, present and future. He’s my cheers to 2013 as it dies and my cheers to 2014 and what may come. First, what’s been done. As I was saying, I’m not a fan of wait a whole year to review things, and I’ve done plenty of reviewing over the last year. That’s include making hard decisions and kicking some serious ass. I’ve made huge changes, not just in my life, but in the direction I’m heading in my career (if you’d even call what I do a career, there isn’t exactly a defined path).

Accomplishments

I haven’t worked for a company in 4 months. I’d want to stop doing that for many months and strike out and try something of my own. Run a startup, build a startup, work as a purely individual contractor and contributor or something. Something were I wasn’t collecting a set pay check by a set company that could at whim do whatever it wanted with me, the project and such. I wanted a truly greenfield effort and a greenfield gig. So what did I do?

Beer

I sat on my porch for 2 months, enjoyed the waning summer and drank a few beers. Amazing and tasty brews from local brewers in San Francisco, Portland, Seattle and a few other locations. Most of them, from right here in the beer capital of the world Portland, Oregon. I spent a few evening just hanging out with friends, fellow coders, metal heads and musicians at heart at Bailey’s Tap Room. A lot of hanging out there, but it went further then that. I jammed with a multitude of street musicians, hoodie donned and pulled to. It was very enjoyable.

During all of this time I didn’t really throw a lick of code. I didn’t implement anything. I didn’t even really think that much about stuff. I read a few things here and there and did study a little bit. But mostly I just did a lot of hanging out, sitting, chilling and introspecting about what I wanted to do next.

The Changes: Change #1 a Calendar

After that 2 months of getting all fat and happy. Just enjoying life and pondering all that is the first big change happened. It’s kind of stupid, but it is a huge change for me. I updated my calendar to actually reflect what the hell I’m doing. I’ve made a point in the last 2 plus months to keep it up to date too. It’s amazing how much easier the day to day is when the calendar is up to date. It seems like a small thing. Something of the “well no shit Sherlock” category of obvious. But it has indeed shifted the way I work and the way I stay organized for the better.

The Changes: Change #2 Fukkit, OS-X & All the OSs it must be. Windows is officially dead to me.

With the last few months at Basho I’d bought an X1 Carbon, using mostly with Ubuntu but also having Windows 8 loaded on it. Windows 8 I grew to not just dislike, but loathed the horridness of so many things. It was Windows 7, with a nasty UI and stupid UX thrown on top. It took decades of UI know how and turned everything upside down.

So I killed it. I killed it dead. Ubuntu was the only US for me at that point but I wanted more. I wanted a high res screen (minimum of 1920×1080 work space at least) that I could do video editing and video rendering on. The Ubuntu and Carbon wasn’t cutting it for that. I wanted to be able to write OS-X, iOS, Windows or whatever code I wanted being able to switch between whichever OS on an efficient OS. The only one that enables all of that is OS-X with VMware Fusion loaded on it (or maybe Parallels or such). So I said to myself, screw it, get back on board that Apple wagon. I still had a Mac Book Air, but it wouldn’t cut it for all the needs, so I upgraded to a Mac Book Pro Retina with 16GB RAM and an i7. This sucker screams and does every single things I want. Change #2, easy, just plunked down a giant chunk of money and it was done. Whew.

The Changes: Change #3 Hedge My Work Decision, Then Decide on Something.

The final decision of this year was the biggest I’ve made in some time. I started doing some contract writing for blogs, all while checking into a few cool companies around Portland. I also started discussions with Aaron Gray about a prospective business. While looking at becoming the Vice President of Engineering for one company with an exciting product, writing blog entries and working with startups to help determine their paths, and looking at just doing simple contract work building out some large scale systems something came up.

Aaron and I decided to kick off Deconstructed.io. Yup, I’m co-founding a startup with Aaron Gray. Do you know him? Follow him on the tweetersphere @agray.

The Changes: Change #4 Yup, I’ve changed my blog theme again. It’s not a big deal, but it should be much more readable.

Happy new year to all, keep kicking ass and putting up the good fight.   \m/  \m/

Some JavaScript API Coding With Restify & Express & Hacking it With cURL …Segment #2

Ah, part 2! If you’re looking for part 1, click this link.

Review: In the last blog entry I went through more than a few examples of using cURL to issue GET requests against various end points using Node.js & Restify. I also covered the basics on where to go to find cURL in case it isn’t installed. The last part I covered was a little bit of WebStorm info to boot. In this part of the series I’m now going to dive into the HTTP verbs beyond GET.

POST

The practice around issuing a command via http verb to save data is via a post. When you issue a post via cURL use the -X followed by POST to designate a post verb, then -H to assign the content type parameter. In this particular example I’ve set it to application/json since my payload of data will be JSON format. Then add the final data with a -d option, followed by the actual data.

[sourcecode language=”bash”]curl -X POST -H "Content-Type: application/json" -d ‘{"uuid":"79E5591A-1E54-4562-A276-AFC266F54390","webid":"56E62C3A-D6BC-4F4F-B72A-E6CE081190B6"}’ http://localhost:3000/ident%5B/sourcecode%5D

Other data types can be sent, which the content type can be appropriately set for including; html, json, script, text or html. One example of this same command, issued with jQuery on the client side would actually look like this.

[sourcecode language=”javascript”]
var data = {"uuid":"79E5591A-1E54-4562-A276-AFC266F54390","webid":"56E62C3A-D6BC-4F4F-B72A-E6CE081190B6"};

$.post( "http://localhost:3000/ident", function( data ) {
$( ".result" ).html( data );
});
[/sourcecode]

When building post end points via express one of the things you may run into is the following message being displayed in the console.

[sourcecode language=”bash”]
/usr/local/bin/node app.js
connect.multipart() will be removed in connect 3.0
visit https://github.com/senchalabs/connect/wiki/Connect-3.0 for alternatives
connect.limit() will be removed in connect 3.0
[/sourcecode]

The immediate fix for this, until the changes are made (which may or may not mean to just alwasy  is to replace this line

[sourcecode language=”javascript”]
app.use(express.bodyParser());
[/sourcecode]

with these lines

[sourcecode language=”javascript”]
app.use(express.json());
app.use(express.urlencoded());
[/sourcecode]

So here’s some common examples for use from a great write up on writing basic RESTful APIs with Node.js and Express from the Modulus blog.

[sourcecode language=”javascript”]
var express = require(‘express’);
var app = express();

app.use(express.json());
app.use(express.urlencoded());

var quotes = [
{ author : ‘Audrey Hepburn’, text : "Nothing is impossible, the word itself says ‘I’m possible’!"},
{ author : ‘Walt Disney’, text : "You may not realize it when it happens, but a kick in the teeth may be the best thing in the world for you"},
{ author : ‘Unknown’, text : "Even the greatest was once a beginner. Don’t be afraid to take that first step."},
{ author : ‘Neale Donald Walsch’, text : "You are afraid to die, and you’re afraid to live. What a way to exist."}
];

app.get(‘/’, function(req, res) {
res.json(quotes);
});

app.get(‘/quote/random’, function(req, res) {
var id = Math.floor(Math.random() * quotes.length);
var q = quotes[id];
res.json(q);
});

app.get(‘/quote/:id’, function(req, res) {
if(quotes.length <= req.params.id || req.params.id < 0) {
res.statusCode = 404;
return res.send(‘Error 404: No quote found’);
}

var q = quotes[req.params.id];
res.json(q);
});

app.post(‘/quote’, function(req, res) {
if(!req.body.hasOwnProperty(‘author’) ||
!req.body.hasOwnProperty(‘text’)) {
res.statusCode = 400;
return res.send(‘Error 400: Post syntax incorrect.’);
}

var newQuote = {
author : req.body.author,
text : req.body.text
};

quotes.push(newQuote);
res.json(true);
});

app.listen(process.env.PORT || 3412);
[/sourcecode]

This is a great little snippet of code to use for testing your curling against just to check out.

References:

Some JavaScript API Coding With Restify & Express & Hacking it With cURL …Segment #1 (with some Webstorm to boot)

So often I end up putting together some RESTful services (or the intent is to at least build them with that premise, but we all know how that ends up). The API URIs routing gets put together and one wants to take a crack at the service as soon as possible. Here’s a quick guide for using cURL to take some basic actions against the services and understand what you’re getting back.

The first thing to do is make sure you can run JavaScript, which means you have a computer. The second thing is to get cURL, which means you’re running some variant of Linux or UNIX. In most scenarios one would be running OS-X. The easiest way to determine if it is installed on your computer just open up a terminal and type ‘curl –help’. You should get a result with all the switches, which is almost always a bit of overload.

[sourcecode language=”bash”]$ curl –help
Usage: curl [options…]
Options: (H) means HTTP/HTTPS only, (F) means FTP only
–anyauth Pick "any" authentication method (H)
-a, –append Append to target file when uploading (F/SFTP)
–basic Use HTTP Basic Authentication (H)
–cacert FILE CA certificate to verify peer against (SSL)
–capath DIR CA directory to verify peer against (SSL)
-E, –cert CERT[:PASSWD] Client certificate file and password (SSL)
–cert-type TYPE Certificate file type (DER/PEM/ENG) (SSL)
–ciphers LIST SSL ciphers to use (SSL)
–compressed Request compressed response (using deflate or gzip)
-K, –config FILE Specify which config file to read
–connect-timeout SECONDS Maximum time allowed for connection
-C, –continue-at OFFSET Resumed transfer offset
-b, –cookie STRING/FILE String or file to read cookies from (H)
-c, –cookie-jar FILE Write cookies to this file after operation (H)
–create-dirs Create necessary local directory hierarchy
–crlf Convert LF to CRLF in upload
–crlfile FILE Get a CRL list in PEM format from the given file
-d, –data DATA HTTP POST data (H)
–data-ascii DATA HTTP POST ASCII data (H)
–data-binary DATA HTTP POST binary data (H)
–data-urlencode DATA HTTP POST data url encoded (H)
–delegation STRING GSS-API delegation permission
–digest Use HTTP Digest Authentication (H)
–disable-eprt Inhibit using EPRT or LPRT (F)
–disable-epsv Inhibit using EPSV (F)
-D, –dump-header FILE Write the headers to this file
–egd-file FILE EGD socket path for random data (SSL)
–engine ENGINE Crypto engine (SSL). "–engine list" for list
-f, –fail Fail silently (no output at all) on HTTP errors (H)
-F, –form CONTENT Specify HTTP multipart POST data (H)
–form-string STRING Specify HTTP multipart POST data (H)
–ftp-account DATA Account data string (F)
–ftp-alternative-to-user COMMAND String to replace "USER [name]" (F)
–ftp-create-dirs Create the remote dirs if not present (F)
–ftp-method [MULTICWD/NOCWD/SINGLECWD] Control CWD usage (F)
–ftp-pasv Use PASV/EPSV instead of PORT (F)
-P, –ftp-port ADR Use PORT with given address instead of PASV (F)
–ftp-skip-pasv-ip Skip the IP address for PASV (F)
–ftp-pret Send PRET before PASV (for drftpd) (F)
–ftp-ssl-ccc Send CCC after authenticating (F)
–ftp-ssl-ccc-mode ACTIVE/PASSIVE Set CCC mode (F)
–ftp-ssl-control Require SSL/TLS for ftp login, clear for transfer (F)
-G, –get Send the -d data with a HTTP GET (H)…[/sourcecode]

Don’t get intimidated! It goes on and on and on, but just know it’s installed if you see all these goodies. If you don’t get the results above, then installing cURL is the next step. I’ll leave that to you. Here’s some links to download and get started however.

Next you’ll of course need Node.js and Restify installed. I’ll assume you have Node.js installed. Create a directory and in that directory just run the following command.

[sourcecode language=”bash”]
npm install restify
[/sourcecode]

Next create a file called server.js in that directory you’ve just installed restify in. Here’s the initial JavaScript code for that file that I’ve used to put together for the first few examples of using cURL.

[sourcecode language=”javascript”]
var restify = require(‘restify’);

function respond(req, res, next) {
res.send(‘hello ‘ + req.params.name);
}

var server = restify.createServer();
server.get(‘/hello/:name’, respond);
server.head(‘/hello/:name’, respond);

server.listen(8080, function() {
console.log(‘%s listening at %s’, server.name, server.url);
});
[/sourcecode]

Ok, now to run this with node.js just issue the command to launch node.js with this file that was just created.

[sourcecode language=”bash”]
node server.js
restify listening at http://0.0.0.0:8080
[/sourcecode]

Getting Get

Now the service is running on port 8080 against 0.0.0.0. To check out what a standard GET verb will do in a browser, open up a browser and navigate to http://0.0.0.0:8080.

Browsing the GET response via Chrome.
Browsing the GET response via Chrome.

You’ll see this in the browser window. Just straight plain text too. If you look at source, this is all you get back. Now open up a terminal and run the following cURL command to execute a GET against the URI & port. This is the most basic cURL command one can make. It is simply issuing a GET request against the URI and will display the body of the response.

[sourcecode language=”bash”]
curl 0.0.0.0:8080
[/sourcecode]

The response will be similar to this for the particular request.

[sourcecode language=”bash”]
{"code":"ResourceNotFound","message":"/ does not exist"}
[/sourcecode]

Your terminal will probably stick the subsequent prompt at the end of the result too, because the result doesn’t end in a newline. Beware of that, your prompt hasn’t disappeared. đŸ˜‰

To get a little more information you can get the header of the response dumped into the terminal with a -i. The -i option stands for –include, to include the header. Issue the command as either line shown below.

[sourcecode language=”bash”]
curl -i http://0.0.0.0:8080
curl –include http://0.0.0.0:8080
[/sourcecode]

The response will be provide a little bit more about what is going on.

[sourcecode language=”bash”]
HTTP/1.1 404 Not Found
Content-Type: application/json
Content-Length: 56
Date: Wed, 27 Nov 2013 00:27:36 GMT
Connection: keep-alive

{"code":"ResourceNotFound","message":"/ does not exist"}
[/sourcecode]

With this response the actual response error code number is shown. In this case we have a 404, which points us to the problem with this curl request. The server isn’t returning anything to our curl request. If we look at the code, we can see that the ‘get’ route is setup as ‘/hello/:name’ which means that the domain root is only looking at http://url_root/hello/someName for a request to be made in order to return a response.

[sourcecode language=”javascript”]
var server = restify.createServer();
server.get(‘/hello/:name’, respond);
server.head(‘/hello/:name’, respond);
[/sourcecode]

Issue a command against the server now with the following curl request.

[sourcecode language=”bash”]
curl -i http://0.0.0.0:8080/hello/Adron
[/sourcecode]

The response should come back as an actual response with content.

[sourcecode language=”bash”]
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 13
Date: Wed, 27 Nov 2013 00:34:04 GMT
Connection: keep-alive

"hello Adron"
[/sourcecode]

Here the content is returned as “hello Adron” and the header returns a 200. The content type is application/json format with the length returned as 13. Note also the connection is set to keep-alive. Let’s dive into that.

If we change the connection type, which is important for many scenarios, we have to send extra header information to ask for the response to be returned accordingly. In order to do that we can pass the -H or –header option in with the curl request. If the command is issued with an -i and -H as shown below the result will be as follows.

[sourcecode language=””]
curl -iH "connection: close" http://0.0.0.0:8080/hello/Adron
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 13
Date: Wed, 27 Nov 2013 00:41:07 GMT
Connection: close

"hello Adron"
[/sourcecode]

If we take away the -i we’ll just get the response, which is “hello Adron” and wouldn’t get the header, which now returns Connection: close in the response. By default, curl sets the connection as keep-alive, but in order to make the request return right away the connection needs to be issued a request for it to close. By setting the -H or –header value of connection to close, we get the response immediately. With restify, it is also important to note that it checks if the user agent is curl.

If it is curl the connection header to close and removes the content-length header. However I’ve experienced that restify is not doing this in all circumstances or that the use of curl is being changed in some of my usage. So don’t always assume that this will be the case. The safest bet is to set the connection closed when done. Thus, adding -H or –header and setting connection to close with a “Connection: close”.

Beyond Basic Get

Ok, so that’s a pretty solid use of GET with cURL. Let’s dive into some puts and deletes with a get or two thrown in for comparison. Change the executing code to the code shown in the server.js file below.

[sourcecode language=”javascript”]
var restify = require(‘restify’);

function send(req, res, next) {
res.send(‘hello ‘ + req.params.name);
return next();
}

var server = restify.createServer();
server.post(‘/hello’, function create(req, res, next) {
res.send(201, Math.random().toString(36).substr(3, 8));
return next();
});
server.put(‘/hello’, send);
server.get(‘/hello/:name’, send);
server.head(‘/hello/:name’, send);
server.del(‘hello/:name’, function rm(req, res, next) {
res.send(204);
return next();
});

server.listen(8080, function() {
console.log(‘%s listening at %s’, server.name, server.url);
});
[/sourcecode]

The first section of code to check out is around the function send.

[sourcecode language=”javascript”]
function send(req, res, next) {
res.send(‘hello ‘ + req.params.name);
return next();
}
[/sourcecode]

This function is setup to take req, res, and then handle next. The req is the request, the res is the response and the next is for issuing to return and continue with the result. The next bit of code starts the server with the restify.createServer();. Just below that there are several handlers that are setup.

[sourcecode language=”javascript”]
server.post(‘/hello’, function create(req, res, next) {
res.send(201, Math.random().toString(36).substr(3, 8));
return next();
});
server.put(‘/hello’, send);
server.get(‘/hello/:name’, send);
server.head(‘/hello/:name’, send);
server.del(‘hello/:name’, function rm(req, res, next) {
res.send(204);
return next();
});
[/sourcecode]

Now at this point I got a little sidetracked writing this blog entry. But I thought to myself, “hell, I’m just figuring out some parts of Webstorm, I ought to blog a little about it!” So, here’s…

A Little Webstorm Love

Webstorm and cURL. Click the image for a full size image.
Webstorm and cURL. Click the image for a full size image.

Before continuing on I wanted to cover a few tidbits of the Jetbrains Webstorm IDE. I often switch back and forth between the Sublime/Terminal combo and the Webstorm IDE. The really cool thing about this IDE is that it actually has a Terminal built in, color coding and autocomplete of the code, refactoring, and file and folder viewer and a whole slew of other features. In the image above that I’ve included there are four neon pointers that are displaying some of the key functionality that I’m using to work through this blog entry with cURL and Restify.

The arrows, from left to right are pointing to the following IDE elements. The first is pointing to the javascript files storgie.js and starter.js which I added specifically to show the git status colors. Each color reflect if the file is new (green), has changes (light blue) or is committed with no changes (white). The second arrow is just pointing to the general folder structure. Here you can see the hidden .* files like the .gitignore and .npmignore and also easy to dig through the node_modules directory. Webstorm also uses the node_modules directory to provide extra information and autocomplete to the code as you work through your coding session. The next arrow is pointing out the terminal in the editor, which is where I’m working up the curl examples in this blog entry. Then of course the color coded starter.js file that is one of the working examples. Webstorm, simply, is pretty sweet. I’m looking to do some more walk throughs and work sessions with the editor in the near future. So if interested, be sure to keep reading and subscribe, I’ll be sure to post any links to wherever the material ends up right here.

Now, back to the cURLing. đŸ˜‰

After I toyed around with Webstorm and bit to get it work in a way that was efficient for me to use it for developing these APIs I stumbled into an idea. I’d provide a page for the APIs that could be located at the root of the API service such as http://api.blagh.com. The APIs would still be a restful type schema like http://api.blagh.com/thing/create or http://api.blagh.com/thing/destroy but at the very root would be a kind of docs. Maybe this could just be a status page even. Whatever the case, there needs to be something at http://api.blagh.com so I decided right then and there I’d switch to express.js to build the rest of the API services. Restify is fine and all but for this, it seemed like express would have all of the pieces I need for this.

Just to boot, I then read a few articles about express being faster such as this one. But then I read this issue on github and almost thought, “maybe I should keep using restify” but then I thought, “dammit, just get it done the way you want it built” so it was back to express. It’s easy enough to change this later so I just got back to coding, albeit with express now. So keep reading and in the next day or two I’ll have part two of this series on using cURL to hack at your APIs.

Enjoy the composite coding & cheers!

References:

How to Build an NPM Package, Beginning the Symphonize Project

NPM has helped to build on the massive Node.js popularity and drive JavaScript from a simple scripting language in the web browser to a powerful and capable back-end server language. A quick refresher, NPM stands for Node.js Package Manager and each package is made up of:

  1. a folder containing a program described by a package.json file.
  2. a gzipped tarball containing [1]
    1. a url that resolves to [2]
    2. a <name>@<version> that is published on the registry with [A]
    3. a <name>@<tag> that points to [B]
    4. a <name> that has a “latest” tag satisfying [C]
    5. a git url that, when cloned, results in [1]
Path structure view in Jetbrains Webstorm IDE.
Path structure view in Jetbrains Webstorm IDE.

With that basic understanding of what a module is that NPM provides, let’s jump through the steps to build a module that provides some basic functionality. I won’t cover too many parts in detail yet, just the happy path to getting an NPM library running.

First let’s create an appropriate folder and file structure to get started with. Here’s the commands I ran to get started.

[sourcecode language=”bash”]
mkdir bin
mkdir lib
[/sourcecode]

With these two directories created I then created the following files in the designated paths. In bin I created the symphonize.js file and in lib I created a main.js file.

Now, I added the following code to the symphonize.js file.

[sourcecode language=”javascript”]
exports.Coupling = function (searchThis, forThis) {
var returnValue = ‘no’;
if (searchThis.indexOf(forThis) > -1) {
returnValue = ‘yes’;
}
return returnValue;
}
[/sourcecode]

In the main.js file I added the following.

[sourcecode language=”javascript”]
(function () {
var couple = require(‘../bin/symphonize’);
couple.Coupling("Sample text", "Sample");
}).call(this)
[/sourcecode]

There are a number of issues with this code, I know, but it’s just a sample of the minimal amount of code, folder structure and packages.json that I need to get this package installed and ready for iteration as I move forward with the actual code base and what functionality will actually be added. Speaking of the packages.json file, I created one and added the following configuration settings to it.

[sourcecode language=”javascript”]
{
"author": "Adron Hall",
"name": "symphonize",
"description": "Prints out data to the console! Will be iterating soon for real functionality!",
"version": "0.1.0",
"repository": {
"url": "git@github.com:Adron/symphonize.git"
},
"main": "./lib/main",
"bin": {
"replaceme": "./bin/symphonize"
},
"dependencies": {},
"devDependencies": {},
"optionalDependencies": {},
"engines": {
"node": "*"
}
}
[/sourcecode]

That is now enough for me to at least get the module added to the global NPM repository, get things pointed back to Github appropriately and move forward with actual coding. I might even setup some continuous builds and delivery at some point, since I’ve now got the end point of where the libraries will be going. The commands to get a module uploaded to the NPM Repository are as follows. This command of course assumes I’ve already added a user using npm adduser or I’ve added one via the web site interface at https://npmjs.org/.

[sourcecode language=”bash”]
npm publish
[/sourcecode]

I’ve now got everything prepared and uploaded to NPM there is now a symphonize module library ready for use.

My NPM Page for Symphonize. Click to go to the actual NPM page.
My NPM Page for Symphonize. Click to go to the actual NPM page.

Here’s a few quick references to where everything is: