joeytwiddle

Do not use forEach with async-await

TLDR: Use for...of instead of forEach() in asynchronous code.

For legacy browsers, use for...i or [].reduce()

To execute the promises in parallel, use Promise.all([].map(...))

The problem

joeytwiddle

Be Overly Liberal with Thresholds, not Slightly Conservative

A mistake I often see in software development is the way people choose thresholds. The developer is told they need to limit certain types of activity, for logical reasons, but they set the limits too strictly.

I recommend:

When setting a threshold, be generous to the user, and then double that. If a high threshold will still satisfy your requirements, then choose

joeytwiddle

#!/usr/bin/env bash
set -e

# See also: https://github.com/frost-nzcr4/find_forks (same thing but in python)

origin_url="$(git remote show origin | grep 'Fetch URL:' | sed 's+.*: ++')"

full_repo_name="$(echo "$origin_url" | sed 's+.*github.com/++ ; s+\.git$++')"

forks_url="https://api.github.com/repos/${full_repo_name}/forks"

joeytwiddle

#!/usr/bin/env bash
set -e

# This script will start three shards, a config server and a mongos, all on the current machine.
#
# It was written for Mongo 3.4, based on https://docs.mongodb.com/manual/tutorial/deploy-shard-cluster/
#
# This script is only for testing purposes.  In production, you would run each of these servers on a different machine.
#
# If you do run this, please ensure that your machine has a few gigs of swap space.  mongod indexes will happily

joeytwiddle

Preamble

I have used WebStorm at work for the past three years. But last month I used VSCode exclusively for four weeks, because I wanted to learn it. I noted my observations here.

Eventually, as a deadline approached, I switched back to WebStorm. Why? VSCode is very good, and I was impressed. But I still find WebStorm is slightly better at a few things which I use very frequently. These small improvements really add up when I'm trying to get stuff done.

In keeping with the Pareto principle, small advantages with only a few commonly used features are enough to make one editor stand out for me. Specifically, "Go to Definition/References", "Searching" and "Carrying imports" are so important, that just making these more convenient means that all other concerns are irrelevant.

So, for the reader's convenience, these are the first few features I will address below.

joeytwiddle

/*
 * TLDR: I want to use await in a function, but I don't want my function to return a Promise.
 *
 * Solution: Use this inside the body of your function: Promise.resolve(async () => { ... }).catch(...);
 *
 * Original post follows.  (I say original, but it has slowly grown longer and longer...!)
 *
 * ------------------
 *
 * I have been using async-await and loving it.  But there is one thing I'm not sure how to handle.

joeytwiddle

async function getFoo (bar) {
  const baz = 2 * bar;
  
  const root = await asyncSqrt(baz);
  
  return 2 * root;
}

// Is the same as

joeytwiddle

Asking Good Questions

Suggestions to help you ask good questions on StackOverflow, GitHub issues and IRC, as well as when asking colleagues face-to-face.

General rule: Put at least as much effort into the question as you would like others to put into the answer.

Preparation

1. Check that you have the latest version of the software. (The bug might have already been fixed.)

joeytwiddle

#!/usr/bin/env bash

set -e

cache_dir="$HOME/Library/Group Containers/K36BKF7T3D.group.com.apple.configurator/Library/Caches/Assets/TemporaryItems/MobileApps"

if command -v find >/dev/null && command -v mktemp >/dev/null && command -v unzip >/dev/null && command -v grep >/dev/null
then :
else
  echo "This script requires the follow executables to run: find mktemp unzip grep"

joeytwiddle

I recommend using throw over return Promise.reject() when possible, because:

1. If you are inside "promise-land" then your throw will be automatically converted into a rejected promise.
2. But it is shorter, which makes it easier to read.
3. And it retains some parity between synchronous and asynchronous code. (It will continue to work as expected if those lines were extracted into a synchronous function.)
4. Also, throw can be used to break out of a stack of deeply nested synchronous function calls. (Returning a rejection will only pass it up one level. Of course, we shouldn't be returning rejections from sycnhronous functions anyway.)

Although throwing an error is not safe inside callback functions (which are often called from the engine, without a surrounding try-catch wrapper), it is entirely safe to throw from inside an async function (or from within a .then() handler function), because in those cases the throw will be automatically converted into a rejected promise.

Situations where