Forem: Steven Washington

Understanding Permissions

Steven Washington — Thu, 18 Jul 2019 10:39:38 +0000

Every so often I’ll be setting up a project and run into file permission issues. Most times, I’ll Google the error and come across a forum post that’s something like

Just type chmod 755 ./file.txt in Terminal and you’ll be fine.

So while this works, it would be much better if I actually knew that this line was doing.

The first part is easy: chmod is the name of the process that actually changes the permissions on the file I want.

The last part is even easier: It’s the path to the file I want to change the permissions on.

But that’s that 755 about? How does that relate to file permissions?

Unix permissions basics

Very basically, file permission roles are broken up into 3 types of people: User, Group and World.

User is the owner of the file.

Group is a special set of users can have special privileges on the file.

Others is everyone else.

Additionally, there are four types of permissions: Read, Write, Execute, and None. Read, Write and None are self explanatory. Having the “execute” permission means that you can run the file, as opposed to simply opening it or editing it. This is usually for files that are executable by the system like shell scripts or similar.

For example: If you have Read and Write permissions for ./file.sh, you can open it, and you can edit it. But without the “Execute” permission, you can’t run the script.

Viewing Permissions

Try something out for me: Open up a terminal, go to a directory with a bunch of files, and type ls -l. This will list all the files in the directory (ls) in a long format (-l). You’ll get something like this:

Look on the very left column, and you’ll see a combination of 10 r’s, w’s, x’s, and -‘s. This is not a random jumble of letters, but actually a lineup of permissions:

The first digit is the directory flag. If the row describes a directory, it’ll be d, otherwise it will be -
The next three digits are the User permissions. This is set up in order rwx or “Read, Write, E x ecute.
The next three are the Group permissions, set up the same as the User
The next three are Other permissions

Let’s take this line for example

-rw-r--r-- 1 stevewashington staff 805 Jul 17 19:11 package.json

We can take that first column, and break it up into 4 sections:

- >> This is the directory flag. package.json is not a directory, so this is ’-’

rw- >> these next three digits are the “User” section. So the Owner (“stevewashington”) can Read the file, Write to the file, but not Execute it.

r-- >> These are the “Group” permissions. Anyone in the defined Group (“staff”) can read the file, but not write to it or execute it.

r-- >> These are “Other” permissions, which are the same as “Group,” can read, but not write or execute.

Okay but what about the numbers?

The number in the chmod command (755 in the example above) are in “octal”, or base-8. Each digit can hold a number from 0-7, and the number 8 is “10” in octal.

You may notice that the number has 3 digits. You may also see that there are three permissions roles, User, Group, and Other. Put these together, and you can read these as separate permission sets: User is 7, Group is 5, and Other is also 5.

So now we just need to convert each digit from octal to a set of 3 letters: rwx. And we will be using binary as an intermediary:

	Octal/Decimal	Binary
User	7	111
Group	5	101
Other	5	101

Here we have the conversions for each digit in 755 to binary (as in “seven, five, five”, not “seven hundred fifty five”)

Here’s another “coincidence”, the binary numbers also have 3 digits! So we can turn on or off “rwx” flags based on whether the binary number is 1 or 0:

	Octal/Decimal	Binary	Permissions
User	7	111	rwx
Group	5	101	r-x
Other	5	101	r-x

If we mash them together, we see that chmod 755 ./file.txt means:

Change ./file.txt so that:

the owner can read, write, and execute it

the defined group can read it and execute it

everyone else can also read and execute it

Knowing this, this is actually fairly open permissions for a file. Are you use you want absolutely everyone to be able to execute a program on your server? 🤔

Using the package.json example from above, we can work it out backwards:

	Permissions	Binary	Octal/Decimal
User	rw-	110	6
Group	r—	100	4
Other	r—	100	4

So copying the permissions of package.json we’d use something like chmod 644 ./file.txt. This means for package.json:

the owner can read, write, but not execute it

the defined group can only read it

everyone else can only read it as well

Which makes sense! You can’t really “execute” .json files, so there’s no reason to give that permission to anyone.

Conclusion

This was a basic overview of Unix(-like) permissions and how to understand them. Now you know what chmod 755 ./file.sh means, and can make smart decisions to fix your issue. This is a crucial part (and only a part!) in keeping your files and server safe.

Photo by Alex Martinez on Unsplash

DemandPad

Steven Washington — Wed, 22 May 2019 22:01:49 +0000

Basic Info

Link to Application

Github Repo

Goal

This was a personal project with a personal goal: have a quick utility to open up and take notes.

In the past, I would have a bookmark to open a url:

Try it!* It will open up a blank webpage that you can type in. This is great for jotting down quick notes (just like a post it note), with almost no system overhead, having to open a separate program, having to find a pen, etc.

* Type the URL from the screenshot, unfortunately I can't type such a data URI into the body of this post. Check out this issue on Github, seems to be an issue to prevent XSS.

However, this approach has one major shortfall, saving. Once you close the tab, the notes are gone forever, akin to tossing the post-it note. Sometimes I would leave this tab open for days, only to despair when I accidentally closed it, or an overeager update would restart my computer.
My solution is to make a webapp that is nearly as light as the dataURI, but with the ability to save and load previous notes.

Saving/Loading mechanism

Notes are saved/loaded from the browser's localStorage. The mechanism saves on every keypress, serializing all the note data into a JSON string and saving it into the local store (which can only save strings).

One big limitation of this is the fact that notes don't "travel" with me, so any new device I use will have its own set of notes. This also applies to separate profiles (at least in Chrome) on the same machine. I use separate profiles for my personal (Google) and work (GApps) accounts. This means that the notes don't "cross-pollinate," for better or for worse.

