Javascript has a surprisingly neat (and built-in) way to format currency values using it’s Internationalization API Intl.

It’s the sort of thing thats often forgotten when ‘internatinalising’ sites as the variation of display for numeric values isn’t widely appreciated. But using the Internationalization API it’s really simple to display numbers in the preferred format of your users.

To format a currency output, use Intl.NumberFormat:

const currencyFormatter = new Intl.NumberFormat('de', {
  style: 'currency',
  currency: 'EUR',

// -> "100,00 €"
const currencyFormatter = new Intl.NumberFormat('en', {
  style: 'currency',
  currency: 'EUR',

// -> "€100.00"

It’s a great API but does have some caveats, particularly if you use english formatting on certain currencies. For example, the Swedish currency Krona. With the Swedish sv locale in place the output will be 100,00 kr, so you might expect the en output to be 100.00 kr, however it displays SEK 100.00, which seems to be a fallback.

There is an additional argument currencyDisplay which in theory will enforce the output style, but even with it set to "symbol" (which is actually the default) in this case it doesn’t matter.

Mutt Forms Vue (MFV) is an extension to Mutt Forms, a tool for building HTML forms from JSON Schema definitions, to make it compatible with VueJS. By default, Mutt Forms renders HTML forms directly to the DOM, MFV uses Vue templating system in addition to offering some other benefits - like reactive properties.

MFV was developed in-house at Bought By Many, primarily to get a more robust integration with our VueJS apps. Mutt Forms works directly with the DOM which doesn’t play nicely with Vue, it’s a bit of an anti-pattern to mix these approaches so MFV was born to solve that issue. Like Mutt Forms, it has no dependencies (apart from Vue & Mutt itself) so it’s a tiny addition to any app, and is super fast at rendering even large complicated forms. It’s available for all on a standard MIT license.


MFV is easily installed from NPM, it’s recommended to use yarn but npm works just fine too:

yarn add mutt-forms-vue

Once installed, it can be hooked into Vue like most Vue plugins by using Vue.use(). This can be done anywhere during the app initialisation:

import Vue from 'vue'
import MuttVue from 'mutt-forms-vue'


Use with Webpack

MFV, like Mutt Forms, is written in ES6. You can use it directly but you may need to adjust your babel setup to have it transpile correctly. To avoid this, a bundled dist version is provided where the module has already been transpiled. You can include this version using the webpack alias syntax:

  "resolve": {
    "alias": {
      "mutt-forms$": "node_modules/mutt-forms/dist/",
      "mutt-forms-vue$": "node_modules/mutt-forms-vue/dist/"

NOTE: Depending on your setup, you may need a vue alias here also, MFV internally uses Vue templates - so you will need the template compiler, not just the runtime.

Getting started

MFV will extend Vue to add the components ‘mutt-vue’, ‘mutt-widget’ & ‘mutt-watcher’, as well as extending Vue to add a hook directly to Mutt (this is available as this.$mutt inside components). The components can be used to build forms (and form fragments) directly in Vue templates. In the simplest case, you can just pass a JSON schema to a ‘mutt-vue’ component and you will get a form:

    <mutt-vue v-bind:schema="schema" v-on:submit=”submitForm”>

export default {
  name: 'demo',
  data() {
    return {
      schema: {
        name: {
          type: 'string'
        email: {
          type: 'string'
  methods: {
    submitForm(form) {
      if(form.validate()) {
                JSON.stringify(, null, 2))

‘mutt-forms-vue’ also takes options, just as Mutt Form objects themselves do - in fact mutt-forms-vue components will take all of the arguments you might expect to send to a Mutt Form object.

A bit deeper

Under the hood of the mutt-vue component is simply iterating over (along with some helpful layout & functions) a set of Mutt form fields and renders each one using mutt-widget. You don’t have to do this however, if you want to create custom layouts or create form fragments you can use the mutt-widget component directly.

mutt-widget components expect a field as an argument and will render the corresponding HTML input interface for that field type. The mutt-widget component is itself polymorphic, and will inspect the field type to determine exactly how it should render. As is usual with Mutt, you can use field options to override default widgets for a given field, MFV will respect this too.

<mutt-widget v-bind:field="field"></mutt-widget>

Getting reactive

The final MFV component is called mutt-watcher. These can be used to reflect the value of a given field reactively. Internally MFV will make the field value reactive, which means should it change it will update other components reactively. ‘mutt-watcher’ exploits this, so you can create things like form summary panels or more intricate UI’s. As will mutt-widget, it requires a form field to be bound to it. It will render the field value in a text format in the format field name: <field value>, there are a few options to aid this display, but by default it will handle all of the data types Mutt understands.

It has a couple of neat uses, for example displaying the value of a hidden field that’s being updated behind the scenes elsewhere and it can even display form fields that aren’t otherwise rendered in the main form.

<mutt-watcher v-bind:field="field"></mutt-watcher>

Hopefully that covers some of the main features of MFV, there is a git repository available with all of these code samples in a working demo app. MFV is still under active development but at this stage it’s API can be considered pretty stable.

(If you end up using MFV in a project, would love to hear your experience!)

As someone who just can’t make the switch to Apple Maps permanently, it’s really no surprise to hear Google is winning this particular battle, but it’s incredible to see just how far ahead it is.

“Now, you can see 25 million new building footprints that have been added to Google Maps on desktop and mobile across major metropolitan regions in the United States, including Houston, Los Angeles, Chicago, Miami, and the San Francisco Bay Area.”

Great round up of the differences by Justin O’Beirne.

UML Sequence Diagram

UML might be 20+ years old at this stage but it’s still incredibly useful - especially when describing a Micro-service world.

Drawing the diagrams themselves, with a tool like VISO or OmniGraffle, does get old quite quickly though when changes are rapid.

I’ve started using Mermaid for generating the system diagrams from ‘code’ directly. It’s much less work as things change and is really easy to setup.

The simplest way to get started is to install the CLI version of mermaid:

yarn global add mermaid.cli

Once your up and running, you can produce diagrams by writing out a document containing the sequence:

	participant C as Client
	participant MS1 as Microservice 1
	participant MS2 as Microservice 2

    C->>MS1: Make Request
	activate MS1
    MS1->>MS2: Internal Request
	activate MS2
	MS2-->>MS1: Data
	deactivate MS2
	MS1-->>C: Response data
	deactivate MS1

And running the build command:

mmdc -i test.mmd -o test.svg

The syntax for generating the diagrams is reasonably intuitive, but there are a couple of gotchas - most of which cause the diagram to not render. It’s worth checking the diagram reference to make sure your syntax is correct as the CLI interface doesn’t give feedback.

Working with JSON Web Tokens (JWT) can be a bit awkward, particularly when using the command line to make requests, so I’ve created a little tool to make life easier.

It’s called hastilude and is available on NPM, to install run:

npm install -g hastilude or yarn global add hastilude

It allows for tokens to be generated from a static JSON file as well as to dissemble encrypted ones into a readable form.

Generating tokens

You probably already have a payload you want to send in a file (if not, you need to create one as a JSON string isn’t accepted as an argument), you can then use hastilude to generate a JWT token from it.


  "apples": "oranges",
  "black": "white"

from the command line, point at the file containing the the payload and set the secret:

hastilude generate --secret secret --payload test.json

This will output the token contents to command line. If you wanted to use it as a HTTP authorization header, say with HTTPie, you can add the --http flag to get the output:

Authorization:Bearer <generated token>

With HTTPie, that looks like:

http "`hastilude generate -s secret -p test.json --http`"

Dismantling tokens

You can also use hastilude to dismantle a JWT for you:

hastilude dismantle -t <your jwt token>

  "apples": "oranges",
  "black": "white",
  "iat": 1518723649,
  "exp": 1518725449

All contributions welcome, the Project is on github.

When you push to Heroku, the contents of the .git directory are usually removed which makes getting the last commit hash a bit tricky.

Luckily there is a Heroku labs extension you can use to get some of the git information back. Just run this command against your app:

heroku labs:enable runtime-dyno-metadata -a <app name>

This will add the following to the env (note - this only happens on the next deploy after configuring):

HEROKU_APP_ID:             4d00253d-b1dc-44dd-9949-106af8002de5
HEROKU_APP_NAME:           <app name>
HEROKU_SLUG_COMMIT:        731b2957b0ec6937cb8bbb0755aa8194e9f02600

If you want to use this info in Jeykll, you can add a small script to your _plugins folder to make this available:

module Jekyll

  class EnvVars < Generator

    def generate(site)
      site.config['source_version'] = ENV['HEROKU_SLUG_COMMIT'] || '<dev>'
      site.config['release_version'] = ENV['HEROKU_RELEASE_VERSION'] || '<dev>'



and you can then access the info under the {{ site.* }}.

Social logins can cause havoc with Google Analytics (GA) as visitors are typically directed away from your domain to the domain of the Social login provider. This ‘breaks’ the visitors session on your site, making the resulting return from the social provider appear as if it’s a new session.

There are a couple of approaches but it depends on the social login provider. Google logins are simple enough as they use the domain This can simply be excluded out right like you might with a payment processor (PayPal/Stripe etc..) by adding the domain to the excluded list.

Whilst this works for Google, this isn’t as useful for Facebook & Twitter - particularly if you use either as a way to drive traffic (or even care about referrals from them). Excluding the domains or will block out all referrals - it’s unlikely anyone wants this.

There doesn’t appear to be a way in GA to handle this scenario via configuration, there is only a code workaround. The answer is to have GA ‘blank’ the referrals from these social logins URL’s. You can add the following next to your GA setup:

var refs = [

if(document.referrer) {
  for(var i=0; i < refs.length; i++) {
    if(document.referrer.slice(0, refs[i].length) == refs[i]) {
      ga('set', 'referrer', '');

It should come after the ga('create', ...) call and before the ga('send', 'pageview', ...) call.

This will blank the referral from the social logins and stop new sessions being created.

NOTE: The example only works for a specific version of the Facebook API, if you are using another version (not v2.9) you should change the URLs to suit - or the code could be modified to support multiple versions.

Webfaction is a great host for small websites, particularly if they use a fairly generic setup, but it can be a bit tricky if you have to start tinkering under the hood. Unfortunately getting MongoDB running at this time isn’t quite as simple as using one of the other database options. Webfaction has a useful guide for setting up MongoDB initially but it doesn’t really go into detail about managing the MongoDB process once it’s all setup.

One of the omissions from the guide is getting the process to auto-start if the server reboots, as being a shared server a lot of the standard Linux configurations for services are out-of-bounds. It can still be accomplished using a Crontab however and hooking it to a startup script.

Once MongoDB is all setup on Webfaction, add three scripts in the bin directory of the MongoDB app:


NB you need to switch out ‘some port’ with port of the mongo app



Then edit your crontab to boot Mongo or a system reboot:

@reboot $HOME/webapps/mongo_db/bin/start

Voilà! Auto-rebooting on system reboot. It’s worth noting you may need to add an additional cron to reboot the process should it fail/crash.