This has been a project in the making for months (years?) and it’s finally in a state I can call “done”. I now have a string of LED lights hanging above my balcony that can be controlled from a phone.

There’s still work to be done, including adding patterns that aren’t just sweeps through the rainbow. Now that this is something that can actually be used, I hope to keep up the work and continue contributing to it.

Also, I really liked the way they made our fig look:

Github project: https://github.com/beekley/PiLights

Video and screenshots: https://imgur.com/a/A3Z7iDl

I started a new job a little over four months ago and, entirely coincidentally of course, I haven’t posted or worked on anything on github in over four months. Last summer and last year in general was a big sprint for personal projects and hobbies. I got a lot done but also got a little burned out.

But it’s (February) 2018 and time to get back on the horse! I have the first homebrew of the year ready for bottling tomorrow and it’s the first candidate for a batch we’re brewing for a friends’ wedding. Recipe here!

There’s a new project that has me really excited: I’m DMing a Dungeons and Dragons group at work. A couple coworkers and I were talking about podcasts and other nerdy media and naturally my favorite live D&D podcast (#TheZoneCast) came up. They said they’ve always wanted to play and I’ve always wanted to DM. We got it going and have a group of 9 who hop in and out of the party.

We’ve had three encounters and couple bookkeeping sessions to create characters and level up. I think it’s gone pretty well so far. Every session goes longer than I plan– including one 5 hour marathon encounter one Wednesday evening. The players just keep getting more into it and that pumps me up.

There are a few logistical quirks with having a group of 9 characters. The party hasn’t and likely won’t ever be consistent, so we’ve been starting and ending each session at a home base– an inn in Neverwinter called The Winter Rose. This is actually pretty nice since it bookends each adventure and gives the characters a familiar place to get to know. Another problem we’re still working on is how to share loot and info with characters who might not have been there for a previous session. We’ll figure it out.

And now, a little overview of the adventure so far.

Our story begins as many do in the Forgotten Realms, at an inn. Our heroes find themselves sharing a beer, perhaps their first together, when a half-orc approaches them and asks to join their party for the last day of travel to Neverwinter. They accept and head out the first thing the next day. Their new companion was not as friendly as (some of them) expected and led them into an ambush. Our heroes were victorious and made it to Neverwinter with a mysterious elven cloak and shiny black gemstone embedded in lockbox used as bait.

The gang then came across a looted merchant cart in the canals of Neverwinter. Follow a trail of goblins, they clear out a sewer lair led by a bugbear named Klarg and free a knight of the Protectorate named Sildar.

When the Protectorate tries to send a reward to the inn where the gang is staying, the knight is attacked by a mob of freedom-fighters. Our heroes (mostly) help the knight, Giles, and fend off the attackers. As a reward, they are given Sildar’s Protectorate-issued magical dagger.

More adventure (and possibly scheming by our heroes) awaits!

It’s no secret (nor surprise) that async/await is one of the most anticipated features of ES8/ES2017. While there are lot of great resources already about the magic of the await keyword, its unsung sidekick async hasn’t gotten the same attention.

If you’ve used async/await before, you know that async is what allows await to work and is required in the nearest-parent function declaration of any use of the await keyword. Without async, await would just block code execution. That would negate JS’s asynchronous nature, one of JS’s best features and the reason JS can be used server-side (e.g. in Node). In order to do this, async makes the function, well, asynchronous by making the function return a promise, allowing other code to continue running while it awaits.

The side-effect of this is that async makes writing promised-based asynchronous functions both simple and synchronous-like:

1. The promise returned by an async function resolves using .then() — just like any other promise — when the function returns, with the value that is returned — just like a synchronous function
2. The promise returned by an async function catches an error using .catch() when the function throws an error

Let’s say we have a function that returns a promise that resolves after it gets some data from an API. Using promises, this might look like the following:

const withPromise = () => {
  return new Promise((resolve, reject) => {
    request(‘https://google.com')
    .then((data) => {
      // Pass data to promise resolution
      resolve(data);
    })
    .catch((err) => {
      // Reject with error
      reject(err);
    });
  });
}

Which requires instantiating a new Promise object, then calling .then, .catch, resolve and reject function. Promises require a lot of baggage to get them to work, not to mention a whole set of vocabulary unique to them.

Using async, we can achieve the same in a few lines

const withAsync = async () => {
  try { return await request(‘https://google.com') }
  catch (err) { throw err }
}

Which not only is concise and reads just like synchronous code, but will return a promise just like the first snippet.

withPromise().then(data => console.log(data));
withAsync().then(data => console.log(data));

(The above snippets use request-promise, a module to make http requests that return promises. They’re also trivial functions that just wrap around the the request method. Also on Medium.)