Deleting Notes

Deleting all notes is fairly easy, it is simply a matter of setting the localStorage key to an empty string. Easy.

It's a bit more complicated to delete a single note, which involves messing with an array, removing an item and ensuring the rest of the items are still ordered properly.

Another issue with deleting single notes is making sure that the user really wants to delete it. This is usually handled by some sort of confirmation message. I have a similar mechanism working on ReactVN

This time, I wanted to try something a little different, inspired by a game that I was deep in at the time: Destiny 2. In that game, you can delete items from your inventory by holding a button. At that point a bar begins to fill up. If you release the button the bar resets, but if you hold the button until the bar fills, the item is removed. This is sort of a fun interactive way to confirm the user wants to delete the item without extra dialongs and extra mouse motion.

(They also give priority to various items by changing the color of the bar and how long it takes to delete something! I could go more into it, but maybe for another time).

Basically, I liked this interaction for confirming deletion, and reimplemented it in React, using setTimeout and state to update a value which drove the CSS property width. For performance reasons, it may have been better to use transform:scale(x) instead of width, since width causing the browser to re-layout which hurts performance and frame rate. Got an issue for that now.

You can see the underlying code for the DeleteButton component here

Process

This personal project I tried to implement a Git workflow of always creating feature updates on a separate branch, and making a pull request to bring the updated and tested change into master. This was great to get in the habit of this sort of flow. It's also cool to go through Github and see the issue/commit/pull request history and see where certain changes happened at a glance. I still like doing git actions via the command line, especially to truly understand what's happening, but using Github in this way has been a great way to explore all the integration features the service has.

In addition, Netlify will take note of pull request, automatically building them in a Deploy Preview. This made it really nice to test out changes in the live environment as the local server from create-react-app isn't always the same.

Underlying Tech

DemandPad is built in React. Everything is client side, using built in browser APIs. Hopefully one day I will update this to use a 3rd party auth service (Netlify Identity, anyone?) which will also allow the notes to be saved in the cloud, to avoid the saving issue mentioned above.

Hosted on Netlify, which has been my go-to lately for putting a front-end project online.

Screenshots

My Development Graveyard, Part 1

Steven Washington — Tue, 14 Aug 2018 00:00:00 +0000

The concept of a Github Graveyard was started by Isaac Lyman in this dev.to post. The idea is to go through all your old projects that you never touch anymore and remember where you’ve come from to help you get to where you’re going. I loved the idea immediately, and decided to start my own!

aterriblefate

Background: This is a simple, single page site, mostly to test out how Github Pages worked. I got the idea on New Year’s 2018, to create a countdown to the next year that looks like the “x days remain” cards from the Legend of Zelda: Majora’s Mask.

What I Learned

Working with Javascript dates
Additional Practice matching styles

Why it died: This is actually alive at http://aterriblefate.net. There are bugs that have popped up (mostly due to spacing and text sizing) since testing with the date Jan 1 2018 yielded limited results. This was never a serious project, so my attention was grabbed away from this pretty quickly.

washingtonsteven.github.io

Background: An older version of my personal site, built with Jekyll for hosting on Github Pages (now I’m using Gatsby and hosting on Netlify).

What I Learned

First step into static site generators, using Jekyll
Github Pages / Domain management

Why it died: I didn’t like the design I came up with, mainly. This was also just after I dove headfirst into react, and was itching to try more react-based projects (such at Gatsby!).

react-json-component

Background: As I was learning more about React, I came across some situations where JSX just wouldn’t cut it. In this case I dug into React.createElement directly to create my components. I eventually wrote some login to take some specially formatted JSON, and spit out actual React Components.

The next step was to create a library that cleanly does this for you, rather than the logic I wrote that was wrapped up in other, application specfici logic

What I Learned

Deeper dive into React component creation
Incidentally, I also dove into what is necessary to create and publish a React Component on npm (even though this one was never published). In addition, taking considerations to keep the component generic enough to fit a wide array of situations that people will throw at it.

Why it died: It had mostly run its course, really. This was more of an exercise in React rather than a final living, breathing project. Rest in Peace.

genmo

Background: Before ReactVN was a thing, my first foray into text adventures was a little command line tool. My eventual plan was to have this become a simulation which can generate a series of actions in a fictional world and generate a short story for submission to NaNoGenMo, National Novel Generating Month.

What I Learned

This was my first look into building command line tools and a deep dive into node system calls
I also built out genmo as an API to be integrated into any sort of app, and in fact included a call-and-response type adventure into a Slack bot.

Why it died: I would love to clean this up one day, but a lot of the logic did end up being sort of “spaghetti” by the end of it, fixing and patching bug after bug instead of thinking of the problem holistically. At this point updates and fixes would be incredibly cumbersome and locked to original design ideas. Next step here would be to do massive refactor, to the point of a possible rewrite.

That’s it for part 1! Like many I have a bunch of projects in my past to look over, so look forward to the next one!

React's new Context API and Actions

Steven Washington — Sat, 31 Mar 2018 11:19:41 +0000

Photo: Daniel Watson

Edit: 4/2/2018 - It was pointed out to me that the example in this post had a performance issue, where render was called on Consumers unnecessarily. I've updated the article, examples, and the CodeSandbox to rectify this.

The new React Context API (~~coming soon~~ now here! in React 16.3) is a massive update of the old concept of context in React, which allowed components to share data outside of the parent > child relationship. There are many examples and tutorials out there that show how to read from the state provided by context, but you can also pass functions that modify that state so consumers can respond to user interactions with state updates!

