node.js development on windows

i’m not much of a windows guy anymore, but was asked to make an install script for developers at work who wanted to write node.js code on windows. the problem with node.js development on windows is not so much about node.js itself, but the limitations of the basic design of the language and its solution. with node.js and its event loop-based architecture, it doesn’t excel at computationally intensive code, so its solution is to compile native libraries and use those to get the performance needed.

this solution is quite viable, but this also requires you to be able to compile these extensions. this is where there are a few problems. trying to get a C compiler on a windows box is sort of non-trivial, but what’s worse is that some of the libraries out there aren’t ported to windows and then you are dead in the water.

so if i absolutely had to develop in windows, i’d setup a VM. and if i had to use a VM, i’d use vagrant for headless virtualization management. and if i had to use vagrant, i’d use virtualbox for virtualization because of its built-in integration with vagrant.

but now the problem is there are a bunch of dependencies that need to be installed before you can even start developing on windows: vagrant, virtualbox, some linux OS, node.js in the linux OS and all of the build tools needed for npm installation for the linux VM. now let’s say that you have a team of windows developers and you want to get them setup quickly. how do you do that? well, that was what i was asked to solve and so i decided to make a windows installer that will install all of the dependencies.

it turns out that there is a pretty established solution available: nullsoft scriptable install system. it comes bundled with plenty of examples and though i feel that the scripting language available with NSIS is a little awkward, the documentation and resources available for it make it fairly easy to use.

the trickiest part of the NSIS script was figuring out how to launch an .msi file instead of a standard .exe file. it turns out that you have to invoke it via msiexec.exe.

so great, you can make a windows installer that will install all of your dependencies. spin up a vagrant box, install all of the dependencies in your VM, then package it up and make an installer that will install everything for you. easy! now you will have an automated install of your development environment.

making the keyboard rate faster on mac os x

i’ve felt that the keyboard repeat rate on mac os x was a little slower than i preferred, even at the fastest setting and wondered whether or not that was something that we can make faster. it turns out that you can override this setting on the command line and go just a little bit faster than what the system preference allows.

run this command in Terminal and you can speed up the repeat rate. i set it to 1, but you can go even faster and set it to 0. make sure you logout and log back in to make the settings go live.

making the leap to sublime text 3

i’ve been holding back from taking the plunge into sublime text 3 because the plugin support for it has been slow to port over to 3’s new architecture, but, tonight, after a fit of frustration with some code, i decided i needed a distraction.

i took an inventory of what plugins i use and it turns out that the plugins i use have been ported over to be compatible with sublime text 3. there’s a great resource can i switch to sublime text 3 that will tell you what shape the plugins that you use are in.

the biggest change i see in my day to day life with sublime text is how sublimelinter works. they’ve completely revamped the way that plugin works. each linter is now a separate plugin that you need to install instead of being packaged together with the main sublimelinter plugin. what this enables which couldn’t happen was that you can run multiple linters for javascript at one time!

i love this because i run both jshint and gjslint on my code and have had to resort to hacks to be able to do this, but now i can do it all.

what to do when the npm registry is down

it seems almost unthinkable, but the npm registry is having issues.

that can happen?? so what do you do when the main npm registry goes down? it turns out there’s an EU mirror.

worked for me in a pinch, i’ll have to remember that.

using livereload without the browser plugin

livereload is a little project that dramatically changes a front end developer’s life. it watches the filesystem for changes and will tell the browser to reload the page if it detects changes on the filesystem.

the idea by itself is pretty awesome. the actual implementation of this is a little weird as there appears to be a standalone app and a browser plugin that communicates with each other to detect the file changes and then trigger a browser reload.

but wait, there’s something even cooler! the livereload node module is an implementation of the livereload server in node.js. you can hook this into your node application and then you won’t need a separate app to monitor for file changes in your codebase. but still, there is some friction here because you still need that browser plugin so that the livereload server can trigger a browser reload.

but if you look at what the plugin does, all it does is inject some javascript on the page to call the livereload server, load up a javascript file, and initiate the websocket connection to listen for triggers. it turns out that you can simply add that script call to your page and then you won’t need the browser plugin at all.

it is technically documented but buried pretty deep in the knowledge base.

livereload is a separate server running in your app, so you just need to stick the code somewhere after your main server has been initiated, i put it at the buttom of my server.js file.

livereload accepts a parameter “exts” which tells it which file extensions to watch. you can add as many paths as you want for directories to watch.

then you just need to add this snippet to the bottom of your page template to have the browser connect the livereload server with your app:

and voila, if you make an update to a file in your project, your browser will automatically reload for you.

using passport for facebook authentication

passport and passport-facebook offers very easy facebook authentication integration into your node app. for the most part, it’s very straightforward, but i got tripped up in a few places.

