Kevin Crawford, Software Engineer

Front-End Specialist · Full-Stack Generalist

Architecting Maintainable, Reusable UIs in Angular: A Case Study

After spending substantial time working in-depth in Angular land, and with further influence from incursions into Flux & React, I've come to develop certain opinions on how to best architect non-trivial, data-driven UI flows in an Angular application.

What follows is a case study of a real-world UI problem, solved with the guidance of well-established principles and patterns in software design.

Read the code on GithubSee the live demo

The User Story

Jill works for The Widget Factory, a company in the business of making widgets. Oftentimes, she wants to be able to test how slightly different widgets perform against each other.

Rather than waste time creating the otherwise-same widget several times over, she would like to be able to quickly generate the different permutations, and be done with it.

Introducing: Ng-coffeeplate

Grunt was really awesome when it first came on the scene, but I've really come to love Gulp. It's faster, more flexible, and I find the "code-over-configuration" paradigm much easier to reason about—all with fewer lines of code.

I needed a boilerplate—suited to my tastes—that I could use to quickly get up and running on new projects with. If you're a fan of Angular, CoffeeScript, Jade, Sass, and TDD, then maybe you'll like it too!

Check it out at

Configuring a Production Node.js and MongoDB Environment in Ubuntu on an Amazon EC2 Instance

This tutorial will cover launching an EC2 instance, setting up the Node.js/MongoDB stack, and keeping your app running as a service so that it is resilient to failure. Most everything is taken directly from the official documentation for the various packages, and I included links. That way you can refer to the tutorial as a general guide, and still use official documentation to get into the nitty-gritty details.

Right, then. Let's get started!

Cloning an Existing Installation of Octopress

The way Octopress deploys to Github Pages is a little funky. When you setup your blog for deployment to Github Pages, a second copy of the repo is instantiated in ./_deploy, and is checked out to the master branch.

You create and edit posts in the source branch, in your project root. During deployment, your site gets generated, and the updates copied to _deploy. From there, a commit is made to master, and a git push is performed, updating the website.

When you clone your blog to a different computer, you need to make sure it is setup in the same way, like so:

# Assuming that you have your Ruby environment configured
$ git clone -b source
$ cd
$ git clone -b master _deploy
$ bundle install

Thank you to and for helping me figure that one out.

Hello, World

console.log("Well let's get started then, shall we?");