Blog logotrial and stderr


A 3 post collection

My app is not a dumping ground for your one-night project libraries

 •  Filed under nodejs

All these devs like "oh, if you're using X and Y, you should really use my X-and-Y-plus-Z integration plugin, which mitigates some bugs in X that I could have fixed, but didn't, instead opting to create more bugs with this library I wrote one night after slamming four manhattans and going home alone"

Another Node.js Configuration Pattern

 •  Filed under nodejs

I'm becoming a fan of Yos Riady's blog. He's got this nice node.js configuration pattern, which introduced me to the glory of nconf. Unfortunately, that pattern doesn't quite have the flexibility I seek, and leaves more up to nconf's convoluted resolution system than I'd like. So here's mine, with the help of Ramda, my favorite utility belt.

const nconf = require('nconf')
const R = require('ramda')

const defaults =
    'node_env': 'development',
    'mongo': {
      'host': 'mongo',
      'collection': 'mything'

const testDefaults = {
  'mongo': { 'db': 'mything-test' }

const localhostDefaults = {
  'mongo': { 'host': 'localhost' }

function Config() {

  nconf.argv().env({ lowerCase: true })  // get NODE_ENV as node_env

  const mergeAllDeepRight = R.reduce(R.mergeDeepRight, {})
  const computedDefaults = mergeAllDeepRight([
    this.env.isTest ? testDefaults : {},
    nconf.get('localhost_services') === '1' ? localhostDefaults : {}


Config.prototype.get = function(key) {
  return nconf.get(key)

// for convenience, because `config.env.isTest` is real nice
const nodeEnv = process.env.NODE_ENV
Config.prototype.env = {
  'isProd':  nodeEnv === 'production',
  'isTest': nodeEnv === 'testing',
  'isDev': nodeEnv === 'development'

module.exports = new Config()

This makes the rules about how defaults are loaded very explicit and very flexible.

NodeJS Considered

 •  Filed under nodejs

NodeJS pros:

  • Share code between server and client

NodeJS cons:

  • Writing more Javascript

My latest gripe is with all the amazingly unintuitive behavior encountered while using Sinon. Sinon is a mocking framework, which is a kind of thing that interacts subtly with the nature of objects and modules and names in a programming language. In Python, these things are pretty easy to reason about, making mocking a breeze. I've been wrestling with Sinon for a few days now and am still being surprised by the contortions necessary to get mocks to work in the unfamiliar jungle of the Javascript module and name-binding system.