Dec 11 2013
Dec 9 2013
Nov 12 2013

Owning my links

I’ve always just blasted links I find interesting onto Twitter, or increasingly via Tent, and I started to realize that I didn’t really own these links. I had no collection, no way to easily make them appear elsewhere. Especially after I read this piece by Dave Winer about owning your links, and seeing his linkblog, I was inspired.

So now my links are my own. They live at

It’s not actually on my servers, but hosted on Tumblr, since sharing links is so easy there. However, the source lives under a domain I control. And for backup, I use IFTTT to save every link to my “links” note in Evernote.

This means that an RSS feed is available. I’m currently syndicating them to Twitter. I’m looking into how to do so with Tent, and if Google+ ever joins us in the syndicated web, there too.

Nov 8 2013


It’s dangerous on the internet, use some security headers. No, really. If you’re making a webapp, you need some of them lovely headers. Headers such as CSP, HSTS, X-Frame-Options. I previously implemented these in our Gmail Bridge, and then needed them again in another app. Copy over the headers code? Nonsense! That’s what libraries are for.



You can use hood without any configuration, and it will use sane defaults that most apps will want to enforce security-wise. You can also pass options to hood(options) to configure parts to be different than default, or you can use each header individually, such as hood.csp().

Included middlewares:

  • csp
  • hsts
  • xframe
  • nosniff

Why didn’t I just use Helmet?

  • helmet doesn’t by default use the Content-Security-Policy header for it’s csp middleware, which is now the standard.
  • I only expected to setup the middleware once, so needing to do pre-setup for helmet.csp by adding and configuring policies felt wrong. hood.csp just accepts policy options, so you can use it once and be done.


Cover your head, v0.1.1.

Nov 6 2013
Nov 5 2013

client-sessions v0.4.0

We released v0.4.0 of client-sessions today, despite all the npm bumpiness. Here’s the changelog:

  • add activeDuration with default to 5 minutes
  • add checking for native Proxy before using node-proxy
  • add cookie.ephemeral option, default false
  • add constant-time check
  • adds self-aware check. wont override req.session if already exists
  • fix wrong handled of utf8 replacement character
  • fix http expiry of cookie to match duration
  • fix updating cookie expiry whenever duration/createdAt changes
Oct 25 2013

dbug v0.1

I’ve been on a logging spree recently, and after having spent some time on an application logging module, I’ve been thinking about what libraries can do about logging. At first I said that libraries should just dump everything into console.log, but I can definitely see downsides to that.


debug is a popular utility that handles this problem of libraries wanting logging without annoying consumers quite well. You can use debug, name a logger, and log messages all you want. Unless a consumer adds en ENV variable to listen to those debug messages, it will be all quiet.


dbug works largely the same, with a few tweaks that I feel are really helpful, but I don’t think I’d have been able to convince TJ to include them in debug.

First of all, it’s a perfectly safe drop-in replacement for debug. It has the same API.

However, it adds a few familiar methods that you’d find on the console object, so you can classify the severity of particular dbug messages. Some may simply be info messages, while others are meant to signify when an error or warn has occurred. Still though, only if the consumer has opted-in to see your messages by setting process.env.DEBUG.

The log level will be included in the log message, so everyone can see the severity.

Additionally, the DEBUG matching is slightly more lenient. You can still use * and comma separated names, but additionally, specifying a name now implies any of it’s children.

DEBUG=foo will match foo:bar. Basically, every name is also the same as name:*.


0.1 is available now.

A few things I’ve been toying with adding to additional versions:

  • DEBUG=foo.warn to only get warn or greater message from the foo logger.
  • Allowing . to be a separate in log names also: dbug('').

And, currently next up is getting intel to play nice with debug/dbug.

Oct 24 2013