Daily Archives: January 18, 2014

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.

jshint
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: https://github.com/victorporof/Sublime-JSHint#automatically-linting-on-edit-or-save

Install SublimeLinter
In Sublime Text: Command-Shift P, Package Control: Install Package
SublimeLinter
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”: [],
“gjslint_ignore”:
[
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.