i’m using krakenjs for my express framework so you have to be a little mindful that some of the express setup stuff has been abstracted away from you. because of that, i was puzzled because i didn’t understand why i couldn’t get access to the passport user object once authenticated.

passport wants to uses sessions. make sure that you enable the express session middleware and make sure you use the middleware before trying to use passport. order matters here. additionally, if you are using cluster, you can’t use in-memory sessions, you’ll have to use something that is globally accessible by all node processes…something like redis can be used via connect-redis.

passport extends express’ req with the isAuthenticated() method
i initially thought that i had to implement and check whether or not the user is authenticated, but passport handles this for you.

you have to implement passport.serializeUser() and passport.deserializeUser()
passport.serializeUser() is the function that will serialize the user info into the session, typically the user ID. at this point, you have access to the Facebook profile object, so you have information like: facebook user ID, username, displayName, etc.

This function is run once at time of authentication to put the authenticated user into the session.

passport.deserializeUser() is the function that will take the user ID from the session then construct the full information of the user and then make this object available in req.user. this function is run on every request to construct the req.user object so make sure that this code is performant. documentation everywhere says that this is where you would query a database to get user information, but it seems like involving a caching layer here would be advised.

my biggest pet peeve: unlinted javascript/node code

the world of front end development is rapidly changing and with the popularity of node.js, it seems that javascript is creeping up everywhere. one of the misconceptions about javascript is that it is a hacky language by nature and the code is always going to look hacky. another popular misconception is that because javascript is executed in the browser and best practice is to minify your javascript code, it doesn’t matter about maintaining a consistent style within your javascript. sadly, many front end developers believe this and it is these same front end developers who are now experimenting with node.js and writing crappy server side code.

the really sad thing here is that there are amazing tools available that solves this problem. as far as i’m concerned it is a solved problem, the barrier to adoption is very low, and there is no reason not to have style adherence in your code base. what i’m talking about here are static code analysis tools for javascript. these are tools that will analyze your code and tell you where there are potential code smells.

there are two that i use for javascript development: jshint and the google closure linter.

two seems like it may be a little overkill and though both tools do have some amount of overlap, they serve two different purposes for me.

for me, i use jshint to detect errors and potential problems in my code. i prefer jshint over jslint because it is a little less opinionated (or can be configured to be less opinionated) than jslint. jshint is a good tool to find problems in your code, but it also helps with writing code with best practices.

google closure linter
google closure linter does the same things jshint does, but it also enforce style conventions. this is amazing by itself, but google has gone one step further and they bundled a tool called fixjsstyle with their gjslint app. fixjsstyle will try to fix all of the problems that gjslint finds. this blew my mind. this tool makes style adherence insanely easy. there is no longer any excuse not to conform to the same style…and yes, it is google’s style convention, but i happen to agree with most of what they say.

so great, there are two tools that lints your code for you, but wait, there’s more!

it seems that javascript developers are all gravitating towards using sublime text editor as their IDE. there are two plugins that will lint your code in real-time so that you will never have to run your linters outside of your text editor: SublimeLinter and JSHint Gutter.

so how do you go about doing it? if you’re on a mac/linux system, you do:

Install jshint and create soft link

Install gjslint and create soft link

Install Sublimt JSHint Gutter plugin
In Sublime Text: Command-Shift P, Package Control: Install Package
JSHint Gutter
You can optionally configure Sublime to lint on edit or save:

Install SublimeLinter
In Sublime Text: Command-Shift P, Package Control: Install Package
Configure SublimeLinter to use Google Closure Linter

Go to Sublime Text 2 => Preferences => Package Settings => SublimeLinter => Settings – Default
Copy the entire file that has been opened here

Go to Sublime Text 2 => Preferences => Package Settings => SublimeLinter => Settings – User
Paste contents into this file
Make the following edits:
“sublimelinter_gutter_marks”: true,
“sublimelinter_mark_style”: “none”,
“javascript_linter”: “gjslint”,
“gjslint_options”: [],
110, // line too long
220 // jsdoc supression

setting up SSL for node using express

i’ve been working with node a lot lately and i’m surprised that i haven’t needed to do this sooner, but i finally needed to set up SSL for one of my node apps and it wasn’t hard to do, but there was no one place where all of the steps were documented on how to setup SSL using express. it actually is pretty straightforward and easy.

first you need to create a certificate for SSL. this can be done by using the command line tool: openssl.

once you have the certificate, all you have to do is tell node that you want to use the certificate you made for the SSL requests. what i didn’t know, but is actually very clearly documented in express’ api documentation is that the variable “app” returned by express() is actually a function used as a callback for node’s http to handle requests. so instead of starting up your server via an app.listen() call, you can simply go back to the basics and use node’s http and https APIs to start the server and pass express’ app to it.

if you want the same code to handle both http and https requests, you can simply call http and https’ createServer() method on different ports.