Fixing Heroku and SFDX CLI after upgrading to macOS High Sierra

macOS was just recently approved by Salesforce IT so I upgraded but only to find that my heroku CLI and SalesforceDX CLI tools had stopped working. I seem to remember that SalesforceDX is basically the same as the Heroku CLI so them failing together made sense. Running the tools only gave strange errors…

$ heroku
    stat /Users/mheisterberg/.local/share/heroku/client/bin/heroku: not a directory
    fork/exec /Users/mheisterberg/.local/share/heroku/client/bin/heroku: not a directory
$ sfdx
    stat /Users/mheisterberg/.local/share/sfdx/client/bin/sfdx: not a directory
panic: fork/exec /Users/mheisterberg/.local/share/sfdx/client/bin/sfdx: not a directory

goroutine 1 [running]:
panic(0x259de0, 0xc420017350)
	/usr/local/go/src/runtime/panic.go:500 +0x1a1
main.must(0x3c03c0, 0xc420017350)
	/home/ubuntu/.go_workspace/src/ +0x5c
main.getExitCode(0x3c03c0, 0xc420017350, 0xc420017350)
	/home/ubuntu/.go_workspace/src/ +0x12b
	/home/ubuntu/.go_workspace/src/ +0x14c

I started thinking it was an issue with node but it turned out to be caused by the command line tools for macOS having been uninstalled or needing to be updated. Below are the steps I used to install the command line tools, upgrade node (I’m using Homebrew) and fix the Heroku CLI and SalesforceDX CLI.

// update / install command line tools for macOS
$ xcode-select --install

// update homebrew
$ brew update

// verify my node version
$ node --version

// upgrade node
$ brew upgrade node
==> Upgrading 1 outdated package, with result:
node 9.3.0_1

// now to the real magic - fix heroku cli
$ rm -rf ~/.local/share/heroku/client
$ heroku update
heroku-cli: Updating to 6.14.43-73d5876... 12.7 MB/12.7 MB
heroku-cli: Updating CLI... already on latest version: 6.14.43-73d5876
heroku-cli: Updating plugins... done
$ heroku --version
heroku-cli/6.14.43-73d5876 (darwin-x64) node-v9.2.0

// rinse and repeat for SalesforceDX cli
$ rm -rf ~/.local/share/sfdx/client
$ sfdx update
sfdx-cli: Updating to 6.0.26-3d23012... 19.3 MB/19.3 MB
Installing dependencies for /Users/mheisterberg/Programming/repos/sfdx-l18n-plugin... done
sfdx-cli: Updating CLI... already on latest version: 6.0.26-3d23012
sfdx-cli: Updating plugins... done
$ sfdx --version
sfdx-cli/6.0.26-3d23012 (darwin-x64) node-v8.6.0

Websockets in an Express node.js app on Heroku

