This year I'm going to refocus on my blog. I plan on writing at least one blog post a month for the rest of the year, but this month has been busy, so I owe you one. My first couple of posts will be about developing APIs and websites using roads and koa. If you would like to skip the wait and see it in action check out roads-starter for a working example.

If you want to be notified of new posts, follow me on Twitter.

This took me way to long to figure out.

  1. In the S3 interface, click the magnifying glass icon to the left of your bucket.
  2. Click the "Edit CORS Configuration" button. It should be right next to "Add Bucket Policy"
  3. You should already have a CORS XML file in here, if not mine looked like this :

    <?xml version="1.0" encoding="UTF-8"?>
    <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">

    This CORS header allows all websites to perform GET requests against this resource.

  4. To reference the file, you must use the url structure [bucket].s3.amazonaws.com/[object]
  5. If using an img tag, it must contain the attribute crossorigin="anonymous". Read more here: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/img#attr-crossorigin

Check out MDN for more information about CORS headers.

I have just implemented the new url routing structure into Roads. Lets start with the example :

routes : {
  'users' : {
    controller : 'user',
    view : 'many',
    routes : {
      '#id' : 'one',
      'auth' : 'auth'
  'me' : {
    controller : 'user',
    view : 'one'

Each key is a "URl Part". I define a URL Part here as one value in the array resulted from url.split('/');

The value for each URL Part defines the necessary information to render the url (eg "users" = "/users"). I use a standard controller/view structure for my code so you can see those keys here. Additional data (like templates, pre/post execution code, etc) could be defined here.

The "routes" key within each value defines child routes. The keys can be literals (eg "auth") or variables (eg "#id"). Variable types are defined by the first character, # means only numbers, $ means any string value that does not contain the character "/". The value of each child route can be defined identically to the parent route.

Child route values have one additional feature, they inherit any missing values from their parents. Not only are object keys inherited, but I have added an additional shortcut. Since views are likely to be the only thing that ever changes, you can forgo the objects entirely and have a route point directly to the view string (eg {"#id" : "one"} tells /users/#id to load the view "one" from within the controller "user").

So lets unwrap the gist from above so you can see what a traditional router would look like.

  route : /\/users/
  controller : 'user',
  view : 'many'
  route : /\/users/(d+)/,
  controller : 'user',
  view : 'one',
  matches : ['id']
  route : /\/users/auth/,
  controller : 'user',
  view : 'auth'
  route : /\/me/,
  controller : 'user',
  view : 'one'

In these traditional routes, you have tons of duplication, and have to iterate over every single route to find your match.

In Road's router, you have much less typing and can skip many routes. If a route does not match the url, there's no reason to check that route's children.

In the end, this feels much more powerful and much less tedious. I think it will make routes more enjoyable to write.

Yesterday I launched Bifocals.js, a node library for handling http responses.

It was my first big launch, and I learned a ton from it. Before I go into that, lets show some numbers.

  • Peaked at # 9 on Hacker News
  • 7,077 Page Views
  • 6,202 Unique Visitors
  • 56% United States
  • 70% Chrome
  • 48% Mac
  • 87% from news.ycombinator.com
  • Avg. Visit Duration: 00:00:17

That visit duration is abysmal. Clearly the docs need to be improved.

I received the best discussion via Facebook, and then Hacker News. No one initially knew what the hell my library did. So I wrote up a new description, which will be added to the docs later.

Bifocals makes it incredibly easy to split your web page up into little tiny chunks. It might not be immediately obvious why this is useful, but it becomes slightly more clear with an understanding of the javascript event queue.

Any time an http request hits the server, it puts your callback into a queue. Node processes this queue in order. Every time you handle a callback for an http request, a database request, any socket or i/o in general, it uses this queue. Additionally, process.nextTick will add functions onto this queue.

If each of your callbacks operate quicker, it should allow improve the request time across your application. Each time a callback completes it releases control to another callback. With mix of pages that render at different speeds, faster requests should get out of the way while longer requests are still handling i/o.

Bifocals not only allows your view functions to be smaller, but it allows them to operate out of order. All of your views can start performing IO at the same time, and no matter which one finishes first bifocals will render the final output accurately.

When all of these techniques are put together, theoretically it should create a faster overall page speed across the entire site. (I hope to have real stats soon)

If you don’t need these benefits, bifocals offers two additional nice features.

  • It abstracts away template rendering to a simple workflow, and allows you to use any core render system you want.
  • It provides easy access to http status codes, and the strange http standard associated with them.

Hopefully this is a little more clear. Thanks to everyone who had comments, I have some cool new features coming soon.