Authoring

Edit Posts

_Existential Quantification in TypeScript

While working on a TypeScript project, I encountered a scenario that seemed impossible to describe with the language. I needed a function that could take a list of action/handler tuples, `[Promise<A>, (a: A) => void][]`, and apply each handler to the the `await`ed result of the action. Something like this:

```typescript
async function applyMany<A>(ahts: [Promise<A>, (a: A) => void][]): Promise<void>
```

The problem is that `A` constrains every tuple in the list. `applyMany` should *only* care about the compatibility of the action and the handler within each tuple.

The solution is [Existential Quantification](https://wiki.haskell.org/Existential_type). It can be used to "hide" types that are *not* meaningful externally. Unfortunately, TypeScript does not explicitly support existential quantification.[^no-support] It is possible however, to "wrap" over the extra type with clever use of closure and type inference.[^clever] Examples of this cleverness were initially difficult for me to decipher, in part, due to my shaky understanding of existential quantification.

[^no-support]: [Existential Type?](https://github.com/Microsoft/TypeScript/issues/14466)

[^clever]: [Closure Workaround](https://github.com/Microsoft/TypeScript/issues/14466#issuecomment-338045331)

While researching the topic, I came across a [section](https://downloads.haskell.org/ghc/latest/docs/html/users_guide/glasgow_exts.html#existentially-quantified-data-constructors) in the GHC user guide that briefly discusses existential quantification in the context of Haskell. Coincidentally, the example it presents is isomorphic to my problem. I decided to implement the example in TypeScript as an exercise. Before working through this example, let's cover some fundamentals.

## Generic Functions in TypeScript

```typescript
function id<A>(a: A): A {
  return a
}
```

The identity function accepts a value of *any* type `A` and returns it unmodified.

```typescript
id<number>(1) // 1
id<string>('foo') // 'foo'
id<boolean>(true) // true
```

We know intuitively that manually supplying the types is redundant. The compiler is able to infer `A` from the argument `a`:

```typescript
id(1) // 1
id('foo') // 'foo'
id(true) // true
```

`id` can also be implemented as an anonymous function:

```typescript
const id = <A>(a: A): A => a
```

Put another way:

```typescript
const id: <A>(a: A) => A = (a) => a
```

More clearly:

```typescript
type F = <A>(a: A) => A

const id: F = (a) => a
```

Typically when we see a generic type alias, the type variables are on the left side of the `=` like so:

```typescript
type F<A> = (a: A) => A
```

Now, we're in a situation where `A` must always be supplied. It is no longer possible for the compiler to infer the type from the argument. As a result, `id` must be implemented for every type:

```typescript
const idNumber: F<number> = (a) => a
const idString: F<string> = (a) => a
const idBoolean: F<boolean> = (a) => a
// ...
```

This mirrors the original problem:

```typescript
type AHT<A> = [Promise<A>, (a: A) => void]

const ahtNumber: AHT<number> = [Promise.resolve(0), (a) => console.log(a + 1)]
const ahtString: AHT<string> = [Promise.resolve('foo'), (a) => console.log(a.length)]
const ahtBool: AHT<boolean> = [Promise.resolve(true), (a) => console.log(!a)]
// ...
```

`<A>` must move to the right of the `=` so that an `AHT` is constructible *for all* types `A`. From what we've seen, functions provide a way to perform this transformation.

## A Simple Existential Type

Let's come back to the Haskell example.

```haskell
data Foo = forall a. MkFoo a (a -> Bool)
         | Nil
```

`Foo` has two data constructors: `MkFoo`, and `Nil`.

```haskell
MkFoo :: forall a. a -> (a -> Bool) -> Foo
Nil   :: Foo
```

`MkFoo` is clearly the function of interest. `forall a.` "existentializes" the type variable `a` removing it from the left side of the `=`‌. The use of `forall` to **exist**entially quantify a type variable is the source of much confusion. To avoid introducing an additional keyword `exists`, the implementers leveraged a recontextualisation of De Morgan's laws within type theory that describes an isomorphism between `exists` and `forall`.[^forall] Barring all that ivory tower stuff, I just think of it like this:

> `MkFoo` constructs a `Foo` `forall` types `a`.

Notice that this is a restatement of what was said about the `AHT` type in the previous section.

[^forall]: [What's the theoretical basis for existential types?](https://stackoverflow.com/questions/10753073/whats-the-theoretical-basis-for-existential-types)

With the `a` extistentialized, a [heterogeneous list](https://wiki.haskell.org/Heterogenous_collections) of `Foo`s can be created.

```haskell
[MkFoo 3 even, MkFoo 'c' isUpper, Nil] :: [Foo]
```

In the first `Foo`, `A` is `Int`. In the second, `A` is `Char`. How can this be achieved in TypeScript? Let's start by defining `Foo`.

```typescript
type Foo = MkFoo | null
```

We don't need to define `Nil` because TypeScript (unfortunately) already has a `null` type. Next we need to define `MkFoo`. Starting from the bottom...

```typescript
type MkFoo_<A> = [A, (a: A) => boolean]
```

`MkFoo_` establishes the relationship between the value and the handler. Next, we need to move the `<A>` to the other side of the `=` by wrapping `MkFoo` in a function.

```typescript
type MkFoo = <R>(run: <A>(_: MkFoo_<A>) => R) => R
```

Well, there's actually two functions. Let's analyze this layer by layer.

```typescript
<A>(_: MkFoo_<A>) => R
```

The inner function infers `A` from the `MkFoo_` argument. As it is a function, it must return something. An additional type variable `R` is used to avoid constraining what can be returned. With only this layer, `R` would appear on the left of the `=` so an additionally layer is necessary.

```typescript
<R>(run: <A>(_: MkFoo_<A>) => R) => R
```

This function is able to infer `R` from the inner layer `run`. You may recognize the "shape" `((_ -> r) -> r)` which is common in [continuation passing style](https://en.wikipedia.org/wiki/Continuation-passing_style) programming. This [blog post](https://rubenpieters.github.io/programming/typescript/2018/07/13/existential-types-typescript.html) explains existential quantification in TypeScript through the lens of CPS.

Now we need a constructor for `MkFoo`:

```typescript
const mkFoo = <A>(mkFoo_: MkFoo_<A>): MkFoo => (run) => run(mkFoo_)
```

This wraps a `MkFoo_` in the layers just described. By accepting a `run` function, a `MkFoo` provides the ability for an external entity to "reach in" and safely interact with the hidden `MkFoo_`. It's a bit like the [*What's in the Box?* challenge](https://youtu.be/Sci99roo2iI).

Finally, we can create the list of `Foo`s:

```typescript
const foos = [
  mkFoo([3, (a) => a % 2 === 0]),
  mkFoo(['c', (a) => a === a.toUpperCase()]),
  null
]
```

Notice that we don't have to explicitly fill in any type variables. In the first `Foo`, `A` is inferred to be `number`. In the second, `A` is inferred to be `string`. `A` is now "closed over" but `R` still needs filling.

```typescript
const f = (foo: Foo): boolean => {
  if (foo === null) return false
  return foo(([v, h]) => h(v))
}

foos.map(f) // [false, false, false]
```

Because the return type of `f` is `boolean`, `R` is filled in with `boolean`. The `run` function `([v, h]) => h(v)`, specified to return `R`, must also return `boolean`. `h(v)` returns `boolean` so the constraint is satisfied. The relationship between `v` and `h` is already encoded within `foo` so they're left unspecified.

We've shown that existential quantification *is* possible in TypeScript. You can play around with this example [here](https://www.typescriptlang.org/play/#code/C4TwDgpgBAsg1gMQPZIPoB4CCA+KBeKAbUwBooAKAQwC4pMBKfXAIxQBsJKA7AXQCg+oSLEQp8UdACVs5AE4BXLrSwzUteMjQrGeXJJ16BAYyRcAzsCgBbUUnEryNzWpHPt620woKuBqD8dbVHoBIWhNcQ0xAB8oLnk2NmNTCygAMxQzcUI+KGtbckIAZjIqP0ooAFIoACZ8PAIABh56Elz8zUKAciMu0spy+oJKADpgJABVMEhZAGFKMwhyeha2vPjEvn4+E3NLNPFyDKRaTXpaViQObi8Ab3aASwOjsQaCDbZGWQhgeVkudKUNiLdrfX7-dIociFABuZAAFi0vPDyDD6CEAL4CY5mEZWShgI70IA).

After implementing `Foo`, I was able to easily transform it into a solution for my initial problem. A new problem arose. I was curious about all the things I could do with existential types. Fortunately, my enthusiasm was curbed after reading this [blog post](https://medium.com/@jonathangfischoff/existential-quantification-patterns-and-antipatterns-3b7b683b7d71) on the dangers of type level magic. The author outlines some good and bad uses of existential quantification. He pointed to the [`foldl`](https://hackage.haskell.org/package/foldl-1.4.6/docs/Control-Foldl.html) package as an example of how to properly employ the technique. It defines the `Fold` data type:

```haskell
data Fold a b = forall x. Fold (x -> a -> x) x (x -> b)
```

If you're unfamiliar with folds, for now just think of them as a more generic form of list reduction.

I decided to implement `Fold` as well as a tiny portion of the library in TypeScript to really solidify all that I'd learned. Let's walk through it together.

## Implementing Fold in TypeScript

`Fold_` is defined just like `MkFoo_`:

```typescript
type Fold_<X, A, B> = { step: (x: X, a: A) => X; initial: X; extract: (x: X) => B }
```

`X` is the type of the accumulator value. `A` is the type of the elements in the structure being folded. `B` is the type of the value resulting from the application of the fold. Many `Fold`s fill in all the variables with the same type. For example, the `sum` fold specifies them all to be `number`. But as we'll see, making these type variables distinct enables the creation of more powerful folds.

Next, we move `<X>` to the right of the `=`:

```typescript
type Fold<A, B> = <R>(run: <X>(_: Fold_<X, A, B>) => R) => R
```

This closely resembles the pattern used when implementing `Foo`. We're already familiar with the `sum` fold, so let's implement that now.

```typescript
const id = <B>(b: B): B => b

const sum: Fold<number, number> = (run) =>
  run({
    step: (x, a) => x + a,
    initial: 0,
    extract: id,
  })
```

This looks familiar. It's almost exactly the same as the `mkFold` constructor defined earlier. This makes sense because it *constructs* a `Fold`. As mentioned previously, all the types involved in this fold are `number`, hence `Fold<number, number>`. By setting `initial` to `0`, the compiler can infer that `X` is also a `number`. `extract` simply returns the accumulator value.

We're still missing one thing: the function that applies a `Fold` to a structure:

```typescript
const fold = <A, B>(f: Fold<A, B>, fa: Foldable<A>): B =>
  f(({ step, initial, extract }) => extract(fa.reduce(step, initial)))
```

Notice how similar this is to the `f` function defined in the `Foo` example. It takes a `Fold` `f` and applies it to a `Foldable` `fa`. Wait, what's a `Foldable`? You may be wondering why I keep using the word "structure" instead of just saying list. Well, what if we want to fold a linked list or a binary tree? Basically any structure that contains elements of a specific type can be folded. The structure just has to have a `reduce` method. Conveniently, the `[]` type already does. Let's define a `Foldable` interface and then create a new `Tree` structure that implements it.

```typescript
type Reduce<A> = <X>(step: (x: X, a: A) => X, init: X) => X

interface Foldable<A> {
  reduce: Reduce<A>
}
```

In the definition of `Reduce`, notice how `A` is on the left of the `=` and `X` is on the right. If `A` and `X` were on the left then we'd be saying that a `Foldable` must specify both `A` and `X`. If they were on the right, we'd be saying that both `A` and `X` can be inferred from `step` and `init`. What we want to say is that the structure implementing `Foldable` should fill in `A` with the type of its elements and that `X` is inferred from the arguments. Thus, `A` on the left, `X` on the right.

Next, let's define a `Tree`. A Haskell implementation might look something like this:[^tree]

```haskell
data Tree a = Empty | Leaf a | Node (Tree a) a (Tree a)
```

[^tree]: [Foldable](https://hackage.haskell.org/package/foldl-1.4.6/docs/Control-Foldl.html#t:Foldable)

This data type is recursive in that a `Node`, one of the `Tree`'s data constructor, takes a left `Tree` and a right `Tree`. TypeScript does not support recursive type aliases but it does have "recursive back references within interface types."[^recursive]

[^recursive]: [Recursive Back References Within Interface Types](https://github.com/microsoft/TypeScript/issues/3496#issuecomment-128553540)

This example was provided by the creator of TypeScript [himself](https://github.com/ahejlsberg).

Unfortunately we can't quite replicate the elegance of the Haskell definition in TypeScript because we need a `class` on which to define `reduce`.

```typescript
type Root<A> = Empty | Leaf<A> | Node<A>

class Tree<A> implements Foldable<A> {
  root: Root<A>

constructor(root: Root<A> = { tag: 'EMPTY' }) {
    this.root = root
  }

// reduce: ...
}

interface Empty {
  tag: 'EMPTY'
}

interface Leaf<A> {
  tag: 'LEAF'
  value: A
}

interface Node<A> {
  tag: 'NODE'
  left: Tree<A>
  value: A
  right: Tree<A>
}
```

A [tagged union type](https://mariusschulz.com/blog/tagged-union-types-in-typescript) is used to describe the `Root` of the `Tree`.

```typescript
  // ...
  reduce: Reduce<A> = (step, init) => {
    const root = this.root
    switch (root.tag) {
      case 'NODE':
        return root.right.reduce(step, step(root.left.reduce(step, init), root.value))
      case 'LEAF':
        return step(init, root.value)
      default:
        // EMPTY
        return init
    }
  }
  // ...
```

`reduce` performs a specific action for each of the different root types. The `NODE` case is clearly the interesting one. It essentially performs an in-order traversal.

Now that we have two different foldable structures, `Tree<A>` and `<A>[]`, let's test out the `sum` fold on them.

```typescript
const testArray = [1, 2, 2, 3]

const testTree = new Tree<number>({
  tag: 'NODE',
  left: new Tree({
    tag: 'NODE',
    left: new Tree({
      tag: 'LEAF',
      value: 1,
    }),
    value: 2,
    right: new Tree(),
  }),
  value: 2,
  right: new Tree({
    tag: 'LEAF',
    value: 3,
  }),
})

fold(sum, testArray) // 8
fold(sum, testTree) // 8
```

So we've proven that the implementation of `Fold` can work on various structures but we haven't tried folds that have different concrete types for `X`, `A`, and `B`.

```typescript
const all = <A>(p: (a: A) => boolean): Fold<A, boolean> => (run) =>
  run({
    step: (x, a) => x && p(a),
    initial: true,
    extract: id,
  })
```

`all` takes a predicate `p` and returns a `Fold<A, boolean>`. If *all* the applications of the predicate to each element in the structure result in `true`, the overall result is `true` otherwise `false`. The compiler can infer `X` from the value of `initial` and `A` from the predicate.

```typescript
const nub = <A>(): Fold<A, A[]> => (run) =>
  run({
    step: (x, a) => x.add(a),
    initial: new Set<A>(),
    extract: (x) => [...x],
  })
```

`nub` folds a structure into a list without duplicate elements.  `X` is inferred to be `Set<A>` from the `initial` value‌. Because sets prevent duplicates from being added and the TypeScript/JavaScript implementation of `Set` maintains insertion order[^order], `extract` can simply convert the accumulator to a list. Note that this fold is a function even though it doesn't take any arguments. This is because it has a type variable and values cannot have type variables.

[^order]: [Set](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Set)

Let's put these folds to use:

```typescript
fold(all((a) => a > 0), testArray) // true
fold(all((a) => a > 0), testTree) // true
fold(all((a) => a < 0), testArray) // false
fold(all((a) => a < 0), testTree) // false

fold(nub(), testArray) // [1, 2, 3]
fold(nub(), testTree) // [1, 2, 3]
```

All this code can be viewed in the [`fold-ts`](https://github.com/wilfreddenton/fold-ts) repo. Maybe you'll find some use for it. If you'd like to contribute additional folds please submit a PR!

If this type level trickery still confuses you, there are plenty of other examples.[^examples]

[^examples]: Examples

- [Encoding Existential Types in TypeScript](https://rubenpieters.github.io/programming/typescript/2018/07/13/existential-types-typescript.html)
  - [Typescript array of different generic types](https://stackoverflow.com/questions/51815782/typescript-array-of-different-generic-types)
  - [How do I type parameterize a tuple?](https://stackoverflow.com/questions/46185023/how-do-i-type-parameterize-a-tuple)

## Existential Crisis

It's unfortunate that a seemingly trivial problem leads to such a complex solution. So far, the only two "mainstream" languages that have explicit implementations of existential quantification are Haskell and Scala. It would be greatly beneficial for a language like TypeScript, one that is accessible to many, to introduce the concept to the programming masses. It's a powerful feature and one that should be in every developers playbook or at least on their radar.

submit

_I See It, I Like It, I Want It, I youtube-dl It

delete

[`youtube-dl`](https://ytdl-org.github.io/youtube-dl/index.html) is the best way to download high quality videos from YouTube. Instructions for how to install it are located [here](https://github.com/ytdl-org/youtube-dl/blob/master/README.md#installation). The tool has a large API surface area and dense documentation which can result in a frustrating experience when you *just* want to download a video. If you see it, like it, want it, this guide will help you get it.

## List Available Formats

```plaintext
youtube-dl -F https://youtu.be/QYh6mYIJG2Y
```

```plaintext
[youtube] QYh6mYIJG2Y: Downloading webpage
[youtube] QYh6mYIJG2Y: Downloading video info webpage
[info] Available formats for QYh6mYIJG2Y:
format code  extension  resolution note
249          webm       audio only tiny   61k , opus @ 50k (48000Hz), 1.15MiB
250          webm       audio only tiny   79k , opus @ 70k (48000Hz), 1.50MiB
140          m4a        audio only tiny  130k , m4a_dash container, mp4a.40.2@128k (44100Hz), 2.86MiB
251          webm       audio only tiny  150k , opus @160k (48000Hz), 2.91MiB
394          mp4        256x144    144p   85k , av01.0.00M.08, 24fps, video only, 1.62MiB
278          webm       256x144    144p   98k , webm container, vp9, 24fps, video only, 1.94MiB
160          mp4        256x144    144p  110k , avc1.4d400c, 24fps, video only, 1.71MiB
395          mp4        426x240    240p  193k , av01.0.00M.08, 24fps, video only, 3.31MiB
242          webm       426x240    240p  221k , vp9, 24fps, video only, 3.52MiB
133          mp4        426x240    240p  294k , avc1.4d4015, 24fps, video only, 3.57MiB
396          mp4        640x360    360p  352k , av01.0.01M.08, 24fps, video only, 5.90MiB
243          webm       640x360    360p  408k , vp9, 24fps, video only, 6.27MiB
134          mp4        640x360    360p  573k , avc1.4d401e, 24fps, video only, 6.55MiB
397          mp4        854x480    480p  638k , av01.0.04M.08, 24fps, video only, 10.28MiB
135          mp4        854x480    480p  725k , avc1.4d401e, 24fps, video only, 8.95MiB
244          webm       854x480    480p  746k , vp9, 24fps, video only, 9.58MiB
136          mp4        1280x720   720p 1142k , avc1.4d401f, 24fps, video only, 13.73MiB
398          mp4        1280x720   720p 1279k , av01.0.05M.08, 24fps, video only, 20.58MiB
247          webm       1280x720   720p 1454k , vp9, 24fps, video only, 16.57MiB
399          mp4        1920x1080  1080p 2237k , av01.0.08M.08, 24fps, video only, 35.73MiB
248          webm       1920x1080  1080p 2659k , vp9, 24fps, video only, 41.98MiB
137          mp4        1920x1080  1080p 3965k , avc1.640028, 24fps, video only, 48.01MiB
18           mp4        640x360    360p  589k , avc1.42001E, mp4a.40.2@ 96k (44100Hz), 12.99MiB (best)
```

## Determine The Highest Quality Video+Audio Formats

Do *not* rely on the `(best)` note. Follow this simple algorithm instead.

1. Find the largest video with the highest resolution in the desired format.
2. Find the largest compatible audio.

Applying the algorithm to the example results in `248` and `251`. I chose `webm` because I find it looks and plays better than `mp4`.

## Download

```plaintext
youtube-dl -f 248+251  https://youtu.be/QYh6mYIJG2Y
```

```plaintext
[youtube] QYh6mYIJG2Y: Downloading webpage
[youtube] QYh6mYIJG2Y: Downloading video info webpage
[download] Destination: Ariana Grande - 7 rings-QYh6mYIJG2Y.f248.webm
[download] 100% of 41.98MiB in 00:00
[download] Destination: Ariana Grande - 7 rings-QYh6mYIJG2Y.f251.webm
[download] 100% of 2.91MiB in 00:00
[ffmpeg] Merging formats into "Ariana Grande - 7 rings-QYh6mYIJG2Y.webm"
Deleting original file Ariana Grande - 7 rings-QYh6mYIJG2Y.f248.webm (pass -k to keep)
Deleting original file Ariana Grande - 7 rings-QYh6mYIJG2Y.f251.webm (pass -k to keep)
```

I used `ffmpeg`, a dependency of `youtube-dl`, to make the loop above.

```plaintext
ffmpeg -i input.mp4 -filter_complex "[0:v]reverse,fifo[r];[0:v][r] concat=n=2:v=1 [v]" -map "[v]" output.mp4
```

The command [concatenates a reversed version of the clip to itself](https://stackoverflow.com/questions/42257354/concat-a-video-with-itself-but-in-reverse-using-ffmpeg).

submit

_Leveraging Go’s Interfaces to Great Effect

delete

Suppose you're developing a web server. One of the request handlers performs logging, authentication, HTTP requests, and database queries. It's provided these capabilities by four structs passed in as arguments and looks something like this:

```go
func createProductHandler(
	l *logger,
	a *auth,
	c *client,
	d *db
) *response {
	// ...
}
```

As the handler deals specifically with creating products, it only uses a few of the methods provided by this set of structs. As a result, the function signature doesn't tell us about the specific behavior of the handler or the side effects it produces. Worse, its coupled to the implementation of the structs. If we were to change their names, split one into multiple, or move methods from one to another, we'd have to modify the handler as well.

With interfaces, we can solve these problems by grouping actions into "effects".

```go
type loggerEff interface { ... }
type authEff interface { ... }
type baseHandlerEff inteface {
	loggerEff,
	authEff,
}
type shopifyEff interface { ... }
type productQueriesEff interface { ... }

type createProductEff interface {
	baseHandlerEff,
	shopifyEff,
	productQueriesEff,
}

func createProductHandler(
	ctx createProductEff
) *Response {
	// ...
}
```

The handler's signature now contains a great deal of **semantic information**. It specifies the side effects the procedure will produce and gives the reader a general understanding of the handler's purpose. The business logic has been **decoupled** from the implementation details. The handler no longer has to change if we modify the structs that implement the interfaces. We created a way to **inject dependencies** into the handler, greatly reducing the burden of argument passing. We can **mock** the interfaces which significantly improves the testability of the handler.

To further understand the pattern, let's explore a runnable example. A web server example would require a number of dependencies that, when wired together, create an opinionated "framework". This would *incorrectly* imply that the pattern is tied to a framework and relegated to web servers. Instead, let's create a fun little guessing game. You can find the full code [here](https://github.com/wilfreddenton/gophects).

The game asks the player to input a number of `turns`, a `low` number, and a `high` number. Once the game has been configured, it will randomly select a hidden number between `low` and `high`. It’s the player's job to guess the number in `turns` attempts.

Consider the effects that could help us here. We need some way to interact with the user. These actions can be grouped in what we'll call the console effect. We also need a way to generate random numbers. Let’s call that the random effect. Notice that we've zeroed in on the parts of the app that perform IO.

Let's specify the console effect.

```go
type consoleEff interface {
	putStr(string)
	putStrLn(string)
	getLine(string) string
}
```

`putStr` and `putStrLn` provide ways to write a string to the console. With `getLine` we can write a prompt `s` to the console and allow the player to input a string which is returned by the function.

How might we implement these actions in a pure way?

```go
type consolePure struct {
	in  []string
	out string
}
```

`in` and `out` are representations of `stdin` and `stdout`. `in` is a list of strings which mocks the series of inputs provided by the player. `out` is a string which will contain the output of the program.

```go
func (p *consolePure) putStr(s string) {
	p.out += s
}
```

`putStr` simply appends the provided string to `out`.

```go
func (p *consolePure) putStrLn(s string) {
	p.putStr(s + "\n")
}
```

`putStrLn` is the same as `putStr` except it tacks on a newline.

```go
func (p *consolePure) getLine(s string) string {
	in := p.in[0]
	p.putStrLn(fmt.Sprintf("%s%v", s, in))
	p.in = p.in[1:]
	return in
}
```

`getLine` pops off mocked player input from the head of `in`, writes the input prefixed with the prompt `s` to `out`, and returns the input.

While we're still not certain how the entire program will look, we know we need a way to read in settings from the user.

```go
func getTurns(ctx consoleEff) int {
	for {
		turnsS := ctx.getLine("turns: ")
		turns, err := strconv.Atoi(turnsS)
		if err != nil {
			ctx.putStrLn(turnsS + " is not an int")
		} else if turns < 1 {
			ctx.putStrLn("turns must be > 0")
		} else {
			return turns
		}
	}
}
```

The code itself is pretty straight forward. The thing to notice is that the function takes a context object that implements `consoleEff`. Inside the body we can see the `consoleEff` actions being used.

Since we've already written the pure implementation of `consoleEff` we can now write a test for `getTurns`. If we were adhering to TDD we should have written the test first but its easier to explain after you've seen the implementation.

```go
func assert(t *testing.T, g, e interface{}) {
	if g != e {
		t.Error(g)
	}
}

func TestGetTurns(t *testing.T) {
	ctx := &consolePure{in: []string{"t", "0", "1"}}
	turns := getTurns(ctx)
	assert(t, turns, 1)
	assert(t, ctx.out, `turns: t
t is not an int
turns: 0
turns must be > 0
turns: 1
`)
}
```

First we define an `assert` function to help us compare expected values and results. In a serious application we'd want something more robust but it will do for this exercise. The test begins by defining the context. As `getTurns` only expects `consoleEff`, we can satisfy the constraint with an instance of `consolePure`. We provide the constructor with a list of mock player input. One element from this list will be supplied to `getTurns` each time it calls `ctx.getLine`. Like any pure function, we can make an assertion about the result but because we mocked the console effect, we can also make an assertion about the side effect.

The implementations of `getLow`, `getHigh`, and their tests is very similar to what was described above so let's to the next part.

Now that we have these three functions implemented and tested we can use them to `setup` the game:

```go
type settings struct {
	turns int
	lo    int
	hi    int
}

func setup(ctx consoleEff) *settings {
	ctx.putStrLn("Guessing Game")

turns := getTurns(ctx)
	lo := getLow(ctx)
	hi := getHigh(ctx, lo)
	return &settings{turns, lo, hi}
}
```

Notice how this function passes the context to `getTurns`,  `getLow`, and `getHigh`. When "contextualizing" child functions, the child's constraints must be a subset of the parent's.

The test for `setup` is similar to the ones we've already written:

```go
func TestSetup(t *testing.T) {
	ctx := &consolePure{in: []string{"5", "1", "10"}}
	r := setup(ctx)
	assert(t, r.turns, 5)
	assert(t, r.lo, 1)
	assert(t, r.hi, 10)
	assert(t, ctx.out, `Guessing Game
turns: 5
low: 1
high: 10
`)
}
```

Now that we have a way for the player to configure the game we can implement the game itself. We know the game needs to generate a random number so let's start by specifying the random effect.

```go
type randEff interface {
	randomR(int, int) int
}
```

This effect is simpler than `consoleEff`, only specifying a single action which selects a random number from within a range. Here's a pure implementation of it:

```go
type randPure struct {
	n int
}

func (r *randPure) randomR(lo, hi int) int {
	r.n = (lo + hi) / 2
	return r.n
}
```

`randPure` keeps track of the most recently generated "random" number in `n`. This pure implementation just returns the average of `lo` and `hi`. It could have been implemented many different ways; for example, `lo + 1` or `hi - 1`. The important thing is that it *deterministically* produces the value so we can rely on our tests running the same every time.

Now that we have an implementation for `randEff` we can write the `play` portion of our game.

```go
type playEff interface {
	consoleEff
	randEff
}

func play(ctx playEff, s *settings) {
	n := ctx.randomR(s.lo, s.hi)
	i := s.turns

for i > 0 {
		gS := ctx.getLine("guess: ")
		g, err := strconv.Atoi(gS)
		if err != nil {
			ctx.putStrLn(gS + " is not an int")
			continue
		}

if g < n {
			ctx.putStrLn("higher")
		} else if g > n {
			ctx.putStrLn("lower")
		} else {
			ctx.putStrLn(gS + " is correct")
			return
		}

i -= 1
	}

ctx.putStrLn("game over")
}
```

I'll leave it to you to read and understand the business logic. Notice that `play` takes a context that implements `playEff`. This is different from what we've seen before. Interface inheritance allows us to compose `consoleEff` and `randEff` to create `playEff`. At a glance, we know that `play` will be interacting with the player and generating random numbers.

Now let's write the tests for `play`:

```go
func TestPlayWin(t *testing.T) {
	ctx := struct {
		*consolePure
		*randPure
	}{&consolePure{in: []string{"x", "3", "7", "5"}}, &randPure{}}
	r := &settings{3, 1, 10}
	play(ctx, r)
	assert(t, ctx.n, 5)
	assert(t, ctx.out, `guess: x
x is not an int
guess: 3
higher
guess: 7
lower
guess: 5
5 is correct
`)
}

func TestPlayLoss(t *testing.T) {
	ctx := struct {
		*consolePure
		*randPure
	}{&consolePure{in: []string{"x", "3", "7"}}, &randPure{}}
	r := &settings{1, 1, 10}
	play(ctx, r)
	assert(t, ctx.out, `guess: x
x is not an int
guess: 3
higher
game over
`)
}
```

We test two sequences of user input, one that results in a win, and one a loss. The structure of these tests is the same as the ones we've seen previously except that an instance of `randPure` must also be provided to the context. Struct inheritance allows us to easily create a context object that exposes all the methods of the composed structs.

The game has now been implemented and tested! By abstracting the IO actions into effects we purified the business logic making it immediately testable. The last thing to do is write the IO implementations of our effects and then compose it all together in a `main` function.

```go
type consoleIO struct{}

func (p *consoleIO) putStr(s string) {
	fmt.Print(s)
}

func (p *consoleIO) putStrLn(s string) {
	fmt.Println(s)
}

func (p *consoleIO) getLine(s string) string {
	fmt.Print(s)
	var in string
	fmt.Scanln(&in)
	return in
}
```

We decided with `consolePure` how the output should look so we just imitate it in `consoleIO`.

```go
type randIO struct{}

func (r *randIO) randomR(lo, hi int) int {
	rand.Seed(time.Now().UnixNano())
	return rand.Intn(hi-lo) + lo
}
```

In `randomR`, we use the current time to seed the pseudorandom number generator. We could have also sourced cryptographically secure random bytes from `/dev/urandom` using the `crypto/rand` package but that's beyond the scope of this example.

As these are very simple implementations they do not necessitate unit tests; however, it is of course best practice to unit test whenever possible.

Finally we can implement `main`:

```go
func main() {
	ctx := struct {
		*consoleIO
		*randIO
	}{&consoleIO{}, &randIO{}}

s := setup(ctx)
	play(ctx, s)
}
```

Notice how similar this is to the tests. The critical difference is that we used the IO implementations instead of the pure.

While certainly a contrived example, I hope it was an illustrative one. The primary takeaway should be that *interfaces are powerful*. In this example, they provided us a way to mock, inject dependencies, decouple business logic from implementation details, and make function definitions more semantically meaningful. In real-life applications you will come up with more interesting effects and implementations. Because they are completely decoupled from business logic you can package them up into an effect library for use across all your projects.

There are a few open source packages that can assist with this pattern. You could use something like [gomock](https://github.com/golang/mock) to generate pure implementations of your effects. You may find yourself constructing very large context `structs` and something like [wire](https://github.com/google/wire) could help automate that. As these types of libraries involve the use of reflection and/or code generation I tend to avoid them; however, they may be necessary for larger projects.

If you're a Haskeller you might be thinking that this all feels very familiar. That's because the pattern came out of my experiences working on [`mtl`](https://hackage.haskell.org/package/mtl) style codebases. Go's interfaces pale in comparison to Haskell's typeclasses but they can still be used to great effect.

submit

_iPad Pro: My Daily Driver

delete

The 2018 12.9" iPad Pro has been my daily driver for over a year. While imperfect, the experience far exceeded my expectations and I may never purchase a laptop again.

Awhile back, I realized my MacBook Pro wasn't being used to its full potential. 99% of the time only Firefox and Emacs were running. When it came time for a new machine, I purchased a mid-tier ThinkPad which was significantly cheaper than the available MacBook Pros but comparable in specs. During its period of use, I tried three different operating systems: Ubuntu, Manjaro, and NixOS. While each has its pros and cons, the primary issue I had with all of them was the web browsing experience. Mixing and matching hardware with software can never result in the kind of performance I'd come to expect living in Apple's walled garden.

Eventually I found myself back in the Apple Store to pickup some AirPods. As I was leaving with my bougie new headphones, the iPad Pro caught my eye. I immediately noticed the 120hz display. It gave the apps a feeling of "realness" I'd never experienced before. Tablets had always seemed superfluous, used only by people whose work consists primarily of emailing. Now, based almost entirely on the quality of the display, I wanted to see if the iPad could work for me.

After a year of use, I'm very pleased with the experience provided by the iPad's stellar hardware, quality app ecosystem, and the many useful accessories.

## Hardware

There's really no way to describe the display. If you haven't used it, go to an Apple Store and try it. While the 4:3 aspect ratio may be a turn off to some, I've found that it is better for web browsing and coding than the more common 16:9 aspect ratio. The 12.9" display has plenty of width to make HD and 4K video feel immersive. The colors are full of life and the blacks are the deepest I've seen on an LCD. The 264ppi resolution makes text crisp and easy to read.

Complimenting the display is the Apple A12X Bionic chip which seems to never break a sweat. The animations are fluid, media editing performance is incredible, and you can [play Fortnite at 120fps](https://www.theverge.com/2020/1/19/21073526/fortnite-ipad-pro-frame-rate-120-fps).

The build quality and design is the best I've seen from Apple in years. The return of the boxy design—reminiscent of the iPhone 5—makes it look both classy and tactical.

Perhaps the most impressive aspect of the iPad Pro's hardware is the truly all day battery life. I routinely get 8 hours of screen on time and never worry about running out.

I do find that, with a rather pitiful 6GB of RAM, iPadOS must perform aggressive RAM management, "blanking out" apps when you switch away from them. I hope the situation will improve as iPadOS deviates from iOS and new models ship with more RAM.

## Software

### Safari

Safari evolved from a blown up phone app to an *almost* desktop class browser in iPadOS 13. With fast rendering, slick animations, a FaceID integrated password manager, landscape and portrait view modes, ad blocker extensions, and the always convenient form factor of the iPad, it's the best way to view the web. However, it's not without its faults.

Support for complex web apps is still lacking. For those who view and create spreadsheets or slideshows extensively, the iPad setup just doesn't work. The native apps have only a fraction of the features compared to their desktop counterparts and the web apps are impractical to use on iPadOS Safari. I believe these problems will eventually be solved as the iPad becomes more widely used in the workplace.

Another issue with Safari is the ephemerality of tabs. A result of the more general RAM problem I discussed previously, iPadOS will frequently blackout tabs and reload them next time they're viewed.

### [Blink Shell](https://apps.apple.com/us/app/blink-shell-mosh-ssh-client/id1156707581)

This app is the core of the setup. When opened, it presents you with a unix-like command prompt providing a small palette of commands. As `Blink` is not a full unix environment, for this setup to work, a remote development server is required. The two remote connection utilities provided by Blink are `mosh` and `ssh`. For those unfamiliar with the greatness of [`mosh`](https://mosh.org/), think of it like an enhanced `ssh`. Predictive updating and support for intermittent connectivity provide the feeling of working locally.

In theory, `mosh` should maintain a connection to the remote server even after locking the iPad or changing WiFi connections. In practice, `mosh` will occasionally be unable to automatically reconnect. I believe this happens when using WiFi networks that have multiple and/or poorly setup access points. For the times when `mosh` drops the ball, `tmux` is there. Because my server is running both `mosh` and `tmux` I can connect to it with:

```plaintext
mosh <host> -- tmux a -d
```

This will attach (`a`) my new `mosh` session to the existing `tmux` session and detach (`-d`) the broken `mosh` session. Put simply, it reopens my development environment exactly as I left it. Here's my `~/.tmux.conf`:

```plaintext
new-session
set status-utf8 on
set utf8 on
set -g default-terminal "screen-256color"
set -g status off
```

`set -g status off` will disable the `tmux` status bar which completely hides the fact that `tmux` is in use.

While it may seem like a pain to work in a remote server, one significant benefit is that no matter what computer you're on, you can connect to your development environment.

For those of you who want to use a Graphical IDE, Blink and `mosh` will not help you with that. What I've described is only for terminal based editor users. I have not explored the ecosystem for iPad app IDEs but I imagine the offerings are pretty limited.

### Files

The Files app was a welcome sight when it released with iOS 11. Since then it has been improved significantly. You can now view and manage external hard drives, USB drives, and SD cards. However, for the purposes of my setup, it lacks the crucial ability to (S)FTP into a remote server. For that I use [FileBrowser](https://apps.apple.com/us/app/filebrowser-document-manager/id364738545). Interoperability between the two apps is superb. They can be viewed side by side allowing me to drag multiple files from my remote server into the Files app and vice versa. FileBrowser even provides an extension allowing me to manage my remote files within the Files app.

A tip for using FileBrowser: when you setup an SFTP connection you can authenticate with an `ssh` key by saving the private key in the "My Private Files" folder. The name of the key file must follow this pattern:

```plaintext
<user>.<ip_address>.<port>.sftp
```

If you're looking for a free alternative to FileBrowser, give [FTPManager](https://apps.apple.com/us/app/ftpmanager-ftp-sftp-client/id525959186) a try.

## [iVim](https://apps.apple.com/us/app/ivim/id1266544660)

Unfortunately, support for copying text from the remote shell into a local iPad app is poor. For example, the copying mechanism on the iPad does not understand the separation of "windows" in Emacs. It copies at the "cell" level. I'm forced to copy from the contents of a remote file. I navigate to the remote file in FileBrowser and then share and open the file with iVim. iVim is a port of Vim which seems to be able to open plaintext files of any extension. I copy the necessary lines in iVim and then paste wherever I need to. Fortunately, Copying from an app into the remote shell does work well.

## [Inspect Browser](https://apps.apple.com/us/app/inspect-browser/id1203594958)

For front end web development, you need to be able to view the UI in a browser. At first this seems impossible with just a remote shell but it's entirely possible with just a bit of setup. First, open up a range of TCP ports on your remote server. Then you can run the UI's backend on a port in the range. For example, you might run a web server you're working on at `http://localhost:1337` now you can view it in your iPad's Safari at `http://my.servers.public.ip:1337`. The problem is that Safari doesn't provide any web tools and caches static assets aggressively. This is where Inspect Browser comes in. It gives you many of the tools that the Chrome web inspector provides albeit in a clunkier interface.

## [iA Writer](https://apps.apple.com/us/app/ia-writer/id775737172)

iA Writer is my favorite markdown editor which I use to write blog posts and documentation. There are plenty of others to choose from but I've found this one to be the best.

## [Octal](https://apps.apple.com/us/app/octal/id1308885491)

Octal is a great way to read Hacker News on the iPad.

## Accessories

### [HyperDrive 6-in-1 USB-C Hub](https://www.hypershop.com/products/hyperdrive-6-in-1-hub-for-ipad-pro-2018)

If you only buy one accessory, this is the one to buy. With a complete array of ports, HDMI, SD card, Micro SD, USB-A (outbound charging), USB-C (2-way charging), and the much coveted 3.5mm audio jack, this thing is the real deal. For $70 this dongle provides incomparably more value than anything Apple has to offer.

The main issue has nothing to do with the accessory itself. iPadOS still has embarrassingly poor external display support. By default, apps will mirror themselves in a fixed 4:3 aspect ratio (even if the external display is 16:9). For better support, apps have to implement that themselves. Blink properly utilizes an external display by rendering a resolution adapting terminal.

### [Brydge Pro](https://www.brydge.com/products/brydge-for-ipad-pro-2018)

Do not buy this keyboard. My experience with it was very poor. While it sports an impressive amount of features, the execution is lackluster. The clamps that hold onto the iPad move independently making it difficult to fit the device in place. These clamps are covered in cheap rubber sleeves that slip off constantly and eventually rip due to strain from repeatedly attaching and detaching the iPad. The thin rubber bumpers that are supposed to keep the iPad raised above the keyboard while in the closed position are too far from the edge. As a result, the top of the iPad hits the metal of the keyboard which could scratch the glass or even bend the chassis. The keys themselves, while having decent travel, are made from a terrible cheap plastic. As this is a bluetooth keyboard you will have to worry about charging it; however, the battery does last a very long time.

### [Apple Smart Keyboard](https://www.apple.com/smart-keyboard/)

While a flawed device, I've had a much better time with this keyboard than the Brydge. The texture of the keys feels premium, the closed position keeps the iPad flush against the keyboard, and it doesn't need to be charged. If Apple figures out a way to give it a hinge instead of just the two viewing angles it would be significantly better. The $200 price tag is absurd but what else can you expect from Apple.

### [HHKB Professional Hybrid Type-S](https://fujitsuscannerstore.com/cg01000-297001/)

Fujitsu recently added Bluetooth 4.2 and USB-C to an already incredible keyboard. It works perfectly with my iPad and my Windows Desktop. I can send an iMessage on the iPad, press a key combo, and then immediately be playing [Path of Exile](https://www.pathofexile.com) on the PC.

### [Apple Pencil](https://www.apple.com/apple-pencil/)

The 2nd generation Apple Pencil is an impressive gadget. The magnetic wireless charging mechanism works perfectly. I use it often for "back of the napkin" math, service architecture diagrams, and wireframes. As I don't draw often, I probably could have bought a cheaper stylus, but the sleek design and perfect compatibility with the iPad won me over.

### [Logitech MX Master 2S](https://www.amazon.com/Logitech-Master-Wireless-Mouse-Rechargeable/dp/B071YZJ1G1)

iPadOS 13 brought minimal mouse support to the iPad. It doesn't function like a desktop mouse instead acting more like a "virtual finger". Still, it makes using the iPad with an external display and keyboard much easier. Any bluetooth [BT] mouse with extra buttons should work well. I use an MX Master 2S, mapping the additional buttons to various iPad actions like opening up the App Switcher. The new [Logitech MX Master 3](https://www.amazon.com/Logitech-Master-Advanced-Wireless-Mouse/dp/B07S395RWD) would be great as well.

When traveling, I use the the [Microsoft Arc Mouse](https://www.amazon.com/Microsoft-Arc-Mouse-ELG-00001-Black/dp/B072FG8LBV). The design is sexy and the innovative snap feature proves Microsoft can *think different*. Usability was clearly sacrificed for portability but it gets the job done when you're on the go.

I wish the Magic Trackpad was more compatible with iPadOS. Using gestures instead of buttons to perform actions would provide a more familiar way to interact with an iPad.

To use a BT mouse with your iPad go to the following settings menu:

```plaintext
Settings -> Accessibility -> AssistiveTouch
```

Here there is a toggle to turn on AssistiveTouch as well as a bunch of other settings. I like to turn the "Idle Opacity" to the lowest. In "Pointer Style" I choose the smallest possible size. In "Devices" you can connect the BT mouse. Once connected, you can tap the device to map actions to buttons.

I also like to add the "Accessibility Shortcuts" control to Control Center and enable the AssistiveTouch shortcut so it's easy to toggle on and off.

Unfortunately, mouse support is still buggy. For some reason iPadOS thinks that my mouse is also a keyboard. If I disconnect my USB keyboard (plugged in with the HyperDrive dongle) while the BT mouse is still connected, no on-screen keyboard will appear. If I connect the keyboard while the BT mouse is connected, none of the commands like `Command + Tab` or `Command + Space` will work within apps but *will* work on the home screen. This forces you to consider the order in which you connect your devices. Start with the BT mouse turned off. Connect the keyboard, then turn on the BT mouse which should automatically connect if paired. When disconnecting the keyboard just make sure the mouse gets turned off and the on-screen keyboard should appear.

Additionally, the mouse related animations are ugly. The cursor practically jumps around the screen and scrolling with the mouse wheel is a stutter-fest. It's a pretty poor experience so far but still manages to be better than touch when using the iPad as part of a larger setup.

## Insecure About the Future

I plan on using this setup into the foreseeable future but there are some concerns.

It seems that Blink is [maintained by a single person](https://github.com/blinksh/blink/commits/raw). While I have nothing but respect for yury, I can't help but think that dealing with [hundreds of issues](https://github.com/blinksh/blink/issues) alone will cause burnout eventually. The only other option I see in the app store is [Terminus](https://apps.apple.com/us/app/termius-ssh-client/id549039908) but it doesn't share the minimalist philosophy I love so much about Blink.

`mosh` hasn't seen a release since summer 2017. There's an [issue](https://github.com/mobile-shell/mosh/issues/974) about it on Github but it doesn't seem like much progress is being made. As there really is nothing else like `mosh`, this is potentially a huge problem for the longevity of the setup.

iPadOS needs desktop class RAM management and generally iPads need more RAM. If apps on your laptop had their state cleared every so often you would be upset right? If I have an app open it's because I'm using it and I need its state to be maintained.

The fact that the $200 Apple Smart Keyboard is the best portable keyboard option I've found is sad. Somebody, other than Brydge, please make a keyboard that has a 360 degree hinge and a built-in trackpad.

## I Need an Appliance not a Computer

At the risk of starting a war, to me, an iPhone is just a fancy phone and an Android is a computer in your pocket. While this may seem like a rag on iPhone, this is exactly why I use one. I don't need a phone to do all the things Android is capable of. I just need it do a few important things reliably. The iPhone is an appliance and so is the iPad. That's why it works for me. The vast majority of my work is web browsing and Emacsing, the iPad provides these two capabilities in a way no laptop can.

submit

_Enjoy Writing JavaScript With Async/Await

delete

JavaScript has come a long way since the days of [callback hell](http://callbackhell.com/). Many libraries were introduced to help ease the pain but it wasn't until the introduction of [promises](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) did things really start to improve.[^lol] While promises solve the nesting issue, chaining them together is still an awkward way to compose a procedure.

[^lol]: Pretentious haskellers sneered and said something like "Lmao, the script kiddies unwittingly discovered monads".

Now that `async/await` has full support in LTS versions of `node` as well as recent versions of [all *modern* browsers](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function#Browser_compatibility), JavaScript can be enjoyable to write. If you are targeting older platforms, [Babel](https://babeljs.io/) can help by providing polyfills or by compiling your code to specific targets.

## You Can't Erase History

While `async/await` does an excellent job of covering up the old blemishes, history cannot be erased. Callbacks and promises will still be used however sparingly.

```javascript
function sleep(ms) {
  return new Promise(resolve => {
    setTimeout(() => {
      resolve(ms)
    }, ms)
  })
}
```

In the example above, the familiar `setTimeout` function is being "promisified" to create a convenient `sleep` function. At the bottom "layer", there's a call to the `resolve` function provided by the promise. `resolve` is mostly synonymous with `return`. Whatever value we `resolve`, in this case `ms`, can be thought of as the return value of the promise. Because `resolve` is invoked within the callback function of `setTimeout`, the promise will "return" after `ms` milliseconds. Historically, to synchronize this promise, we would use `sleep(ms).then(...)` but with `async/await` we can just `await sleep(ms)`. This layering/wrapping pattern can be used to "modernize" any legacy higher-order function. Suppose you want to use `fs.readFile`, wrap it in a promise, and then call it with `await`.

## Composing Async Functions

```javascript
// sync version
function main() {
  syncSleep(1000)
  syncSleep(2000)
  syncSleep(3000)
}

main()
```

```javascript
// async version
async function main() {
  await sleep(1000)
  await sleep(2000)
  await sleep(3000)
}

main()
```

The first code block shows how normal synchronous code is composed into a procedure. This example is both fake in that  `syncSleep` does not exist and contrived in that you could just `syncSleep(6000)` if it did but go with it. The second block composes asynchronous functions and it's nearly identical to the first except for the addition of `async` and `await`. If you need to synchronize a promise or a function that includes `async` in its definition (also a promise under the hood), call it with the `await` keyword. Any function that contains `await`ed calls must include the `async` keyword in its definition.

To prove that the sleeps in `main` take a total of 6 seconds to run we can write a timing mechanism.

```javascript
async function timed(action) {
  console.log('running timed action...')
  const start = Date.now()
  await action()
  console.log(`${Math.floor((Date.now() - start) / 1000)} seconds elapsed`)
}
```

Because `timed` takes an async action, `await` is used to synchronize it. As `await` is used within the body of `timed`, it must include the `async` keyword in its definition. Now we can modify `main` to use `timed`.

```javascript
async function main() {
  await timed(async () => {
    console.log(await sleep(1000))
    console.log(await sleep(2000))
    console.log(await sleep(3000))
  })
}

main()
```

The example groups the calls to `sleep` within an asynchronous anonymous function which is passed, as the async action, to `timed`. Running this produces the output:

```plaintext
running timed action...
1000
2000
3000
6 seconds elapsed
```

From the output it is clear that the calls to `sleep` are running synchronously and do not "overlap" in any way.

## Running Async Functions Concurrently

Sometimes we don't want to run a set of async actions synchronously. Instead we'd like to compose them into a single async action that runs the sub-actions concurrently.

Pretend that `sleep(1000)`, `sleep(2000)`, and `sleep(3000)` are all requests to some API that fetch data and have `ms` latency. The requests are totally independent so they can be performed concurrently. If we `await` each one sequentially like in the previous example, we are waiting unnecessarily long. As requests are typically IO bound, sending request concurrently provides a significant performance boost.

We can do this easily with the extremely useful and oft forgotten `Promise.all` which takes a list of `await`able actions:

```javascript
async function main() {
  await timed(async() => {
    console.log(await Promise.all([
      sleep(1000),
      sleep(2000),
      sleep(3000),
    ]))
  })
}

main()
```

Running this produces different output:

```plaintext
running timed action...
[ 1000, 2000, 3000 ]
3 seconds elapsed
```

Because the three requests (sleeps) are run concurrently, the total elapsed time is bounded by the request that takes the longest, in this case, 3 seconds. Notice that the result of `Promise.all` is a list of the return values of each sub-action. Destructuring makes this easy to handle:

```javascript
[r1, r2, r3] = Promise.all([a1, a2, a3])
```

## Exception Handling

Now that asynchronous code looks essentially the same as synchronous code we can use the previously irrelevant `try/catch/finally` construct.

Let's make a new promise that again uses `setTimeout` but this time results in an error.

```javascript
function nightmare(ms) {
  return new Promise((_, reject) => {
    setTimeout(() => {
      reject(ms)
    }, ms)
  })
}
```

`nightmare` is the same as `sleep` except that it uses `reject` instead of `resolve`. `reject` is to `throw` as `resolve` is to `return`.

```javascript
async function main() {
  try {
    await timed(async () => await nightmare(1000))
  } catch (error) {
    console.error(`error: ${error}`)
  } finally {
    console.log('always runs')
  }
}

main()
```

Running the above produces:

```plaintext
running timed action...
error: 1000
always runs
```

The exception generated by `nightmare` bubbles up through the timing mechanism, up into `main` where it is caught and logged. The `console.log` in the `finally` block demonstrates that code in a `finally` will run regardless of whether or not the code in the `try` throws an exception.

## JavaScript, Elegant?

JavaScript was one of the first languages I learned. Maturing as a developer while the language matured has been an edifying experience. As the community around the language became more knowledgable and skillful, the more elegant the language became and vice versa. Many times the community has been made fun of for rediscovering solutions to problems already solved by a host of other languages. While there is certainly truth to that, this constantly evolving environment was the perfect place for young developers to learn, experiment, and grow.

submit

_Working With Multiple Git Identities

delete

Not everyone has the luxury of using their personal Github account for all their projects. It's quite common to have a company provided account as well as a few personal accounts. Without the proper local setup this can cause all kinds of issues: having to login every push, authentication errors, commits associated with the "wrong" account, etc. For those of us unfamiliar with `git` and/or `ssh`, wrangling multiple identities can be a daunting task but it's actually quite simple.

If you don't already use `ssh` for cloning and authentication then you will need to switch to that. While it requires some setup, no longer having to login to perform git actions is quite convenient.

Let's assume you have a `work` account and a `personal` account. If you don't already have `ssh` keys for these accounts follow this handy [guide](https://help.github.com/en/github/authenticating-to-github/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent) provided by Github. Once you've created both keys, [add them to your respective Github accounts](https://help.github.com/en/github/authenticating-to-github/adding-a-new-ssh-key-to-your-github-account).

Your `~/.ssh` directory should now look something like this:

```plaintext
.ssh/
|-- id_rsa_work
|-- id_rsa_work.pub
|-- id_rsa_personal
|-- id_rsa_personal.pub
```

There should be a public and private key for both of your accounts. If not, you may have overwritten the first set with the second.

If your `~/.ssh` directory doesn't already contain a `config` file you'll need to create one (`~/.ssh/config`). It should look something like this:

```plaintext
Host github.com-work
  HostName github.com
  User git
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_rsa_work

Host github.com-personal
  HostName github.com
  User git
  AddKeysToAgent yes
  IdentityFile ~/.ssh/id_rsa_personal
```

At first glance, this configuration may seem confusing but cloning a couple repos should clear things up.

Suppose you have a clone URL for a work repo like this:

`git@github.com:my-company/work-repo.git`

You'd need to change it to this:

`git@github.com-work:my-company/work-repo.git`

Notice how the `host` has changed from `github.com` to `github.com-work`. It's the same `host` that was specified in the `config` file. This tells `ssh` that the `id_rsa_work` key should be used for this repo and to map the custom `github.com-work` host to the actual host `github.com`. Now, to ensure that you're committing and pushing with the right identity, `cd` into the `work-repo` directory and setup a local `git` config.

```plaintext
git config user.name "my-work-username"
git config user.email "my-work-email"
```

As we are not using the `--global` flag, these commands only set the identity for the `work-repo` repo. You will *not* have to set this configuration again unless you delete the directory and reclone.

You can perform the process again for your personal repo swapping out the `github.com-work` custom host with `github.com-personal`, your work username for your personal username, and your work email for your personal email.

This process can be repeated for any number of identities, adding a "block" in the `ssh` config file for each.

submit

PGP Private Key

Create Post

Edit Posts

_Existential Quantification in TypeScript

_I See It, I Like It, I Want It, I youtube-dl It

_Leveraging Go’s Interfaces to Great Effect

_iPad Pro: My Daily Driver

_Enjoy Writing JavaScript With Async/Await

_Working With Multiple Git Identities

_Hello, World!

Edit About

Edit Contact