Naughty @kwik_fit and the hidden unsubscribe buttons

After one too many “spam” emails in my inbox this morning, I started to unsubscribe from them. It turns out that certain companies have some interesting, naughty, tricks to make this as difficult as possible. KwitFit for example have a hidden image with the default pointer cursor to make it near impossible to identify how to submit your request.

Naughty KwikFit

Summary of my top tweeted links during March

Top Tweets sent via BufferApp

Saturday 30th March
WOW!!! RT @ShawnWildermuth: Call me impressed with this HTML5 Canvas example: (tear it up) http://bit.ly/15YqPog
6 Retweets 0 Mentions 12.8k Potential 9 Favorites 140 Clicks

Wednesday 27th March
“Losing pride in what you’re doing turns you into a zombie” http://bit.ly/YeZY7J
5 Retweets 2 Mentions 7.3k Potential 1 Favorite 63 Clicks

Tuesday 26th March
How to hire a product manager – by Ken Norton http://bit.ly/UV6QmD
3 Retweets 0 Mentions 4.6k Potential 2 Favorites 363 Clicks

Sunday 24th March
9 Simple Tricks to Improve the OS X Finder http://bit.ly/YSUa36
1 Retweet 0 Mentions 3.4k Potential 5 Favorites 43 Clicks

Flat UI Design | A showcase of flat UI design http://buff.ly/WYICbL
1 Retweet 0 Mentions 3.6k Potential 6 Favorites 224 Clicks

Saturday 23rd March
Most Startups Should be Deer Hunters http://buff.ly/ZvV8UN
0 Retweets 0 Mentions 3.3k Potential 5 Favorites 102 Clicks

Git file permissions and bash scripts

This took me a very long time to figure out.

When committing files to git, the file permissions are also committed. https://github.com/BenHall/heroku-buildpack-mono/commit/cb85e7fbc6e3f9cc646e7e3394d67419d1dbdfe4#bin/detect

What this means is that when you clone the git repository, it has the nessary file permissions required to be executed. What it also means is if you don’t commit the files with the correct permissions, nothing works.

Storing Node.js application config data

I’ve tried multiple approaches to storing application configuration with Node.js but most have been painful until I found this solution.

tl;dr: Executable configuration FTW via exports.

With Node.js you can export an object or function for use within another module. This is key to keeping your Node.js application readable and structured which as I’ve found can be an art-form in itself.

My current approach is as follows.

I have a config.js which looks like this.

var url = require(‘url’)


var config = {}


config.google = {};
config.redis = {};


config.google.id = process.env.GOOGLE_ID || ‘DEVELOPMENT.googleusercontent.com’;
config.google.secret=  process.env.GOOGLE_SECRET || ‘DEVELOPMENT’;
config.google.callback=  process.env.GOOGLE_CALLBACK || ‘http://127.0.0.1:3000/google/callback’;


config.redis.url=  url.parse(process.env.REDISTOGO_URL || ‘http://127.0.0.1:6379’);


module.exports = config;

Because it’s a standard JavaScript module, when Node.js loads the file it will be executed with the config hash created. This has two important aspects.

Firstly, I can include other helper modules, such as being able to return a parsed url.

Secondly, I can take advantage of the current environment to determine if production or development values should be returned. This is great when combined with Heroku.

With the configuration defined, the logic to access the configuration looks like this:

var config = require(‘./config’)
var id = config.google.id
var url = config.redis.url

No if statements, no redefining variables, no swapping files around. Clean, simple, effective.

If I wanted to have additional confidence then if NODE_ENV equaled production I could ensure all environment variables are not undefined.

This is working for me, but has anyone found any better solutions? Leave a comment or tweet me @Ben_Hall