Grab Bag: pmset, APIs, & Promises
Daily Standup
January 12, 2019
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](https://appletoolbox.com/2018/10/how-to-fix-macos-mojave-battery-draining-issue/) 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](https://www.dssw.co.uk/reference/pmset.html) 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 |
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](https://medium.com/studioarmix/learn-restful-api-design-ideals-c5ec915a430f) 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.
React
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() { |
Then I called the helper function in one of my routes:
router.get('/:id/add-production', (req, res, next) => { |
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 http://goo.gl/rRqMUw |
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) => { |
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.