Saying stuff about stuff.

What happens when null is passed to a JavaScript regular expression?

It’s quite possible that the following is not the expected consequence of passing null to a JavaScript regular expression — it certainly surprised me:

// => true

It looks like extra intentional work is being done to convert the value null to the string "null" whereas my assumption was that, particularly as it’s falsy, it would be interpreted as a blank string.

What’s happening?

I was impressed at how easy it was to find the answer in the ECMA spec that defines this behaviour. It turns out that it is doing extra intentional work to convert null to the string "null".

The spec also describes the following surprising (to me at least) cases:

// => true

// => true

// => true

/\[object Object\]/.test({ a: 1 })
// => true

/1,2/.test([1, 2])
// => true

One example that does feel natural is converting a number to a string:

// => true

But even this has some edge cases:

/Infinity/.test(1 / 0)
// => true

/NaN/.test(0 / 0)
// => true

Back to my problem, what’s the fix?

I could imagine this introducing a type of Scunthorpe problem — albeit with a relatively small window of opportunity — and for the non-falsy cases is the sort of issue that a type-checking system like Flow could help mitigate. Fortunately in my case the value was either a string or null so it was enough to default to an empty string:

var value = null
/null/.test(value || '')
// => false

Introducing Screamshot


I’ve been playing with programmatically fetching screenshots for years but never felt happy with the end result. Using PhantomJS directly seemed cumbersome and things didn’t work reliably for me when they reached production. It was whilst playing with Aesthetic that I learned how easy it was to use Capybara outside of a test environment as a tool for saving screenshots — I was struck by a thought:

My next screenshot-fetching app will use PhantomJS via Capybara and Poltergeist and will be just great!

— Me, before I’d written any code.

So I wrote a Rails app that receives a request, creates a database record, returns an identifier, queues up a job, fetches the screenshot and writes it to a file, and finally notifies the requesting app via a webhook that the screenshot is ready. It did seem a bit much for such a “simple” thing but I was quite pleased with it — and webhooks are cool. As usual it brought my server to its knees.

I started wondering about using Heroku which made me think that being synchronous might be the way to go — as in, the motivation was mostly $$$-driven… Anyway, I rewrote it again*.

It’s called Screamshot and can be found on GitHub, this time it’s synchronous and built on Sinatra and PhantomJS (via Capybara/Poltergeist).

Here’s how to use Screamshot:

$ curl ""

It has plenty of room for improvement: it doesn’t appreciate slow ad servers and therefore often times out, the fonts don’t look great, and it’s currently utilising the limited concurrency of WEBrick.

But I still like it*** — and you might too.

* To be honest part of my motivation for making this again is because I like the idea** for the logo!

** I said I like the idea for the logo…

*** Again, mainly just the logo and colour scheme.

This is amazing! I would love to spend my days performing this silliness.

White Wall

Img 3039

Database “postgres” does not exist

I recently encountered a strange error with PostgreSQL on my development machine:

psql: FATAL:  database "postgres" does not exist
DETAIL:  The database subdirectory "base/12641" is missing.

It was strange because most of my databases were working but a couple weren’t. Also, there was a postgres database - though the postgres role didn’t appear to exist. psql worked but psql -l would output the same error.

I didn’t want to lose my local data and spent a long time failing to find a proper fix - I tried a quick reinstall but that didn’t work either. In the end I resorted to blatting the current install and starting again.

How to dump/restore databases and reinstall PostgreSQL on a Mac with Homebrew

Dump any databases you wish to keep and stop PostgreSQL:

$ pg_dump -Fc --no-acl --no-owner my_database > my_database.dump
$ launchctl unload ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

Better to keep the existing data just in case this process needs to be rolled back:

$ mv /usr/local/var/postgres somewhere/safe

Reinstall and start PostgreSQL:

$ brew uninstall postgresql
$ brew install postgresql
$ launchctl load ~/Library/LaunchAgents/homebrew.mxcl.postgresql.plist

Create and restore the old database(s):

$ createdb my_database
$ pg_restore --no-acl --no-owner -d my_database my_database.dump

If your luck is as good as mine then you should have a fully working PostgreSQL install with your previous database(s).


