Grab Bag: pmset, APIs, & Promises

Daily Standup

Bit of a grab bag of learnings today!

MacOS Mojave Power Management Settings

The other day I wrote about playing around with my laptop's power settings. Since updating to MacOS Mojave, the battery was draining overnight while the laptop was in hibernate mode. [This article]( gave a pretty good explanation of what was happening and some things to try to fix it. Then later I came across a [more complete manual]( for `pmset` so I actually understood what the article was suggesting 😂

Since the issue only presented itself while hibernating without being plugged in, I only needed to change the battery settings (-b) rather than the settings for all power modes (-a) like the article recommended. In the end I settled on the following:

$ pmset -g
System-wide power settings:
Currently in use:
standbydelaylow 10800
standby 1
halfdim 1
hibernatefile /var/vm/sleepimage
powernap 0
gpuswitch 2
disksleep 10
standbydelayhigh 86400
sleep 1 (sleep prevented by sharingd)
autopoweroffdelay 28800
hibernatemode 3
autopoweroff 1
ttyskeepawake 1
displaysleep 15
highstandbythreshold 50
acwake 0
lidwake 1
$ sudo pmset -b standbydelayhigh 60
$ sudo pmset -b standbydelaylow 60

And the issue went away!

API Endpoints Continued

Last time I also wrote about how I'd been listening/reading into nested API endpoints. Today I worked on implementing this into my API and there was a lot to consider. [This article]( gave a good discussion on some of these considerations, and more. For example:
  • pre-fixing all API endpoints with v1, v2, etc. future-proofs use of your API, in case major changes are needed in the future.

I also learned that a Google API Design Guide exists, and another one based on the Heroku HTTP API.


The more I work on this app, the more I can see how and why React is really useful. For example, I am making a lot of queries to the database to get information that’s needed at the app level. However since I’m rendering each page with EJS, I have to query the database for each page. With React, I could make fewer queries and save the relevant information in the app’s state, which makes a cheaper and more efficient database setup.

Now, I obviously don’t have any familiarity (yet) with querying data using React, so it’s possible I understand it wrong. BUT, if that’s in fact how it works, then it would be a big improvement on what I’m doing now.

Remembering Promises

I ran into an issue with a Sequelize Promise from a helper function:

My helper function would query the database to load all venues:

function loadVenues() {
return Venue.findAll({

Then I called the helper function in one of my routes:

router.get('/:id/add-production', (req, res, next) => {
Show.findByPk( => {
loadVenues().then(venues => {
res.render('productions/new', { show: show, venues: venues });

This worked and everything rendered properly in the app, but I got an error from the action:

(node:16076) Warning: a promise was created in a handler at path/shows.js:33:3 but was not returned from it, see
at Function.Promise.attempt.Promise.try (path/node_modules/bluebird/js/release/method.js:29:9)

I tried all kinds of things to fix this because I haven’t worked with promises in this way in a while (maybe ever?). In the end all I needed to do was amend the route function to return loadVenues, even though the helper function already returns:

router.get('/:id/add-production', (req, res, next) => {
Show.findByPk( => {
return loadVenues().then(venues => {
res.render('productions/new', { show: show, venues: venues });

Other Stuff

GitHub finally announced free private repos! As a result I consolidated all of my repos onto GH and saw my contributions graph for 2018 go from 390 to 804 contributions 😃

Up Next

Today I added a form to GFT to be able to create a new production; next is to handle the form & persist its data.