Why Context?

The context API is a solution to help with a number of problems that come with a complex state that is meant to be shared with many components in an app:

It provides a single source of truth for data that can be directly accessed by components that are interested, which means:
It avoids the "prop-drilling" problem, where components receive data only to pass it on to their children, making it hard to reason about where changes to state are (or aren't) happening.

B-but Redux!

Redux is a fantastic tool that solves these problems as well. However Redux also brings a lot of other features to the table (mostly around enforcement of the purity of state and reducers) along with required boilerplate that may be cumbersome depending on what is needed. For perspective, Redux uses the (old) context API.

Check out this article by Dan the Man himself: You Might Not Need Redux

What's Context do?

There are plenty of articles on this (I particularly like this one), so I don't want to go into too many details about how this works. You've seen the examples so far, and they're mostly missing something: how to update the state in the provider. That state is sitting there, and everyone can read it, but how do we writeto it?

Simple Context Example

In many of these examples we make a custom provider to wrap around React's, which has its own state that is passed in as the value. Like so:

`context.js`

import React from "react";

const Context = React.createContext();

export class DuckifyProvider extends React.Component {
  state = { isADuck: false };
  render() {
    const { children } = this.props;
    return ( 
      <Context.Provider value={this.state}>
        {children}
      </Context.Provider>
    );
  }
}

export const DuckifyConsumer = Context.Consumer;

Seems simple, enough. Now we can use the DuckifyConsumer to read that state:

`DuckDeterminer.js`

import React from "react";
import { DuckifyConsumer } from "./context";

class DuckDeterminer extends React.Component {
  render() {
    return (
      <DuckifyConsumer>
        {({ isADuck }) => (
          <div>
            <div>{isADuck ? "quack" : "...silence..."}</div>
          </div>
        )}
      </DuckifyConsumer>
    );
  }
}

export default DuckDeterminer;

Passing Functions

Now, what if we wanted to emulate a witch turning something into a duck (stay with me here)? We need to set isADuck to true, but how?

We pass a function.

In Javascript, functions are known as "first-class", meaning we can treat them as objects, and pass them around, even in state and in the Provider's value prop. It wouldn't surprise me if the reason why the maintainers chose value and not state for that prop is to allow this separation of concepts. value can be anything, though likely based on state.

In this case, we can add an dispatch function to the DuckifyProvider state. dispatch will take in an action (defined as a simple object), and call a reducer function (see below) to update the Provider's state (I saw this method of implementing a redux-like reducer without redux somewhere, but I'm not sure where. If you know where, let me know so I can properly credit the source!).

We pass the state into the value for the Provider, so the consumer will have access to that dispatch function as well.

Here's how that can look:

`context.js`

import React from "react";

const Context = React.createContext();

const reducer = (state, action) => {
  if (action.type === "TOGGLE") {
    return { ...state, isADuck: !state.isADuck };
  }
};

export class DuckifyProvider extends React.Component {
  state = {
    isADuck: false,
    dispatch: action => {
      this.setState(state => reducer(state, action));
    }
  };
  render() {
    const { state, props: { children } } = this;
    return <Context.Provider value={state}>{children}</Context.Provider>;
  }
}

export const DuckifyConsumer = Context.Consumer;

Note that we have dispatch in our state, which we pass into value. This is due to a caveat in how the need to re-render a consumer is determined (Thanks, Dan for pointing that out!). As long as the reference to this.state stays pointed to the same object, any updates the make the Provider re-render, but don't actually change the Provider's state, won't trigger re-renders in the consumers.

Now, in DuckDeterminer, we can create an action ({type:"TOGGLE"}) that is dispatched in the button's onClick.