I think this problem was caused by me not reading the instructions and blindly upgrading PostgreSQL with brew upgrade postgresql to go from 9.4 to 9.5. Or was it 9.3 to 9.4…

The proper way to migrate PostgreSQL data between upgrades

Here’s how to properly upgrade PostgreSQL data using pg_upgrade - though I’m sure I did this!

A Homage to jQuery Plugins

I wrote a little blog post on my company blog: a homage to jQuery plugins. It includes the phrase “front-end toolbox” which triggered my euphemism alarm but managed to slip through everyone else’s.


Last week I put together a Gem for use with the new Rails 3.1 asset pipeline, it packages up js-model and means you’ll never have right-click-save-as-move-to-directory ever again. Now all you have to do is include it in your Gemfile:

gem 'js-model-rails'

And require js-model in your application.js:

//= require js-model

Being able to manage JavaScript and CSS dependencies using Gems is a nice feature but it really starts to get interesting when you consider how a little backend integration can ease your frontend development. For instance, at the moment js-model-rails does something I always forget to do myself:

config.active_record.include_root_in_json = false

But in the future it’ll read your include_root_in_json setting and configure the JavaScript accordingly.

There are so many areas where having access to the backend environment will make working on the frontend much simpler. I’m not suggesting that every JavaScript library needs a corresponding Gem but in this case - and no doubt many others - it’s the start of a beautiful friendship.

Here’s the source on Github.

Using onScreen to power infinite scrolling

A while ago I wrote a really simple jQuery plugin called onScreen that adds a selector to filter out elements that are currently visible on the screen. Here’s a quick snippet of jQuery that uses it to help power infinite scrolling.

$(function() {
  function loadMorePosts(post_id) {
    var path = "/posts?offset=" + post_id
    if (history.pushState) history.pushState({}, null, path)

  // Every second check if the last post is on-screen, if it is
  // then load the next chunk of posts.
  setTimeout(function() {
    var post = $(".post:last:onScreen")
    if (post.length) loadMorePosts("id"))
  }, 1000)

Fixing the port number in OmniAuth callbacks with a Varnish/nginx/Passenger stack

My current server setup is thus: Varnish on port 80 and nginx (with Passenger) on 8080. Unfortunately my Rails app thought it was running on port 8080 and therefore my OmniAuth/Twitter login was returning to the wrong URL - something along the lines of… .

I tried setting X-Forwarded-Port etc in Varnish and fastcgi_param SERVER_PORT 80; in nginx, both without success. However, if you are using Passenger then you want to set:

passenger_set_cgi_param SERVER_PORT 80;

Here are the docs - they say you can set it in an http block but that didn’t work for me and I had to add it to the server block.

Anyway, this solved my problem and will hopefully help a few more people.

Finding a DOM node’s common ancestor using JavaScript

I recently ran into a problem where I needed a way to find the common ancestor of two DOM nodes (using JavaScript). I wasn’t happy with the accepted answer I found on Stack Overflow so I made my own.

function parents(node) {
  var nodes = []
  for (; node; node = node.parentNode) {
  return nodes

function commonAncestor(node1, node2) {
  var parents1 = parents(node1)
  var parents2 = parents(node2)

  for (var i = 0; i < parents1.length; i++) {
    if (parents2.indexOf(parents1[i]) > -1) return parents1[i]

  throw "No common ancestor!"

Unfortunately, after working with Mr Blimke for so long this first algorithm is no longer good enough for me as it has an efficiency of O(N1 * N2) - basically O(N2).

So I thought a little longer and made some simple changes. The new algorithm has efficiency O(N) and a bonus of detecting whether the nodes are actually related before attempting to compute anything.

function parents(node) {
  var nodes = []
  for (; node; node = node.parentNode) {
  return nodes

function commonAncestor(node1, node2) {
  var parents1 = parents(node1)
  var parents2 = parents(node2)

  if (parents1[0] != parents2[0]) throw "No common ancestor!"

  for (var i = 0; i < parents1.length; i++) {
    if (parents1[i] != parents2[i]) return parents1[i - 1]

The thing is, I imagine there are even more efficient solutions but this one will have to do for now! Anyway I added it as an answer to the original Stack Overflow question so mod it up if you like it!