Last night I was having an issue with websockets and TLS in an Express.js node.js app. My websocket was working just fine when developing locally over plain HTTP but when I deployed the app to Heroku I received an error as that app runs over HTTPS but the websocket was still plain HTTP (using ws:// instead of wss://). Hmmm…. I started digging into websockets over TLS and how that would work without any luck. So I asked around but then it dawned on me and I answered my own question… Sometimes finding the answer is all about the question you ask 🙂

So the main realisation is that TLS connections are terminated by the Heroku router and forwarded to a web dyno hence there was no need to listen for TLS based websocket connections in my app. Also remembering how websocket connections are created is important. A websocket connection is a normal HTTP connection which is then upgraded to a websocket connection. So the real solution was to understand how a web dyno in node.js using Express could share it’s port with websockets using a HTTP server and that the same HTTP server would be used for both HTTP transport and websocket connections.

The solution was as follows:

const express = require('express')
const http = require('http')
const WebSocket = require('ws')

const port = process.env.PORT || 8080
const app = express()
const httpServer = http.createServer(app)
const wss = new WebSocket.Server({
    'server': httpServer

So in essence:

  1. Create the Express.js app (but do not set it up to listen in a port)
  2. Create HTTP server in node.js passing in the Express.js app
  3. Create websocket server agin using the HTTP server as the server
  4. Make the HTTP server listen on the port provided through environment variable

Dreamforce 2017 Playlist Generator

Looking for sessions from Dreamforce 2017 I found a list of sessions in a speadsheet and for fun I threw together a quick app to provider a better overview, allow me to filter the list easily and generate playlists on Youtube for select sessions. The app is written in node.js, is available on Github and is hosted on Heroku at After you authorize the app for Youtube it displays the list of sessions and you can generate playlists.

As a good friend of me always says – YMMV… Use at your own risk.

Deploy your own Salesforce Workbench on Heroku at the click of a button

The other day Salesforce Workbench was having issues. Generally it kept returning errors and SOQL queries took forever and timed out. Now Salesforce Workbech is a LAMP app that runs on Heroku and it turns out it is actually possible to deploy your own instance on Heroku using a simple Heroku Button. To do this simply follow the below steps (you need to have an account but if you don’t simply sign up):

  1. Go to the project page at
  2. Click the Deploy to Heroku button (use the button on the bottom and not the one on the top right as the one on the top right deploys and older version)
  3. Log into the deployed app (remember to add your security token after the password but I guess you knew that!!) and you are done!

Now you have your own instance of Salesforce Workbench running on Heroku. So nice. Below is a small video I recorded showing the actual steps and realtime – just over a minute and you have your own instance! Boom!!

Simplifying usage of Salesforce Lightning Design System using NPM and Express

Using Salesforce Lightning Design System (SLDS) is a great and easy way to add some super nice styling to your app. It comes with some nice defaults and a responsive grid system like other frameworks lige Bootstrap. Where SLDS really shines is of course if you are already using Salesforce (I assume you’re already on Lightning right?!!?!?) or if you are going to. And again who isn’t. Anyways… Using SLDS makes your apps really look like Salesforce which is nice for Salesforce Lightning Components or for an app using Lightning Out to host Lightning apps in external applications.

I often use SLDS for another use-case which is quickly doing a mockup for a new Lightning Component. Doing it in SLDS can often be way quicker than making by hand from scratch or attempting to draw the component using Powerpoint or other tool.

Previously I’ve been using the download option for SLDS ie. grabbing the package of the website, expanding and copying into my app. Today I tried out the NPM solution as I often use node.js and Express when I need to mock stuff up. Installing SLDS is as easy as doing a “npm install @salesforce-ux/design-system –save” and you’re all set. Mostly. Problem is of course that the assets you need end up in the node_modules directory which is not exposed outside the app. The way I get around it is to add a static-rule to my Express server.js as follows:

const app = express();
app.use('/slds', express.static(__dirname + '/node_modules/@salesforce-ux/design-system/assets'));

Then loading SLDS assets into my app is as easy as:

<link rel="stylesheet" type="text/css" href="/slds/styles/salesforce-lightning-design-system.css" />

This works great if/when you post your app to Heroku as well and has the additional benefit of easy version management using NPM and package.json.

Simple speedtest app deployed using heroku

My parents mobile broadband connection in their summer house seemed a little flaky and my father asked me how we could monitor it. Easy I thought. I would simply grab a Raspberry pi and one of the available tools so I googled and found a nice tutorial. Getting it to work was easy enough but after having this run for a few days the results were weird and didn’t match what we saw while there. So what do any self-respecting programmer do? Write his/her own of course… 🙂

So I broke out my language of choice (Java) and wrote a simple servlet I could use using curl. The servlet responds to GET and POST requests and hence allows me to measure download and upload speed. Using curl it was very easy to capture the connection time and the actual time to do the operation. Putting it all together using cron allowed me to run it on schedule and pipe the result to CSV files for later analysis.

Now I needed a place to run the app – the obvious choice was a free dyno on Heroku. To deploy I simply created an app, set two configuration parameters and then pushed using Git which in turn built, deployed and ran the application. So easy. And all using command line.

Next steps? Send the results to a Google spreadsheet using IFTTT to allow my dad to get the data himself and analyse to his hearts content…

The application is available at and the README explains the whole heroku deployment process.