Sometimes you have to fail hard

This was a post I wrote in the middle of 2013 but never published. I wanted to share this since it’s a common story across all technologies and developers of all skill levels. Sometimes things really just don’t work. As a post-script, I did come back to this project and had a lot of success. When in doubt, let time figure it out :)

For the last couple of weeks, I’ve been trying my hand at the node.js ecosystem. I had an app idea but I wanted to make sure I chose tech stacks wisely. There’s no better way to get familiar with different stacks than to get your hands dirty and try them all, so that’s what I did.

Sometimes when you start with a new language or platform things come easy, you can blaze a burning trail writing great software. You’re like an extension of the computer, everything … Read more

, , , , ,

Angular with typescript architecture

Bear with me, this is going to be a long post.

For the past several months I’ve been working on a production single page application written with AngularJS and TypeScript, and I wanted to share how myself and my team have architected the application. In case you were wondering, the app was written using typescript 0.8.3 and not 0.9.1 (which is out now with generics).

In general, I was really unhappy with a lot of the AngularJS examples I had found on the internet when researching how to structure the application, since they all looked flimsy and poorly constructed. While the examples found online were easy to read and follow, they clearly wouldn’t work with an actual large application.

I had several goals:

  • I didn’t want to have to constantly register directives/filters/controllers/etc with Angular everytime I added something
  • I didn’t want to have to update my main index.html page with
Read more

, ,

Separation of concerns in node.js

I’ve been playing with typescript and node.js and I wanted to talk a little about how I’ve broken up my app source. It’s always good to modularize an application into smaller bits, and while node lets you do a lot, quickly, with just a little bit of code, as your application grows you really can’t put all your logic in one big app.ts.


Instead of the normal application example you see for node projects, I wanted to make it clearer what the initialization of my application does. My app start is structured like this:

* Module dependencies.

import db = module("./storage/storageContainer");
import auth = module("./auth/oauthDefinitions");
import requestBase = module("./routes/requestBase");

var express = require(‘express’)
, routes = require(‘./routes’)
, http = require(‘http’)
, path = require(‘path’)
, log = require("./utils/log.js")
, fs = require(‘fs’)
, passport = require(‘passport’);

var app = express();

class AppEntry{
this.initDb();… Read more


Mongoose with TypeScript

Mongoose is a library for node.js that wraps the mongoDB driver. Since I’ve been playing with typescript, I wanted to show a short demo of strongly typing mongoose with unit tests run in nodeunit all using typescript.


First, I have a collection of definition files that represent mongoose types, nodeunit types, and my own document types (in schemaDef.d.ts).


///<reference path="./mongoose.d.ts"/>
///<reference path="./nodeUnit.d.ts"/>
///<reference path="./schemaDef.d.ts"/>

The nodeunit definitions /def/nodeUnit.d.ts

interface ITest{
done(): void;
ok(isGood:Boolean, message?:string):void;
equal(expected:any, actual:any, message?:string);

Here are the basic mongoose definitions in /def/mongoose.d.ts. I can’t guarantee that these types are right, I’m updating them as I go along. I’m inferring the structure from the documentation and personal experimentation. As I encounter new mongoose definitions, I can just add them to the appropriate scope. You can see that I’m also chaining definitions: one definitions functions might return another interface that has … Read more

, ,