Deploying a web application is always kind of a scary process.  I feel like even when it works well, there’s a second where I wonder if it’s going to break.  Deploying a web application manually is probably where this irrational fear comes from.  Now that automatic deployments are the norm, there’s no reason to be scared anymore.

Capistrano is a standard for automatic deployments.  It’s been around for a while now, it’s a mature product, and it works really well.  There’s good documentation available, and honestly, it’s never really given me any problems.  Capistrano is also written in Ruby.  Unfortunately, I don’t program in Ruby (nor do I want to), so I’ve never really felt comfortable setting up and configuring Capistrano.  Not to mention that I feel a little dirty having Ruby code in my beautiful node codebase.

When I heard about ShipIt though, I got really excited.  I could have automatic deployments with a tool written in Javascript?!  Count me in!  I installed it, started configuring it into my Koa Starter Kit, and wrote this blog to document my progress.

Continue reading

I recently started working on a new web project (borrowbot.net), and I was trying to decide how to structure it and what libraries to use.  I had used Koa.js in the past and really enjoyed it, so I wanted to use that again.  I came up with a list of things I wanted to include:

I also had found some cool packages that weren’t vital, but that I wanted to include.

After I got BorrowBot up and running and set up with those libraries, I started a new repo to make a starter kit.  I removed all the app specific stuff, and then I was left with a bare bones skeleton that can be used with any project.

Check it out, let me know how you like it, and make some cool stuff with it!

Koa Starter Kit

I come from the land of PHP, where calls to external resources are synchronous.  This makes things like making web requests or database calls fairly easy.  Especially if you’re making these calls in a loop, or using the results from the first call as input for the second.

You can see from the above example, it’s super straightforward to make these types of calls.  You query the database, wait while it’s working, and put the result in the variable once you’re finished.  These types of calls to external resources block (or pause execution), but that’s usually not too big of a deal.

When I started working in node.js though, everything I know about external resource calls got thrown out.  Enter asynchronous processing.

Continue reading

I recently got tasked to document some databases for a project I’m working on.  I happen to enjoy writing documentation, so I thought it would be no big deal.  How wrong I was.  There’s so many tables, and all of them are filled with columns that lack comments.  It’s my job to find out what all of them do, and document them.  My initial thought was to create a markdown document and capture all of the data in some tables.  As I started to do that, I was really pleased with the result.  Beautifully rendered tables that accurately describe what column does what, how it’s formatted, and why we need it.

Unfortunately, my extremely manual documentation process doesn’t scale.  When I realized that several tables all share the same column name, I started to wonder “what happens if I make a typo and then copy and paste it everywhere throughout my documentation?”.  I started to think of ways to centralize the content, while still being able to keep my content in markdown.  The solution I came up with was Mustache and Grunt.

Continue reading