Showing posts with label javascript. Show all posts
Showing posts with label javascript. Show all posts

Wednesday, June 12, 2013

Getting Started With Node.js Modules and npm (for developers)

In spite of node.js' wild popularity, finding good informative docs and tutorials as to how to develop and distribute apps for the platform can be a chore. Google searches on the matter tend to return either out-of-date or end-user results. So, as a service to the community and for my own edification, I'm going to show you how to get started developing node.js and packaging with npm.

This tutorial assumes you have node.js version 0.8.1+ as well as npm version 1.2.18+ properly installed. It further assumes working on a POSIX-ish environment. Also assumed is that the reader has at least passing knowledge of JavaScript.


"Hello Google"

In order to better illustrate the steps, we are going to develop a super trivial app that will send a search query to google, retrieve the results in json format and then print the results to the screen. So, let's get moving:

1. Let's create a directory and cd into it:

   $ mkdir hello-google && cd $_

2. Now the crucial step to get your node module started:

   $ npm init

This will create a file named package.json which should look something like this:

{
  "name": "hello-google",
  "version": "0.0.1",
  "description": "A trivial app to illustrate node.js dev",
  "main": "main.js",
  "scripts": {
    "test": ""
  },
  "dependencies": {
    },
  "repository": "",
  "author": "Ruben Orduz",
  "license": "MIT"
}

3. Install request module (easier to use than the default http client):

   $ npm install request

4. Let's add request to the list of dependencies in package.json:

{
  "name": "hello-google",
  "version": "0.0.1",
  "description": "A trivial app to illustrate node.js dev",
  "main": "main.js",
  "scripts": {
    "test": ""
  },
  "dependencies": {
    "request": ""
    },
  "repository": "",
  "author": "Ruben Orduz",
  "license": "MIT"
}

5. Let's create main.js and write some code (you can use your text editor of choice in place of 'open'):

   $ touch main.js && open $_

6. Now copy and paste the following code in main.js:

7. Now, let's test everything is working (assuming you are inside hello-google directory):

   $ cd ..
   $ node hello-google/

In a few seconds, you should see something along the lines of:

   PRISM (surveillanc -> http://en.wikipedia.org/w

   Nine Companies Tied to http://www.usnews.com/new

   What Is PRISM? - G -> http://gizmodo.com/what-i

   NSA slides explain the http://www.washingtonpost

8. If you have never submitted any packages to npm before, you must register with the following command:

   $ npm adduser

it will prompt you some questions and within seconds you will have your user and machine authorized to publish to npm's public servers. 

9. Once you are 100% ready that you want to publish a module for public consumption, you can run the following command:

   $ npm publish

10. To make sure your module can be installed and run:

   $ npm install hello-google

11. Let's test it through node:

   $ echo "r = require('hello-google');" > test.js && node test.js

Note that the name the module will be published as it's not the name of the directory, it's the name declared in the package.json

Saturday, July 21, 2012

Thinking Outside The Box: JS Frameworks and Libraries

It seems that everywhere you look nowadays, in terms of ECMA/JavaScript libraries and frameworks (jQuery, ember, Angular, lawnchair, etc.), it's all about fancy, minimal, simple, terse, expressive, consistent, predictable, easy-to-learn, multi-platform bullshit. I say let's think outside the box. Let's build something awesome. Here are a few tenets of Project Bloatrzr:

  • Inconsistently inconsistent: sometimes we follow a pattern, sometimes we don't.
  • Optimized for IE6 @ 800x600: let's obey and pay homage to the one and true web browser, at SVGA resolution, the one and true resolution.
  • Humongous: in terms of both size and memory footprint. Memory is cheap and abundant, and so is bandwidth. No need to cram and prune superfluous code we may or may not need in the future.
  • Syntactic sugar clusterf**k: part Perl, part Lisp, Part Objective-C and part MIPS assembly.
  • Inherently incompatible: why should we cram our style so that it can "play well with others"? That's obsolete thinking right there. Let's do our own thing and tough luck for the user if their other libraries break. Also, why corner ourselves into a corner? Let's do this in a forwards and backwards incompatible approach as well.
  • Documentation: what documentation?
  • Changelogs: why take the fun and the sense of adventure of finding out what was changed? Developers like challenges, let's give them one.
  • Git repo: Nope. In fact, no version control at all. We'll e-mail Zip'd source trees to each other and we'll do a "good faith" effort to include important code from anyone else that was CC'd.
  • Blatantly insecure: why spend precious time "securing" our code? We all know a determined hacker can and will find a way to find an exploit. So, might as well leave a few holes in our code the industrious hacker can inject his or her code.
So, let's get this ball rolling, shall we?