Solving my Sonos morning alarm problem

I’ve jumped on the Sonos bandwagon a while back and I have a couple of Sonos players around the house. One in the bathroom, one in the kitchen, in the living room etc. I’ve been using them with alarms in the morning (weekdays only) so that the bathroom one tuned in to local radio (streamed of course) at 5.30am, the kitchen one joined in at 6am and then the upstairs one at 6.30am when it’s time to wake the kids. The problem with this setup is that Sonos does not offer a way to let the players join into the same group meaning that eventually / sometimes they will be slightly apart in the streaming of the audio which is really annoying. I’ve been looking for a solution for a while but didn’t find a solution until now.

My solution has been to use the node-sonos-http-api running on a Raspberry Pi and using cron. Very simple really. Basically the node-sonos-http-api offers up a local HTTP server on port 5005 that accepts GET requests to perform actions on players such as playing, tuning in to Tunein stations, joining groups etc. So I have a couple of cron jobs that first thing makes sure the bathroom player leaves any other group it might be in, sets the volume and then tunes into the radio station. Later the kitchen players volume is set and the player joins the bathroom player and so on. Very cool and works like a charm.

The biggest problem turned out to be getting node and npm installed on the Raspberry Pi v.2 I’m using but downloading the binaries manually and installing manually (unzipping really) instead of using apt-get worked like a charm. Then I simply run the node-sonos-http-api server on startup and have cron do the requests using curl chaining multiple requests together using && where necessary i.e. when I need to change volume and join a group in one cron job.

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/github.com/heroku/cli/io.go:115 +0x5c
main.getExitCode(0x3c03c0, 0xc420017350, 0xc420017350)
	/home/ubuntu/.go_workspace/src/github.com/heroku/cli/main.go:42 +0x12b
main.main()
	/home/ubuntu/.go_workspace/src/github.com/heroku/cli/main.go:28 +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
v8.8.1

// 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

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 df17playlistgenerator.herokuapp.com. 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.

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.