(We can also enforce certain action types with an enum object that we export for the DuckifyContext file. You'll see this when you check out the CodeSandbox for this)

`DuckDeterminer.js`

import React from "react";
import { DuckifyConsumer } from "./DuckContext";

class DuckDeterminer extends React.Component {
  render() {
    return (
      <DuckifyConsumer>
        {({ isADuck, dispatch }) => {
          return (
            <div>
              <div>{isADuck ? "🦆 quack" : "...silence..."}</div>
              <button onClick={e => dispatch({ type: "TOGGLE" })}>
                Change!
              </button>
            </div>
          );
        }}
      </DuckifyConsumer>
    );
  }
}

export default DuckDeterminer;

The secret sauce here is the dispatch function. Since we can pass it around like any other object, we can pass it into our render prop function, and call it there! At that point the state of our Context store is updated, and the view inside the Consumer updates, toggling on and off whether the duck truly exists.

Extra credit

You can (read: I like to) also add a helpers field alongside state and dispatch, as a set of functions that "help" you sift through the data. If state is a massive array, perhaps you can write a getLargest or getSmallest or getById function to help you traverse the list without having to split the implementation details of accessing various items in a list in your consumer components.

Conclusion

Used responsibly, the new Context API can be very powerful, and will only grow as more and more awesome patterns are discovered. But every new pattern (including this one, even) should be used with care and knowledge of the tradeoffs/benefits, else you're dipping your toes in deaded antipattern territory.

React's new context API, is incredibly flexible in what you can pass through it. Typically you will want to pass your state into the value prop to be available to consumers, but passing along functions to modify state is possible as well, and can make interacting with the new API a breeze.

Try it out

The DuckDeterminer component is available to play with on CodeSandbox, right now!

ReactVN

Steven Washington — Mon, 12 Mar 2018 00:00:00 +0000

React VN is a Visual Novel Editor and Player for playing and writing text adventures.

NB: this is an older project that I had sitting in my drafts for a while. This has been live on my site for a while, so no time like the present to publish here! Some statements in here are a bit...dated...however.

Technology

React

React VN was written for the web with Javascript, using React as a framework for the data and managing interactions.

create-react-app

The React setup was scaffolded with Create React App, and then was ejected for a few reasons:

Adding Sass compilation (using sass-loader) - Faciliating a special build that only builds the Player (default build includes the Editor)

React 16.3 Context API

This project also makes used of the new (and unreleased, at the time) React Context API. The Context is set up in src/data/StoryContext.js. In that file there is a StoryProvider that wraps around the default Context.Provider component that providers the story data to the consumer. However it also exposes several functions that serve as an API for the storyData: helper functions (for quick access for nodes) and actions (for modifying nodes).

Deployment

Concept

The application is split up into two separate deployments, an “editor” build and a “player” build. The Editor includes tools to create a new story, edit an existing one, and export a story to a .json file. The Editor also automatically turns on “debug mode” where you can see a bit of what’s happening under the hood as the story is being processed. The Player can only load and play .json stories.

Processes

The initial deployment plan is to host both web apps, and allow people to share .json files as they wished (created in the editor webapp). A person would receive someone else’s .json and upload it to the Player webapp to play the story.

Soon, an officially supported deployment will be to allow editors to download the source for the app, and run their own editor apps on their local machines or even self-host, and do the same for their player apps. In this case the Player can be set to load a specific .json file instead of asking for a specific screen to load.

Current State

Currently, both apps are deployed via Github to Netlify (Editor and Player). Each build is also run through TravisCI to run tests, and on tagged releases, will generate a player.zip that contains all the files needed to host a Player app which will be attached to the Github release.

Links

Source: https://github.com/washingtonsteven/react-vn

Editor: http://react-vn.netlify.com

Player: http://react-vn-player.netlify.com

Screenshots

Caching Component data in React

Steven Washington — Sun, 04 Mar 2018 16:47:26 +0000

The Problem

So I recently came across an issue in a React App that I'm building (for funsies):

I have an array of objects, that potentially can get huge. Each one of those objects has an id, so implementing Array.find to get the item I want should work.


const nodes = [
  { id:"abc", content:"Lorem ipsum"},
  { id:"def", content:"Dolor sit" },
  // ...
]

const getNode = id => nodes.find(n => n.id === id);

console.log(getNode('abc'));
// => { id:"abc", content:"Lorem ipsum" }

However, when nodes gets big, Array.find is going to be iterating over each item, which can get expensive. So we can implement a 'cache' of sorts to help out.

const nodes = [
  { id:"abc", content:"Lorem ipsum"},
  { id:"def", content:"Dolor sit" },
  // ...
];

const keyedNodes = {}

const getNode = id => {
  if (!keyedNodes[id]) {
    keyedNodes[id] = nodes.find(n => n.id === id);
  }

  return keyedNodes[id];
}

console.log(getNode('abc'));
// => { id:"abc", content:"Lorem ipsum" }

console.log(getNode('abc'));
// This time we are coming from keyedNodes!
// => { id:"abc", content:"Lorem ipsum" }

Seems simple enough!

React and data

Being a relative React newbie, I had it drilled into my head where the sources of data in an app should be: either prop or state. props holds data that the component receives (and it shouldn't update itself), and state holds the current state of the component, which that same component has complete control over (via setState of course!).

Armed with this info, I went to implement this memoization tactic using the component's state, and it got super messy given setState's asynchronous nature.

Check out the demo on CodeSandbox

Look at that nasty getNode function! We have to wait for the state to resolve before actually changing the node, or else we risk overwriting the state at the wrong time. (the state in changeNodes, which doesn't have the keyedNodes update in getNode, would overwrite the keyedNodes object to be blank! No help at all!).

I lived with this for a while, then I looked over at Kent Dodd's video on using class fields (which is useful for getting around those pesky bind calls). This reminded me that class fields exist (sort of..., the default babel config for Create React App does allow for their use). So not only could I put state in as a class field (along with arrow functions to create properly bound functions for component callbacks), but anything else can go here too!

Note: You don't actually need to use class fields for this, either! this.keyedNodes in constructor will do the same thing.

So, putting keyedNodes on a classVariable renders something similar, but much easier to read:

Check out the demo on CodeSandbox

Downsides?

The main downside to this is that React doesn't look at class fields other than state and props to control the rendering of updates. So if for whatever reason you need this cache to be tied to the render loop, you are stuck with the first way: keeping the cache in state.

I believe that in most cases, however, the cache doesn't need to trigger or get updated by React itself. The cache should follow any updates to the component, not preempt them.

To that end, perhaps we can an addition in componentDidUpdate to clear the cache if this.state.nodes just went through an update, so we aren't potentially dealing with old data. But this goes to show that data in class fields needs to be treated with care.

One other side effect is that these class fields are bound to the instance and not the prototype. Meaning that another component on the page that is using the same set of data has to build its own cache, and can't borrow it. This can be fixed by putting the cache in state, lifting the cache to a parent component, or using a render prop (or HOC) with a Cache component (or withCache HOC).

Conclusion - Use with caution!

Holding on to component-specific (and even instance-specific) data within a class or object field can be very useful for some quick optimizations, or just holding some data that doesn't necessarily need to be ensnared in the React render loop, where the async nature of setState can cause strange problems and race conditions that can lead to less-than-readable code. However, because the class field is outside of the render loop, updates to that data won't be managed by React, and can cause problems along the way if used improperly. A simple cache for storing data that needs to be readily accessible is a great use for this, as a cache naturally falls back onto the React state for a miss, and should 'follow the leader' in taking the source of truth from state.

Yelling at Silicon (Part 1)

Steven Washington — Tue, 13 Feb 2018 15:07:57 +0000

The use of various voice-activated home assistants in everyday life has been booming lately. It started off with Siri, and Google followed with their Assistant. Alexa came on the scene and even Cortana has given it a go.

These assistants come with a good set of features and functions that help you automate your life: setting timers, playing music, turning on and off lights, setting thermostats, etc. It's all very helpful! However, regardless of how many functions exist, there's never going to be a one-size-fits-all solution.

So it's time to make one.

Play along by following what I have so far in Github

A bus tracking app

My typical morning involves the usual things: waking up, checking Twitter while laying in bed for 20 minutes, rushing through breakfast/shower/dressing myself to get out the door on time. A part of this involves halting the whole process as I fiddle with my phone to bring up predictions from a bus tracking app (Nextbus in this case). It would be so much easier if I could instead ask my phone (or Google Home) for the latest buses by my house as I'm toasting a bagel or tying my shoes.

To start, I built a quick function that interfaces with Nextbus' API. It accepts a stop name, and returns an object that has the prediction data that I need:

// Nextbus needs a stopId to look up predictions
// We have an object that maps stopNames to stopIds
const stops = {
  'harvard':'55555'
  // other stops here...
}

exports.getPredictions = stopName => {
  const stopId = stops[stopName];

  const nextbusURL = `http://webservices.nextbus.com/service/publicXMLFeed?command=predictions&a=mbta&stopId=${stopId}`;

  // The Nextbus API is an XML api, so we use the xml2js package
  // to convert that to JSON
  // Then we have a parseSchedule function to clean up that
  // JSON, only returning the results we want
  return request(nextbusURL)
    .then(xml => xml2js(xml))
    .then(json => parseSchedule(json))
}

const parseSchedule = json => {
  const cleanedUp = [];

  // Take `json` and extract only the info we care about
  // In the end, cleanedUp will be a multidimensional array of sentences, like:
  // [
  //   ['The next 77 to Arlington Heights at Harvard is arriving in 5 minutes'],
  //   ['The next 96 to Medford Square at Harvard is arriving in 8 minutes']
  // ]

  return cleanedUp;
}

If you're following in the Github repo, you'll notice that I'm only getting the first prediction for each route/direction combo. Shuffling around this function a bit and we can get multiple sets of predictions per route, which we can append to the inner array

Making sentences - `filter` and `join`

Before we can send this data to any voice assistant, we need to make actual, speakable sentences.

The cleanedUp object from parseSchedule is a multi-dimensional array. The first dimension is a set of routes (bus numbers) and the second is the set of predictions for that route. Since these are in an array, we can use some of the new ES6 functions to parse this out into a set of sentences for each route.

Note: That routes with no predictions will show up as empty arrays, so we have to filter to get them out. Predictions with no value will show up as empty strings, and we can filter those out as well (even using the same length check for both!)

In the actual repo, I have this set up as a one-liner, but it's expanded/annotated below:

exports.stringifyPredictions = (results, joiner = ". ") => {
  let resultsMessage = results.map(predictionList => {

    // predicitonList is a set of predictions for a route
    // Filter out the empty ones (empty strings), then join them together
    return predictionList.filter(l => l.length > 0).join(joiner)
  })

  // Filter and join again on the set of routes
  // Filtering out empty routes (which show up here as empty arrays)
  resultsMessage = resultsMessage.filter(l => l.length > 0).join(joiner);

  return resultsMessage;
}

Make it web-accessible

In order to work, Google Assistant must be able to access our service over the web, where we will return what we want it to say as a JSON response. I use Express to set up a server to listen to queries from Google, and host on Heroku.

const app = express();
app.post('/thorndike', (req, res) => {

  // See below for the contents of googleAction.js
  require('./googleAction')(req, res);
});

Conversing with Google Assistant - Actions on Google and DialogFlow

Now that we have functions for getting prediction sentences, we need to hook up Google Assistant to respond to our voice, and reach out to our service to get the set of predictions. For that we use the actions-on-google module from npm as well as Dialogflow.

Before getting into code, we need to set up our app on the Google Developer Console and Dialogflow. Dialogflow is the glue between Google Assistant and our app, it receives the parsed voice input from Google Assistant, and will call our app via webhook (they call it a "Fulfillment") in response. I used this bit of documentation to get all of this set up. It goes over some of the concepts of a Google Assistant "conversation" as well has walking through the Dialogflow web console.

Part of said setup is making an "Action" that the service can respond to. This can be any sort of string that identifies what's happening; we just need to remember is when we get to coding up our response. Another important part is the "argument," which is a piece of the spoken phrase that can be variable. We can extract that text and use that to inform which bus we are looking for. E.g. "Hey Google, What buses are near Harvard?" Both of these will get sent to our request handler, which is the next bit of code we will be working on!

Responding to requests with `actions-on-google`

The actions-on-google module works by parsing the request received from Google Assistant/Dialog flow, and calling a function based on what action was sent. This is done by setting up a Map that connects action strings to functions. From there we just have to call getPredictions/stringifyPredictions to get our prediction sentences, and then pass that into a tell function that actions-on-google gives us!

// googleAction.js

const App = require('actions-on-google').DialogflowApp;
const { getPredictions, stringifyPredictions } = require('./getPredictions');

// This is the action we set up in DialogFlow
const ASK_ACTION = 'ask_stop_by_name';

// We set up a parameter called stop_name, that is filled in
// when the voice input is parsed.
const STOP_NAME_ARGUMENT = 'stop_name';

module.exports = (request, response) => {
  const app = new App({request, response});

  let actionMap = new Map();
  actionMap.set(ASK_ACTION, app => {

    // getArgument() is a function from 
    // `actions-on-google` / `DialogflowApp` that can parse
    // out the argument from the voice input.
    let stopName = app.getArgument(STOP_NAME_ARGUMENT);

    getPredictions(stopName)
      .then(results => stringifyPredictions(results))
      .then(resultsMessage => {

        // stringifyPredictions returns 'false' if a stop exists, but has no buses.
        if (resultsMessage === false) {

          // app.tell literally makes Google Assistant speak!
          app.tell(`There don't seem to be any buses at ${stopName}`);
        }

        // any other falsy value means that the app doesn't know about that stop
        else if (!resultsMessage) {
          app.tell(`Sorry, I don't have information for ${stopName}`);
        }

        // We got some predictions!
        else {
          app.tell(resultsMessage);
        }
      });
  });

  // The App, built based on the request/response we received,
  // will take in our map, figure out the action based
  // on what Dialogflow sent us, and then call the
  // relevant function.
  app.handleRequest(actionMap);
}

Talking with Google Assistant

Now that we have our web app set up (and hosted, and the webhook is put into Dialogflow), we can start talking to our new Google Assistant app! There are just a few things to set up that will make talking to Google just a bit nicer.

Rename your app

When setting up Dialogflow, it created an app in the Actions on Google Console. We can log in here and update the App information, like the app name and pronunciation, so we can talk to our service by name. I called mine "Thorndike Next Bus" (more on naming in a bit).

This screen is meant for putting in your app metadata for publishing on the Google Actions Marketplace for everyone to use. However I currently don't have plans for a general public release of this; I just want to use it on my account. But since we are effectively preparing a public app (just not releasing it), we have a few limitations.

There are a number of required fields that don't apply, mostly related to marketing imagery and copy. You can leave these blank, and your info will save, however you'll get warnings everytime you return to make an update
Since this is meant for a public release, the name of your app has to be unique (and also not related to an established brand, as Google will prompt you to prove that you are working on behalf of that brand, which you probably aren't). This means that your app's name might have to be an awkward phrase instead of a single word.
Since we aren't "releasing" our Google Assistant app, she will constantly tell us that we are using the "test version" of our app. Oh well.

Testing in the browser

Once you edit your app information, you can test out the responses in your browser by clicking "Test Draft". You'll get a screen that looks like the Google Assisant Android screen on the left, and various data about your tests on the right. Here, you can type in your expected voice input and see how Google Assistant responds.

Success!

Testing with your voice

Now that everything is deployed, you can actually talk with Google Assistant (as long as you are logged in to the same Google account as you made the app on) and follow a similar conversation as you saw above. Just say "Hey Google, Talk to " and you're ready to go.

Feels clunky? Yeah, it kind of is.

The was Actions on Google works is through a concept of "conversations." Which is great for talking to an AI. However the fact that you have to retrieve a second "assistant" to get the information (instead of the info coming from Google Assistant herself) feels like a hiccup in the process. In the end, it adds an extra call/response to a procedure that could be shortened "Hey Google, get predictions for X bus." Going the "conversation" route is a bit longer, but it has the benefit of being completely hands-free.

The Future

This way of augmenting Google Assistant is fantastic for setting up conversations with AI to interact with data sources that don't come "standard" with it. Just takes a bit of work to mold the data into a sentence, and then serve a response when Google comes knocking on your server with some voice input. However, sometimes these conversations can be clunky just to get a bit of data. If only there were an alternative way to get the data, with a single sentence or even the press of a button…

Oh wait there is! In a followup article, I'll be hooking up the same bus tracking app to IFTTT's Google Assistant integration, which will allow us to access our data in a number of different alternative ways to Google's conversations.

What do you look for in a good developer article/tutorial?

Steven Washington — Thu, 08 Feb 2018 22:45:00 +0000

I've been sitting on an article (a Google Assistant tutorial) for a while, trying to groom it to be great! However I've been kind of stuck in a paralysis afraid of it not being perfect.

I know at some point I will have to just hit publish and go for it, but I figured I'd ask the community...What are some good things to have in an article/tutorial that make the whole thing a joy to read and learn from?

Snippet: All-CSS (scss) Arrow Circles for Your Pagination Needs

Steven Washington — Mon, 11 Sep 2017 00:53:18 +0000

So I just did this for my site and thought it was a fun and simple snippet to share. Nothing too fancy, but using only CSS for something presentational just makes me giddy!

So here’s the markup:

<span class="page-link prev"><a href="/prev"></a></span>
<span class="page-link next"><a href="/next"></a></span>

Easy! Only slightly weird thing is that there is no text in the a tags. We would probably want to add a title attribute to the tag to make sure everyone knows what we are talking about.

And the magic! In Sass (scss) because we’re being all modern: (explanation in comments)

$circle_diameter: 50px;
$dark_gray: rgba(74, 77, 81, 1);
$yellow: rgba(255, 199, 0, 1);
.page-link {
  a { 
    // We will make this empty a tag a circle
    // Set equal width and height.
    width: $circle_diameter; 
    height: $circle_diameter;

    // This curves in the corners to make a circle.
    border-radius:50%; 

    // Make it look nice.
    background-color:$yellow;

    // We're going to be doing some funky positioning stuff!
    position:relative;

    // Yes! We are using both :before and :after pseudoclasses! Each will be a "leg" of the arrow
    &:before, &:after { 
      // Gotta have this to make the pseudoclasses work.
      content:"";
      // You can mess with these values to change how thick and long the arrow legs are.
      // But you will have to mess with positioning below, as well.
      width:30%;
      height:12%;
      // Something to contrast the $yellow.
      background-color:$dark_gray; 
      // Here it comes...
      position:absolute; 
      // Oh, just center it. 
      // transform will take care of fine tuning the positioning.
      top:50%; 
      left:50%;
    }
  }

  // Here's all the crazy positioning stuff, handled by the "transform" directive.
  // :before becomes the top of the arrow, and :after is the bottom (see the second param of translate()).
  // Note how the values flip between .prev and .next (and the first param in translate value flipping over -50%)!
  // You can tweak these values to make different angles of arrows! 
  // But if you do you will probably have to change the size of the legs above.
  &.prev {
    a:before{
      transform:translate(-60%, -100%) rotate(-45deg);
    }
    a:after {
      transform:translate(-60%, 0) rotate(45deg);
    }
  }

  // Second verse, same as the first!
  &.next {
    a:before{
      transform:translate(-40%, -100%) rotate(45deg);
    }
    a:after {
      transform:translate(-40%, 0) rotate(-45deg);
    }
  }
}

The :before and :after pseudoclasses are a lifesaver here.

And here’s what it all looks like in the end:

Well, at least I think it’s pretty neat.

This post was originally published on washingtonsteven.net

Playing with Canvas and ES6 Classes

Steven Washington — Sat, 09 Sep 2017 15:32:02 +0000

This is also available on my new blog http://washingtonsteven.net/playing-with-canvas-and-es6-classes/

A Train Ride

This past Labor Day weekend I took some time to take the train down to New York City with my wife to see the sights, eat some good food, and generally get incredibly overwhelmed by the sheer denseness of the city. It's a great city and I know many people love it, but it's more and more becoming not my style. However on the way back I was actually awake enough to run through a quick tutorialÂ on how to use the HTML5 Canvas API to draw to the screen, take in inputs and output a simple, single-screen platformer game. Nothing to write home about, but it was nice to get away from the libraries like Pixi and CreateJS and just get your hands dirty directly.

A New Challenge

The tutorial (linked above) turned out to be from 2013. Flipping through it, the javascript necessary to power the simple app was fairly straightforward, and the tutorial was less a lesson in Javascript and more a lesson in simple game programming: concepts of player variables, modeling the loop in memory then drawing it, and collisions (box-based, but still) were all covered. As someone with some experience building similar systems in Unity, this wasn't anything particularly new. But that Unity knowledge would drive me to update the code in this tutorial for something that is very useful in Unity's use of C#, and just about every other language except Javascript, until recently that is.

ES6 Classes

The tutorial keeps all of the game state in the global windowÂ object. Various other objects (like a playerÂ object, or boxesÂ array) are top level, while items like handling input are added directly as needed. As a person that's constantly interested in keeping a clean and semantic codebase, I took the 3.5 hour ride (we were lucky enough to get Acela tickets) to try to refactor what the original author had done.

Code

Follow along with the code on Github. I don't repeat every line here, so go check the full thing out! (Link goes to the specific commit that this post is referencing, since I will be updating it in the future).

Main class

I started off with a main class, that really just kicked everything off. I've had a habit of doing something like:

    $(document).ready(function() {
      main.init();
    });
    var main = {
      init:function() {
        // actually do stuff here
      }
    };

It kept things out of the global scope, at least. But not nearly ES6-y enough. Also...still relying on jQuery? That's so 2010. Now we can shed that pile of bloat¹ and in a fairly easy-to-read way setup our main starter class: the public static void main(String [] args) of Javascript.

    class CVS { //CVS is short for canvas, not a convenience store/pharmacy
      constructor() {
        // actually do stuff here
      }  
    }

    (function() {
      let cvs = new CVS();
    })();

Browserify

Javascript isn't great about sharing resources between files. At least in the browser, you either need to concatenate all your work into a single file (which you should do for production, but is a pain in dev), or add a bunch of <script> tags (for those who really don't care about HTTP requests). Fortunately, you can work in separate files and a huge number of packages (gulp, browserify, and webpack, to name a few) will do all the concatenating work for you. What's even better is that with some you can even declare which files you want to use in Javascript itself, with the use of modules. All you need is a require and boom, you have resources from another file.

Player class

For example, the Player should have its own class where it can keep track of it's own variables (position, velocity, and size, among others). For sanity's sake, we will separate that out into a separate file to keep the code base organized (and prevent collisions in scm). Luckily ES6 gives us a default (fingerguns) way to expose a class

player.js

    class Player {
      constructor() {
        this.x = 0; this.y = 0; //etc., etc.
      }

      move(horizontal, vertical) {
        // given the horizontal and vertical input directions, move the player in this frame by updating this.x and this.y
      }

      draw(ctx) {
        // Given a canvas 2d context, draw the player at the current position (this.x, this.y). 
        // For simplicity's sake, this player is a square and we can use the canvas rect() function
      }
    }

    export default Player;

That last line is the magic². We now can export the class (which is actually a function, since class is just syntactic sugar for JS prototypical "class" definition, and not truly a "new" spec.

Collisions! (util.js)

It's hard to have a game without checking for collisions! The end of util.js (which isn't really a class, just an object with a collection of functions) has some basic math for checking for collisions between two objects. I won't go into the math of it (the tutorial linked above does a good job of that). But it can detect if two objects have collided as long as both can describe a rectangle, that is, they have an x and y position, and width and height.

Other classes

input.js

Having an input class (which basically is a Singleton, like Player above), is useful to send input events to the appropriate place. The Player doesn't need to know anything about what keys were pressed, just what direction we need to go! So we abstract that away from them. This even allows the flexibility to swap out what kind of inputs we are using: keyboard, mouse, Wiimote, and even mind control³ are all possible!

    class Input {
      constructor(docBody) { //pass in a reference to document.body
        this.keys = [];
        docBody.addEventListener('keydown', (e) => { this.keys[e.keyCode] = true });
        docBody.addEventListener('keyup', (e) => { this.keys[e.keyCode] = false });
      }
    }

This is the meat of Input. An array keeps track of which keys are pressed. And anyone with access to an Input instance can just check Input.keys and see what keys are pressed at any given moment. Any other functions on this class (for now) are just fluff to make checking easier.

As I'm writing this, I realize that an update for this is to make Input a true singleton. Right now you can have multiple versions of this class which can be a mess. For the most part, I think you'd only need one.

platform.js and level.js (and coin.js!)

Platform is basically a glorified rectangle with a draw function. Pass it a canvas context and it'll draw a rect onto it with it's own internal state (x, y, width, and height). Coins are the same, except they are circles, and have a collected state that will gray them out the next time they are drawn.

Level is a collection of platforms. If you tell a level to draw itself, it just passes on the command to it's array of platforms (and coins).

(The rest of) util.js

The rest of util has some nice helper functions to get us through the hard times (and keeping things DRY)

normalize(num): Sometimes, we don't care about the value of a variable, just whether it is less than zero, zero or greater than zero. Here's a quickie to do that. (Don't tell me, there's a Math function that already does this in Javascript)
clamp(num, min, max): Instead of having boundary checks everywhere, here we can just pass a number in, and either get that number back, or min if it's less than min or max if it's less than max. In addition there's some simple checks so that min and max can be passed in any order, and if you only pass a single boundary, it will assume that that is max and min is negative max.
not(o): Just a simple way to check for existence without having to weed out 'falsy' values each time.
objectHasAllProps(o, props) (and objectsHaveAllProps): Just used for collide, it's something of a type checker in a language where types don't exist Â¯\_(ãƒ„)_/Â¯. Added a plural version because.

Round 2, start!

So that's the first pass at it (at least a brief overview, anyway). It was a lot of fun to go through and make this work with this new tool I'm learning about! The next step is implementing more complex levels, possibly getting out of the drawing API and working with actual images, and throwing it all away and just using a canvas library like Pixi.js because I ain't got time to write my own.

Once again, follow the code (at the time of this post) on Github

1. jQuery has it's uses, of course. But I always try to see how long I can go before having to use it.

2. Tools like Babel have made exporting/importing variables weird, since Babel < 6.0 suppressed errors for some technically invalid code. Read more here.

3. Mind Control API coming ~2020?

Is Apple really needed?

Steven Washington — Mon, 28 Aug 2017 14:45:02 +0000

So it seems that Apple has a large share of use in the web development community, particularly because of it's Unix-like-ness and it's ease of use for the common user. It would seem that would make it a great choice for IT to roll across the company; devs get a Unix-like machine and everyone else gets a simple machine to use.

But for hobby developers, is there anything locking you to Apple? Any utility or tool that is a must-have that is only available on Mac and not Linux? Or would it be just fine to get a cheap machine with Linux and call it a day?

Apologies for any platforms wars this erupts...

Hi, I'm Steven Washington

Steven Washington — Wed, 21 Jun 2017 07:45:44 +0000

I have been coding for 15 years.

You can find me on GitHub as washingtonsteven

I live in Boston.

I work for Connelly Partners

I mostly program in these languages: JS/PHP/C#.

I am currently learning more about MEAN stack and Unity for 2D game development.

Nice to meet you.

Forem: Steven Washington

Understanding Permissions

Unix permissions basics

Viewing Permissions

Okay but what about the numbers?

Conclusion

DemandPad

Basic Info

Goal

Saving/Loading mechanism

Deleting Notes

Process

Underlying Tech

Screenshots

My Development Graveyard, Part 1

aterriblefate

washingtonsteven.github.io

react-json-component

genmo

React's new Context API and Actions

Why Context?

B-but Redux!

What's Context do?

Simple Context Example

context.js

DuckDeterminer.js

Passing Functions

context.js

DuckDeterminer.js

Extra credit

Conclusion

Try it out

ReactVN

Technology

React

create-react-app

React 16.3 Context API

Deployment

Concept

Processes

Current State

Links

Screenshots

Caching Component data in React

The Problem

React and data

Check out the demo on CodeSandbox

Check out the demo on CodeSandbox

Downsides?

Conclusion - Use with caution!

Yelling at Silicon (Part 1)

A bus tracking app

Making sentences - filter and join

Make it web-accessible

Conversing with Google Assistant - Actions on Google and DialogFlow

Responding to requests with actions-on-google

Talking with Google Assistant

Rename your app

Testing in the browser

Testing with your voice

Feels clunky? Yeah, it kind of is.

The Future

What do you look for in a good developer article/tutorial?

Snippet: All-CSS (scss) Arrow Circles for Your Pagination Needs

Playing with Canvas and ES6 Classes

A Train Ride

A New Challenge

ES6 Classes

Code

Main class

Browserify

Player class

player.js

Collisions! (util.js)

Other classes

input.js

platform.js and level.js (and coin.js!)

(The rest of) util.js

Round 2, start!

Is Apple really needed?

`context.js`

`DuckDeterminer.js`

`context.js`

`DuckDeterminer.js`

Making sentences - `filter` and `join`

Responding to requests with `actions-on-google`