Forem: Babak

Learning Algorithms Through Games

Babak — Tue, 07 Jan 2020 17:43:03 +0000

I'm studying algorithms through games. I recently re-created one of those number slider games. As a kid, I remember getting these free puzzles from the flight crew.

See the code here:

https://github.com/babakness/number-slider

Algorithm

Making this game presents a number of neat challenges. The key algorithm to making this work is, given a matrix of numbers with size N*M, and empty piece, E; move each piece from a select piece P0 toward E.

Suppose we number each piece adjacent to P0 in an increasing fashion, ie P1, P2, ...Pn until we reach the empty square E. After the move, Pn will occupy the position of E, and each piece before it will move likewise until P0 is in the position of P1.

Finally, after P0 moves, the piece E is placed in its prior position.

Game Design

This game can be thought of as breaking down following the MVC structure. The main algorithms can be thought of as the Model, and the code manipulates the DOM as the Controller. Finally, the html page and the styles involved can be considered the View.

I use these names loosely, the essential idea is to break up our code into just enough abstractions to organize our code; but not so many as to create confusion.

Vanilla JS

No frameworks! The game uses the DOM API directly. It can be a good review of how to use regular DOM and CSS animations to achieve game play animations.

Useful functions

Some pretty nice functions came out of this.

Here is a function that throttles calls to an async function--only allowing the function to be called again after it has completed it task.

/**
 * HOF to prevent calls to an async function before it resolves
 * @param fn async function to throttle until resolve
 */
function throttleAsyncCalls<A,B>( 
    fn: (...args: A[]) => Promise<B> 
  ) {
  let wait = false
  return async function( ...args: A[] ) {
    if( wait === true ) {
      return
    }
    wait = true
    let result = await fn( ...args )
    wait = false
    return result
  }
}

How about this one, it dispatches a mouse click when you click "enter" on an element. This is useful for a11y.

  /**
   * When enter is pressed on an element, dispatch a click event on that element
   * @param event Keyboard Event
   */
  function routeEnterToClick( event: KeyboardEvent ) {
    let mouseClick = new MouseEvent( 'click', { bubbles: true } )
    if( event.key.toLowerCase() === 'enter' ) {
      event.target.dispatchEvent( mouseClick )
    }
  }

And much more 😁

Play around!

Have fun!

https://number-slider.algogames.dev

Follow me on Twitter at Babakness.

Understanding recursion using iteration (or vice versa)

Babak — Wed, 27 Nov 2019 09:01:31 +0000

Introduction

Understanding how recursion works can be difficult. In this lesson, we're going to look at how to flatten an array using iteration. Afterwards, I will write down a recursive solution to compare this too.

The Stack

The power of recursion is the stack. Each time a function calls itself, all variables are re-initialized. If you want to share state between function calls, you can either pass them along each function call explicitly, or you can use a closure to encapsulate data structures you want access through to all calls. There are pros and cons to each here.

The approach we'll use here is to simulate encapsulation, meaning our state stack will not need to pass along the resulting output array to each iteration.

The Approach

Here is an overview of our approach:

We're going to use a depth-first iterative method to flatten an array. The idea is to add each non-array item to a result array. When an array is discovered, we do some bookkeeping to remember where we left off then start analyzing this sub-array. Repeat.

How To Do It

Keep a results array and a state stack to track two states,

an array to analyze and analyze
a location in that array to start analyzing start

We'll want to start by setting the initial state of the stack, called stack

The array will be the base array
The index will be the zeroth index

So everything in our while loop is driven off of these states, start of type number and analyze of type array<unknown>

Now, while we have states in our stack stack

Iterate this array until a sub-array is discovered; otherwise, add the value to the result array
When a sub-array is discovered
- Remember our current state
- Set up the next state, the sub-array and index zero

Once we no longer have states, return the result.

The Code

// O(N)
function flattenArrIter( arr ) {
  // edge case, array is empty 
  if(!arr.length) return arr

  // output array
  let result = []
  // track states, start with first item in
  // given array
  let stack = [{ start:0, analyze: arr }]
  // while we have states in the stack
  while( stack.length ) {
    // destructure the states
    let { start, analyze } = stack.pop()
    let index = start
    // iterate until an array is discovered or we run out of items in the array
    while( index < analyze.length && !Array.isArray( analyze[index] ) ) {
      result.push( analyze[index] )
      index++
    }
    // if we have items in the array, we know that we must have found
    // an embedded sub-array
    if( index < analyze.length ) {
      // remember to start with the next item in the array after
      // analyzing the sub array
      stack.push({ start:index + 1, analyze })
      // start analyzing the sub array
      stack.push({ start:0, analyze: analyze[index] })
    }
  }
  // no more items in the stack
  return result
}

The Recursive Ways

Now let's look at the recursive way of doing this. First up, we'll use encapsulation.


function flattenArrWithEncapsulation( arr ) {
  // encapsulation, our helper will have access
  // to result array across function calls
  let result = []
  helper( arr )
  return result 

  function helper( analyze ) {
    for( let index = 0; index < analyze.length; index++ ) {
      let item = analyze[index]
      if( Array.isArray(item) ) {
        helper( item ) 
      } else {
        result.push( item )
      }
    }
  }
}

This function is pure because while it does mutate internally, it is deterministic and mutates nothing externally.

Also, its important to realize that while the function itself is pure, the inner helper function is not pure. It is bound to this function and mutates values outside itself. In this case the result array is mutated.

This is a good function to study when comparing recursion to iteration, at least for this particular case. Notice how each recursive call will spawn a new values for index and analyze just like the iterative method. This is how we "utilize the recursive stack"!

Side note:

Because we can use the for-of syntax here, we can re-write this in a more elegant way

function flattenArrWithEncapsulation( arr ) {
  // encapsulation, our helper will have access
  // to result array across function calls
  let result = []
  helper( arr )
  return result 

  function helper( analyze ) {
    for( let item of analyze ) {
      if( Array.isArray(item) ) {
        helper( item ) 
      } else {
        result.push( item )
      }
    }
  }
}

This masks how recursion is keeping track of the index in this stack. I thought to include it here to provide an additional point of comparison.

Bonus: Other Ways To Solve Recursively

In case you're wondering about encapsulation and mutation, let's consider how we could re-write using no encapsulation


function flattenArrNoEncapsulationNotPure( arr, result = [] ) {
  for( let item of arr ) {
    if( Array.isArray(item) ) {
      flattenArrNoEncapsulationNotPure( item, result ) 
    } else {
      result.push( item )
    }
  }
  return result
}

Neat! Yet this function is not pure! It mutates result!

Let's see how we can write this with no encapsulation and no mutation


// Don't use this, very inefficient! ~ greater than O(N^3) time complexity!
function flattenArrNoMutationNoEncapsulation( arr, index = 0, result = [] ) {
  // base case
  if( arr.length === index) {
    return result
  }
  if( Array.isArray( arr[index] ) ) {
    return result.concat( flattenArrNoMutationNoEncapsulation( arr[index], 0, result) )
  } else {

    return result.concat( arr[index] ).concat( flattenArrNoMutationNoEncapsulation( arr, index + 1, result) )
  } 
}

OK, I don't recommend using this, because it is much MUCH slower than all the other functions here. In fact, it will not run in O(N) time! This is because each concat call run in linear time, unlike push which is a constant time O(1) operation.

I believe the time complexity grows in Squared Pyramidal time

https://en.wikipedia.org/wiki/Square_pyramidal_number

Conclusion

In this article we looked at how to manually keep a state stack to emulate recursive solutions using iteration. These kinds of exercise help in understanding what the "recursive stack" is. I hope this has been a useful introduction in how iteration and recursion relate to each other.

Use the correct version of Node when starting VS Code terminal session using Fish

Babak — Wed, 11 Sep 2019 23:41:18 +0000

I like using Fish for interactivity at the terminal

https://fishshell.com

I also like using VS Code.

There are times I am working in a project that requires a specific version of Node. The problem I was having was that each and every time I opened up a new terminal in VS Code, I would have to remember to switch to the correct node version. Sure I could have an .nvmrc file, but then I would have to remember to issue nvm use. I could have my login script automatically issue that command; however, .nvmrc might be located in the parent directory.

Here is what I wanted:

Upon login check to see if there is a .nvmrc in the parent directory
If so, load the settings there
If not, do nothing

I discovered most of what I was after in this post by btoueg on GitHub

https://github.com/nvm-sh/nvm/issues/110#issuecomment-442955314

From that post I derived what I was looking for. First we need a find-up by btoueg and another function that will issue the nvm use command per .nvmrc found in our path.

function find-up --description 'Find file recursively in parent directory'

    set path (pwd)

    while test "$path" != "/" ; and not test -f "$path/$argv[1]"
        set path (dirname $path)
    end

    if test -f "$path/$argv[1]"
        echo "$path/$argv[1]"
    else
        echo ""
    end

end


function nvm-use --description 'run nvm using .nvmrc in parent directory'

  set loaded_version (node --version)
  set nvmrc (find-up '.nvmrc')

  if test -f $nvmrc
    set nvmrc_version (cat $nvmrc)
    if test $loaded_version != $nvmrc_version
      nvm use --silent
    end
  end

end

Then simply invoke it

nvm-use

I have that setup in my fish config file ~/.config/fish/config.fish. Now every time I open a new terminal in VS Code, it automatically switches to the correct version of node by looking for (and finding) .nvmrc in a parent directory.

An algorithm for picking random numbers in a range without repetition

Babak — Wed, 21 Aug 2019 03:00:12 +0000

Introduction

Picking random numbers in a range without repetition is a common task in many scenarios from cryptography to games. There are mathematical means for achieving this, for example, pseudo-random number algorithms like linear congruential generators (LCGs). These methods have their pros and cons. Some of the pros include that they can be fast and operate in constant O(1) space complexity. Common cons include that they may not generate all permutations possible and can be tricky to setup.

This article explores the problem of picking random numbers, covering all possible permutations, with O(M) space and time complexity, where M is the desired number of generated numbers, given by 0 <= M <= N and where N is the length of the range. Let's explore how we might do this:

A naïve approach might go like this:

Pick an index at random.
Check to see if we've picked that number before in a set S
If we have picked the number before, go to the first step
Otherwise, use the picked number and record it so we don't pick it again.

The problem with this approach is step 3--having to pick another number. This will slow down our algorithm, with more repetitions at steps 3 as the number of item we pick reaches the length of the array.

One solution to this is to just apply the Fisher-Yates algorithms for just the number of item we want, then return shuffled slice. The problem here is that if we want to pick M numbers within the range 0 to N without mutating the original array, we have to make a copy of the entire array and apply Fisher-Yates for just M items.

The Algorithm

Something we can do is use a hash map to track swipes that would otherwise occur in-place in Fisher-Yates. This idea is similar to using a Sparse Matrix, recording only the changes made to our array. Furthermore, we will keep that information around only for as long as we need. Let's see how this might work.

Let's suppose we have an array with 5 integers.

1 2 3 4 *5

Starting at the end, lets choose a number from 1 to 5. Let suppose we pick 3. At this point we would create a table like so

MAPPINGS
3 => 5

Then we would return 3

Next, we move to 4, choose from 1 to 4. Let's say 2. Record the mapping and return 2.

1 2 3 *4 5

MAPPINGS
3 => 5
2 => 4

return values: 3, 2

Now we are at 3. Let's suppose now we pick 3. We see 3 maps to 5. So we return 5. We delete 3, because we are done with it.

1 2 *3 4 5

MAPPINGS
2 => 4

return values: 3, 2, 5

Ok, this one will be tricky. For index 2 we'll pick 1. We could write 1 => 2, but 2 already appears as a mapping, so we will resolve that and set 1 => 4. Then we return 1. Here is how our state now appears:

1 *2 3 4 5

MAPPINGS
1 => 4

return values: 3, 2, 5, 1

Finally, for index 1, we resolve to 4. Our array looks like this:

3 2 5 1 4

The Code

Let's how the code for this might look like. Here it is in plain JavaScript


// Helpers
function randInt( num ) {
  return Math.floor( Math.random() * ( num + 1 ) )
}
function getMapOrElse( map, key, fallback ){ 
  return map.has( key ) ? map.get( key ) : fallback
}
let getMapKeyOrValue = ( map, key ) => getMapOrElse( map, key, key )

// Virtual Shuffle

export function* virtualShuffle( maxLength, quantity, randRange = randInt  ) {
  // set up hash map to record swaps
  let swapMap = new Map()

  // bind swapMap to helper function
  let swapMapValueOrKey = getMapKeyOrValue.bind( null , swapMap )

  // boundaries for quantity
  if (quantity > maxLength) quantity = maxLength
  if (quantity < 0) quantity = 0

  // define start and end points
  let start = maxLength - 1
  let end = start - quantity

  for( let pointerIndex = start; pointerIndex >= end ; pointerIndex--) {
    // select a random index up to the current pointer
    let randomIndex = randRange( pointerIndex )

    // yield the current randomIndex unless we have a
    // swap recorded. If so, use the recorded swap 
    yield swapMapValueOrKey( randomIndex )

    // set the swap map at the selected random index
    // unless there is a recorded swap to use instead
    swapMap.set( randomIndex, swapMapValueOrKey( pointerIndex ) )

    // we will no longer need the recorded swap at the
    // current pointer
    if( swapMap.get( pointerIndex )) {
      swapMap.delete( pointerIndex )
    } 

  }
}

For good measure, here is a Python version as well. The Python language is well suited for expressing algorithms, often reading like pseudo-code.

import random

# Helpers
def dict_value_or_key( dict, key ): 
  return dict[ key ] if key in dict else key

# Virtual Shuffle
def virtual_shuffle( max_length, quantity, seed = None ):
  # hash map to keeo track of swapped indexes
  swap_map = {}

  # optional seeding of random generator
  if( seed != None ): random.seed( seed )

  # quantity is bound to range
  if quantity > max_length: quantity = max_length
  if quantity < 0: quantity = 0

  # define range start/end points
  start = max_length - 1
  end = start - quantity

  # main algorithm
  for pointer_index in range( start, end, -1 ):
    random_index = random.randint( 0, pointer_index )

    # yield random_index unless swap_map has a swap value
    # in the that case, use the recorded swap value
    yield dict_value_or_key( swap_map, random_index )

    # set swap_map for the randomly selected index to
    # the current pointer_index unless swap_map has
    # a record swap, in that case, use the swap value
    swap_map[ random_index ] = dict_value_or_key( swap_map, pointer_index )

    # we will no longer need recorded swaps recorded
    # for the current index
    if pointer_index in swap_map:
      del swap_map[ pointer_index ]

Like Fisher-Yates, we pick a random number up to pointer_index where pointer_index starts at maximum value in our range and decrements down by one each iteration. For each cycle we do three key things:

yield either the random index we choose or the swap value if we find a mapping for the random index in our dictionary
record a mapping for the randomly selected index to the current pointer
delete a stored mappings for the current pointer, since all future iterations will be less than this value

A helper that really simplifies the code is dict_value_or_key. This is a function that looks up a key in a hash table / dictionary, and returns the value if the key is found; otherwise, it returns the key.

This method is capable of selecting the desired amount of numbers from all permutations (N!).

Conclusion

By using a hash map, we are able to simulate the Fisher-Yates algorithm, picking M elements in a range 0 to N with O(M) space and time complexity.

Lazy Recursion Using JavaScript Generators

Babak — Mon, 22 Jul 2019 07:43:31 +0000

Introduction

Generators and Iterators enable lazy evaluation in JavaScript. Used in a loop, for example, executions "pauses" at each yield statement until the next iteration is requested. What is often overlooked is that generators can be recursive functions. In this brief article, I'll go over a simple example that demonstrates how one can create a recursive generator function for lazy evaluation.

Yield

Most documentation on generators provide iterative examples, often using a while or for construct with a yield statement. For example, a simple generator that yields sequential numbers could be written like this:

function* count() {
  let count = 0
  while( true ) {
    yield count++
  }
}

Iteration is fine; but what about algorithms that are better expressed recursively? How can we use generators to create lazily evaluated recursive functions? We do this by delegating to another generator.

The yield* keyword (with asterisk)

Meet yield*, the lazier cousin of the yield statement. The yield statement pauses with the next value until requested. On the other hand, the yield* statement (with an asterisk) simply defers to another iterator object.

Evaluation doesn't actually stop at yield*, it is merely a syntax to indicate that we'll forward all yields from the given iterator object until it finishes--after which we resume. It turns out, this is quite powerful.

For our first example, let's suppose we want to loop over an iterable, endlessly. We could do this as follows:

function* loop( iterable ) {
  yield* iterable
  yield* loop( iterable )
}

For our second example, we'll look at a more concrete scenario--here is a function that generates array permutations using Heap's Permutation algorithm:

function* heapsPermutationsMutating( source, end = source.length  ) {
  // base case
  if( end === 1 ) { yield [ ... source ] }

  // branch
  for ( var index = 0; index < end; index++ ) {
    yield* heapsPermutationsMutating( source, end - 1 );
    swap( source, end - 1, end % 2 === 0 ? index : 0 )
  }
}

function* heapsPermutations( source ) {
  yield*  heapsPermutationsMutating( source )
}

function swap( arr, i1, i2 ) {
  return [ arr[ i1 ], arr[ i2 ] ] = [ arr[ i2 ], arr[ i1 ] ] 
}

Notice that we don't need to build and keep the resulting array because we yield each permutation and move on. The yield* keyword defers to the yield given in the base case reached at the end of each recursive branch.

This pattern works great for many recursive solutions. What makes the approach great in terms of space and time complexity is that we can stop execution after we get our desired result--we don't need to generate all permutations.

To illustrate this, here is a take generator function that we can use to only create a specific number of permutations.

function* take( num, iter ) {
  let item = iter.next()
  for( let index = 0; index < num && !item.done ; index++) {
    yield item.value
    item = iter.next()
  }
}

To take just the first 5 permutations of an array, we might do something like this:

let permutate5 = [ ...take( 5, heapsPermutations([1,2,3,4,5]) ) ]

Conclusion

Recursive lazy evaluation further improves JavaScript's functional capabilities. It shouldn't be overlooked! Many algorithms are expressed much more elegantly and naturally when written recursively. Recursive functions are just as capable of lazy evaluation as their iterative counterparts.

Dynamically Check Function Parameters Before Runtime

Babak — Mon, 29 Apr 2019 06:57:24 +0000

Prelude

Thanks to TypeScript's conditionals and self-referencing types; it is possible to instruct the compiler to make dynamic choices. This is what I mean by "dynamic"--of course, TypeScript is still a static compile-time type checker.

Introduction

In TypeScript, it is possible to restrict the value that can be assigned to a generic using extends however, there are limitations. In this article we will see how the we can use Type Aliases and the intersection operator & to enhance the kinds of limitations we can place on generics

On Generics

In TypeScript, generics enable us to express polymorphic functions, objects that deal with a variety of types, the return value of a function, and more. One could think of a generic as essentially a variable or a placeholder that is assigned to, so long as its not being widened in the process. By default, generics accept type {}, which is pretty much anything in JavaScript. For example:

declare function id<A>( a: A ) : A

Anything we provide variable a is going to be the type of generic A. But we can also restrict a generic before an assignment. Consider this map function:

declare function map<A, B, FN extends (a:A) => B>( xs: A[], fn: FN ) : B[]

The compiler will expect FN to be a function that takes an A to B. A and B can be anything; but FN has to be a function with an arity of one. This is because FN is already narrowed down to be a function of the given structure through the use of extends.

But there are limits to what we can do. What if, for example, we want to construct a merge function that statically checks that neither of two objects share any keys?

We might start by creating a Type Alias that returns shared keys between two objects:

type CommonKeys< A, B > = Extract<keyof A, keyof B>

But we can't do this:

type Validate<A,B> = CommonKeys<A,B> extends never ? B : never
// 🚫 Error, B has a circular constraint
declare function safeMerge< A, B extends Validate<A,B>>( 
  objA: A, 
  objB: B 
): A & B

B cannot reference itself when declared; and conditionals are not allowed in declarations anyway. So how do we go about this?

Intersections

To solve this problem, we observe that the intersection of any type with itself is itself; and with never it is always never. As such, we first assign the generic and then validate using an intersection. Let see how we can use this to construct a merge function that requires both objects to have unique keys:

type CommonKeys< A, B > = Extract< keyof A, keyof B > 
declare function safeMerge< A, B >( 
  objA: A, 
  objB: B & ( 
    CommonKeys<A,B> extends never 
      ? B // B & B is B
      : never // B & never is never
  ) 
): A & B

Does it work?

// 🚫 Error
const mergedObj = safeMerge( { a: 1 }, { a : 2, b: 3 } )

Good, we get a compiler error! Both objects overlap on key 'a', which we don't want to allow.

// ✅ Works!
const mergedObj = safeMerge( { a: 1 }, { b : 2 } )

It works! Neither object shares a key and our merge will not overwrite any key-value pairs.

The Validation Type Alias as a Pattern

This bit of type code requires us to think about what is happening here:

 B & ( 
    CommonKeys<A,B> extends never 
      ? B // B & B is B
      : never // B & never is never
  )

We can make this a bit more concise using three helpers:

type IsNever<T> = [T] extends [never] ? 1 : 0;
type WhenNever<Evaluate,Return> = IsNever<Evaluate> extends 1 ? Return : never
type WhenNotNever<Evaluate,Return> = IsNever<Evaluate> extends 1 ? never : Return

If you're curious as to why IsNever puts T inside of an array, it is to prevent union distribution. We want to see if T is never and not if its union may contain never. We'll use this test to determine if want to raise a compiler error or not.

For merge function, we'll want to create an error when A and B share keys. We don't want to allow keys to be overwritten. No common keys will result in never, which is what we want. So we'll construct our type helper as follows:

/**
 * Validates that keys in object A do not overlap with object B
 * return A if true and never if not.
 */
type ValidateKeysDontOverlap<A,B> = WhenNever< CommonKeys<A,B>, A >

We can tuck this away into a type validation library and follow a convention where all validating types start with Validate. Then we can use it like this:

declare function safeMerge< A, B >( 
  objA: A, 
  objB: B & ValidateKeysDontOverlap<B,A>
): A & B

A Validation Type Standard

It could be useful if this pattern were standardized around some convention. My personal thought at the moment is that a validation type should return the first parameter if valid and never if not. In this order because TypeScript type aliases can have optional generics, for example:

type Example<A,B = A> = ....

Here the second generic B will be set to A, if not passed. So at least the first parameter will be required. However, as far as I know, not a lot of people are talking about this yet and the range of use cases known to me are limited to my own.

Conclusion

TypeScript enables us to narrow down the range of what a generic can be within some limitations. We can overcome those limitations by intersecting a generic with a Type Alias which will statically compute complex situations and return the same type we are intersecting with or never if we want to cause the compiler to complain about the result of our static analysis.

To better communicate what we are doing, it might be useful to adopt some standard for this pattern. A type alias intended for this kind of pattern might start with the name Validate and return either the first parameter it requires or a type never otherwise.

Introducing The Recursive `Pipe` and `Compose` Types

Babak — Fri, 12 Apr 2019 01:05:26 +0000

It turns out, the recursive Pipe (and Compose) types offer key advantages over the traditional method of using parameter overloading. The key advantages are:

Preserve variable names
Better tolerance of generics in function signature
Variadic entry function
Can theoretically compose unlimited functions

In this article, we'll explore how such a Pipe and Compose type are built.

If you want to follow along with the full source at hand, see this repo:

https://github.com/babakness/pipe-and-compose-types

Introduction

My journey for this project starts as a challenge to create recursive Pipe and Compose types, without relying on overloads that rename the parameters. To review an example of how to build this with overloads follow one of these links to the excellent library fp-ts by @gcanti

Pipe:

https://github.com/gcanti/fp-ts/blob/master/src/function.ts#L222

Compose:

https://github.com/gcanti/fp-ts/blob/master/src/function.ts#L160

I've used this strategy in my own projects. Parameter names are lost and are replaced, in this case, with alphabetic names like a and b.

TypeScript shares its ecosystem with JavaScript. Because JavaScript lacks types, parameter names can be especially helpful in guiding usage.

Let's look at how these types work a bit closer.

Make a Recursive Pipe Type

First, we're going to need some helper types. These are going to extract information from a generic function:



export type ExtractFunctionArguments<Fn> = Fn extends  ( ...args: infer P ) => any  ? P : never
export type ExtractFunctionReturnValue<Fn> = Fn extends  ( ...args: any[] ) => infer P  ? P : never

Next two more helpers, a simple type to allow us to branch different types predicated on the test type and a short hand for express any function.



type BooleanSwitch<Test, T = true, F = false> = Test extends true ? T : F
export type AnyFunction = ( ...args: any[] ) => any

This next type is really esoteric and ad-hoc:




type Arbitrary = 'It was 1554792354 seconds since Jan 01, 1970 when I wrote this' 
type IsAny<O, T = true, F = false> = Arbitrary extends O
  ? any extends O
    ? T
    : F
  : F

Essentially, this type detects any and unknown. It gets confused on {}. At any rate, it isn't exported and intended for internal use.

With those helpers in place, here is the type Pipe:



type Pipe<Fns extends any[], IsPipe = true, PreviousFunction = void, InitalParams extends any[] = any[], ReturnType = any> = {
  'next': ( ( ..._: Fns ) => any ) extends ( ( _: infer First, ..._1: infer Next ) => any )
    ? PreviousFunction extends void
        ? Pipe<Next, IsPipe, First, ExtractFunctionArguments<First>, ExtractFunctionReturnValue<First> >
        : ReturnType extends ExtractFunctionArguments<First>[0]
          ? Pipe<Next, IsPipe, First, InitalParams, ExtractFunctionReturnValue<First> >
          : IsAny<ReturnType> extends true
            ? Pipe<Next, IsPipe, First, InitalParams, ExtractFunctionReturnValue<First> >
            : {
              ERROR: ['Return type ', ReturnType , 'does comply with the input of', ExtractFunctionArguments<First>[0]],
              POSITION: ['Position of problem for input arguments is at', Fns['length'], 'from the', BooleanSwitch<IsPipe, 'end', 'beginning'> , 'and the output of function to the ', BooleanSwitch<IsPipe, 'left', 'right'>],
            }
    : never
  'done': ( ...args: InitalParams ) => ReturnType,
}[
  Fns extends []
    ? 'done'
    : 'next'
]

This type goes through a series of steps, it starts by iterating through each function, starting at the head and recursively passing the tail end to the next iteration. The key to making this work is to extract and separate first item in the array of functions from the rest using this technique:



( ( ..._: Fns ) => any ) extends ( ( _: infer First, ..._1: infer Next ) => any )

If we didn't do error checks, we could distill this next part as simply



PreviousFunction extends void
        ? Pipe<Next, IsPipe, First, ExtractFunctionArguments<First>, ExtractFunctionReturnValue<First> >
        : Pipe<Next, IsPipe, First, InitalParams, ExtractFunctionReturnValue<First> >

PreviousFunction is void only on the first iteration. In that case we extract the initial parameters. We pass InitialParams back in each iteration with the last functions return type. Once we exhaust all functions in the list, this part



 Fns extends []
    ? 'done'
    : 'next'

returns done and we can return a new function made up of the initial parameters and the last return type



'done': ( ...args: InitalParams ) => ReturnType,

The other bits are error detection. If it detects an error, it will return custom object which will point to the count were the error occurred. In other words, it has built-in error reporting.

I learned about this technique studying other people's libraries. One notable example is typescript-tuple which we use later to construct Compose

Alright now let's create an alias for the pipe function itself



type PipeFn = <Fns extends [AnyFunction, ...AnyFunction[]] >( 
  ...fns: Fns & 
    Pipe<Fns> extends AnyFunction 
      ? Fns 
      : never 
) =>  Pipe<Fns>

Here is another technique to illustrate. When our Pipe function return that helpful error object, we want to actually raise a compiler error too. We do this by joining the matched type for fns conditionally to either itself or never. The later condition creating the error.

Finally, we're ready to define pipe.

I do this in a different project, not only in a different file in the same project. I do this for two reasons:

First, I want to separate the implementation from the type. You're free to use these types without potentially including any JavaScript.

Second, once the type has compiled correctly, I want to separate the pros and cons of future TypeScript versions from the type and implementation.

Implementing The Pipe Function



export const pipe: PipeFn =  ( entry: AnyFunction, ...funcs: Function1[] ) =>  ( 
  ( ...arg: unknown[] ) => funcs.reduce( 
    ( acc, item ) => item.call( item, acc ), entry( ...arg ) 
  ) 
)

Let see it work:



const average = pipe(
  ( xs: number[]) => ( [sum(xs), xs.length] ),
  ( [ total, length ] ) => total / length
)

✅ We see average has the right type (xs: number[]) => string and parameter names are preserved.

Let's try another example:



const intersparse = pipe( 
  ( text: string, value: string ): [string[], string] => ([ text.split(''), value ]),
  ( [chars, value]: [ string[], string ] ) => chars.join( value )
)

✅ Both parameter names are preserved (text: string, value: string) => string

Let's try a variadic example:



const longerWord = ( word1: string, word2: string ) => (
  word1.length > word2.length 
    ? word1 
    : word2
)
const longestWord = ( word: string, ...words: string[]) => (
  [word,...words].reduce( longerWord, '' )
)

const length = ( xs: string | unknown[] ) => xs.length

const longestWordLength = pipe(
  longestWord,
  length,
)

✅ Parameter names and types check, the type for longestNameLength is (word: string, ...words: string[]) => number

Great!

Compose

It turns out we can do this for Compose very easily. The helper we need we'll use from typescript-tuple.



import { Reverse } from 'typescript-tuple'
export type Compose<Fns extends any[]> = Pipe<Reverse<Fns>, false>
export type ComposeFn = <Fns extends [AnyFunction, ...AnyFunction[]] >( 
  ...fns: Fns & 
    Compose<Fns> extends AnyFunction 
      ? Fns 
      : never 
) =>  Compose<Fns>

The implementation is only slightly different



import { ComposeFn } from 'pipe-and-compose-types'
export const compose: ComposeFn = ( first: Function1, ...funcs:  AnyFunction[] ): any => {
  /* `any` is used as return type because on compile error we present an object, 
      which will not match this */
  return ( ...arg: unknown[] ) => init( [first, ...funcs] ).reduceRight( 
    (acc, item) => item.call( item, acc ), last(funcs)( ...arg ) 
  )
}

Let's put our new compose to the test:



const longestWordComposeEdition = compose(
  length,
  longestWord,
)

✅ Parameter names and types check, the type for longestNameLength is (word: string, ...words: string[]) => number

Closing

I encourage you to take a look at this repo to review the types

https://github.com/babakness/pipe-and-compose-types

to import the types into your own project, install using:

npm install pipe-and-compose-types

Also look at two great application of these types

https://github.com/babakness/pipe-and-compose

import these functions into your project using

npm install pipe-and-compose

Please share your thought! Feel free to reach out to me on Twitter as well!

Exhaustive Type Checking with TypeScript!

Babak — Mon, 08 Apr 2019 09:31:10 +0000

Introduction

Wouldn't it be great if you could spot a bug the moment you wrote it down? That's what static type analysis is all about. Catch your bugs at compile-time as you type them. This is why TypeScript is such a major productivity booster; especially at the strictest setting.

TypeScript is designed to be a superset of JavaScript, which is why certain features have to be unlocked through patterns and principals. One such great feature is Exhaustiveness Checking.

In short, Exhaustive Type Checking is when your static compiler checks that you're not leaving a possibility unchecked. It helps to think about how null checking works.



function test(x: string | null) {
    if (x === null) {
        return;
    }
    x; // type of x is string in remainder of function
}

The function test above accepts a parameter x which can be either a string or null. Notice that below the if block with the return statement, TypeScript knows that x can now only be string.

If we now add another if block for the case when x is of type string:



function test(x: string | null) {
  if (x === null) {
    return
  }
  if (typeof x === 'string') {
    return;
  }
  x; // type of x is never the remainder of the function
}

Then x below that block is of type never. All possibilities for x have been exhausted. We're now ready to discuss exhaustiveness checks.

Exhaustive Type Checking

TypeScript supports literal values as types. Suppose we have a function makeDessert that takes a fruit of type Fruit and returns a string value to represent the name of the dessert made.



type Fruit = 'banana' | 'orange'
function makeDessert( fruit: Fruit ) {
  // make dessert from type Fruit
}

How do we get compiler to insure we've covered all possible values for fruit inside the makeDessert function?

We start by checking all possibly values:



type Fruit = 'banana' | 'orange'
function makeDessert( fruit: Fruit ) {
  switch( fruit ) {
    case 'banana': return 'Banana Shake'
    case 'orange': return 'Orange Juice'
  }
  x // x has type never here
}

Since we've checked for both banana and orange, x has a type never at the bottom of this switch statement. Now we want to insure this.

From here, there are two ways to do this. The first is to specify the return type of the function



function makeDessert( fruit: Fruit ): string {
  switch( fruit ) {
    case 'banana': return 'Banana Shake'
    case 'orange': return 'Orange Juice'
  }
}

Because we specify the return type, the compiler will let us know if we are not handling a specific case. However, currently, this benefit goes away if the want to throw below the switch statement. TypeScript will assume that never is an acceptable return situation. It may be important to handle situations where the income type is any and does not match our cases.

The second way--to use a function that only accept a parameter of type never, which is what x is at the bottom of the switch statement. That way, if the type Fruit changes, x will no longer be of type never. That would trigger a compiler error and just like that, we have exhaustiveness checking powered by the compiler.

Let's look at this:



type Fruit = 'banana' | 'orange'

function exhaustiveCheck( param: never ) { }

function makeDessert( fruit: Fruit ) {
  switch( fruit ) {
    case 'banana': return 'Banana Shake'
    case 'orange': return 'Orange Juice'
  }
  exhaustiveCheck( fruit ) // ✅ no error
}

Now if Fruit included a value mango, we would receive a compiler error, informing us that fruit at the bottom of the switch statement can be mango.



type Fruit = 'banana' | 'orange' | 'mango'

function exhaustiveCheck( param: never ) { }

function makeDessert( fruit: Fruit ) {
  switch( fruit ) {
    case 'banana': return 'Banana Shake'
    case 'orange': return 'Orange Juice'
  }
  exhaustiveCheck( fruit ) // 🚫 ERROR! `mango` is not assignable to type `never`
}

To fix this error, we have to handle mango as a possible value



type Fruit = 'banana' | 'orange' | 'mango'

function exhaustiveCheck( param: never ) { }

function makeDessert( fruit: Fruit ) {
  switch( fruit ) {
    case 'banana': return 'Banana Shake'
    case 'orange': return 'Orange Juice'
    case 'mango' : return 'Mango Smoothie'
  }
  exhaustiveCheck( fruit ) // ✅ no error, all values handled.
}

Finally, just in case, we should protect ourselves against the possibility the value for fruit being any, which turns off type checking and allows any value to pass into makeDessert. We do this by throwing an error in the exhaustiveCheck function:



function exhaustiveCheck( param: never ): never { 
  throw new Error( 'should not reach here' )
}

This solution is outlined in this StackOverflow issue:

https://stackoverflow.com/questions/39419170/how-do-i-check-that-a-switch-block-is-exhaustive-in-typescript

Can we achieve Exhaustiveness Checking in TypeScript in a less verbose way? A more functional way?

Yes and yes! 😅

Helper Library

I've put together a helper library

https://github.com/babakness/exhaustive-type-checking

Along with a full video tutorial 🎬

To highlight an example, we can create makeDessert as follows:



const makeFruit = matchConfig<Fruit>()
const makeDessert = match({
  banana: () => 'Banana Shake'
  orange: () => 'Orange Juice'
  mango: () => 'Mango Smoothie'
})

This pattern offers a more compose-able way to do exhaustive checking with the same auto-complete goodness the switch pattern enjoyed.

Conclusion

Exhaustiveness checks can really help cut-down runtime bugs. Indeed, even with Test-Driven Development, if we never the write code to handle a situation, our code coverage statistics wouldn't reflect that we didn't test for it either.

Enjoy and feel free to visit me on Twitter and on my new YouTube Channel

How To Simplifiy Code By Removing Variables

Babak — Thu, 21 Mar 2019 09:12:35 +0000

Have you ever found yourself doing something that looks similar to this pattern?

const userInfoFromStorage = localStorage.getItem('userInfo')
const userInfoParsed = JSON.parse(userInfoFromStorage)
const userInfoClearedCache = { ...userInfoParsed, cache: {} }  
return userInfoClearedCache

Lots of use-once temporary variables. I used to do this too. I'd come up with creative ways to name those variables to sort of "self-document" what was happening. But it's generally a bad idea, here are some reasons why:

The more variables you create, the more likely you are to have a typo.
The operations performed on the data are surrounded by a lot of syntax noise.
Variable names don't take the place of comments.
Naming needless variables is an unnecessary mental load.

There are only two hard things in Computer Science: cache invalidation and naming things.

-- Phil Karlton

But what should we do instead? Clearly this isn't going to be easy code to work with:

return {
  ...( 
    JSON.parse( 
      localStorage.getItem(
        'userInfo'
      )
    )
  ),
  cache: {}
}

Yikes! 😲

While ugly, the code above does show that it is possible to express this transformation as a series of function calls with no variables. The output of one function is the input of the next function, and so on. We want to pipe values between functions. One solution is to write a function that allows us to make this abstraction. So how do we do this?

Here is one solution using reduce:

const pipeline = ( initialValue, ...fns ) => (
  fns.reduce( 
    ( val, fn ) => fn( val ), 
    initialValue 
  )
)

As you can see, this function takes an initialValue and uses reduce to feed the output of one function into the input of the next one. If you are not sure why I use reduce here, part I of my reduce tutorial may be helpful. Now we can refactor the original code like so:


return pipeline(
  // get user information stored as a string in local storage
  localStorage.getItem('userInfo'),
  // parse the string
  JSON.parse,
  // reset the cache to an empty obj
  obj => ({ ...obj, cache: {} })
)

Isn't this much cleaner? It is easy to see how data flows from top to bottom.

There are two common challenges some developers may have with this style:

Types. How do you type a pipeline function?
Logging (for debugging). How do you log data between the pipeline chain?

We will address these questions here:

The Typed Version

There is a way to express this function using a self-referencing type, but that is complex and warrants a separate article. For those who are curious, this is what such a type would more or less look like:

https://github.com/babakness/soultrain/blob/v0.0.43/src/type/_experiements.ts#L18

Alternatively, we can simply use TypeScript's function overloading to express how the type should evolve. For example:

function pipeline<A,B>( a: A,  ab: (a: A) => B ): B
function pipeline<A,B,C>( a: A,  ab: (a: A) => B, bc: (a: B) => C ): C
function pipeline<A,B,C,D>( a: A, ab: (a: A) => B, bc: (a: B) => C, cd: (c: C) => D):D
// and so on

This is essentially how pipeline works in my library Soultrain.

babakness / soultrain

Soultrain is a compact functional library written in Typescript.

Please note that this library is still experimental and there will be breaking changes. If you are kicking the tires on this within another experimental project, it is best to lock it down to a specific version.

Install

npm install soultrain

Soultrain

Soultrain is a compact functional library written in Typescript. It is inspired by Ramda and container-style programming based Algebraic Data Types.

Motivation

Ramda is a great tool, however, it relies on JS DOC comment specifications to provide type data. While this is good, Typescript provides superior static-typing. Thus this library aims to provide general purposes functional tools with much better static-typing.

Overview

This section will be completed later. From a high-level, the library provides smart curry, pipe, and pipeline functions with good type support. It currently provides two Monads, a Maybe and a Transduce. The former works similar to other Maybe libraries, however, it provides…

View on GitHub

The benefit of the typed version is getting the compiler to double-check the code. Here is an example that the JavaScript version would not catch:

The compiler has noticed that roo is not a property on the object returned by processor.process

Logging / Debugging

To log data flowing between the functions in the pipeline, one could simply use a log function that both logs and returns the data it receives. With types it could be written as such:

const log = <A>(data: A): A => (console.log(data),data)

Or, to log with a message one could define log like this:

const noteLog = (note: unknown) => (
  <A>(data: A): A => ( console.log(note, data), data )
)

Which can be used thus:

return pipeline(
  // get user information stored as a string in local storage
  localStorage.getItem('userInfo'),
  // parse the string
  JSON.parse,
  // log the data,
  noteLog('data before cache removal'),
  // reset the cache to an empty obj
  obj => ({ ...obj, cache: {} })
)

As an exercise for the reader, one could also create a function that conditionally triggers the debugger.

Functional Programming

The pipeline function, the eager sibling of pipe and compose, will invite you to write more functions. It will also demonstrate to you how powerful currying can be; and even inform you on the order your function parameters should be.

To illustrate this, notice the arrow function in our pipeline example. Isn't obj a single-use variable? All we're using it for is as a placeholder for our data... just a few character to the right!

Turns out that by making sure our source data is the last parameter and by using curried functions, we can simplify our code even further. Below I've written how this could be expressed in vanilla JS--notice that we want to override keys for the incoming object. It will be the second parameter--thus moving from left to right, overriding the second object, obj2, with the object in the first parameter, obj1.

So instead of placing obj2 to the right of the object spread, we reverse the order and place it on the left:

const mergeLeft = curry( 
  // spread the second parameter first
  ( obj1, obj2 ) => ({ ...obj2, ...obj1 })
)

If you're unfamiliar with curry, it basically modifies our function so that it can be used as if it were also written this way:

const mergeLeft = obj1 => obj2 => ({ ...obj2, ...obj1 })

Now our solution becomes:

return pipeline(
  // get user information stored as a string in local storage
  localStorage.getItem('userInfo'),
  // parse the string
  JSON.parse,
  // log the data,
  noteLog('data before cache removal'),
  // reset the cache to an empty obj
  mergeLeft({ cache: {} })
)

Piping encourages us to write small, re-usable functions that perform specific tasks and that take the source data as the last parameter. This is similar to commands on the UNIX or Linux terminal. It's a functional programming concept that has been around for a long time. And like a great classic, it is a principle that proves itself better with time.

ES-Next

Piping data between functions is a great alternative to creating single-use variables which are only used to pass data from one function to another. Many programming languages recognize this and have an operator to perform this task. For JavaScript, there is the proposed pipeline operator

tc39 / proposal-pipeline-operator

A proposal for adding a useful pipe operator to JavaScript.

Pipe Operator (`|>`) for JavaScript

Stage: 2
Champions: J. S. Choi, James DiGioia, Ron Buckton, Tab Atkins-Bittner, [list incomplete]
Former champions: Daniel Ehrenberg
Specification
Contributing guidelines
Proposal history
Babel plugin: Implemented in v7.15. See Babel documentation.

(This document uses % as the placeholder token for the topic reference This will almost certainly not be the final choice see the token bikeshedding discussion for details.)

Why a pipe operator

In the State of JS 2020 survey, the fourth top answer to “What do you feel is currently missing from JavaScript?” was a pipe operator. Why?

When we perform consecutive operations (e.g., function calls) on a value in JavaScript, there are currently two fundamental styles:

passing the value as an argument to the operation (nesting the operations if there are multiple operations),
or calling the function as a method on the…

View on GitHub

Which would allow us to rewrite our original example like this:

return (
 // get user information stored as a string in local storage
 localStorage.getItem('userInfo'),
  // parse the string
  |> JSON.parse
  // reset the cache to an empty obj
  |> obj => ({ ...obj, cache: {} })
)

Until then, we can benefit from using the pipeline function today to avoid unnecessary variable declarations.

How to run VS Code on the server!

Babak — Mon, 11 Mar 2019 07:23:33 +0000

VS Code is my favorite editor for web development. The integrated terminal, the great plugin ecosystem, debugger, and excellent TypeScript support make it just perfect. Its one reason I keep coming back to developing locally. Because while I could run vim on the terminal and work remotely, I'm just not as productive in vim.

Of course there are other options. Cloud development is pretty great. Working on a project entirely remote on a browser is liberating. My project is always ready to be worked on, untethered from my machine. But cloud editors each have their own drawbacks. Ultimately, I want to drop into the terminal, start and stop services, and do all that I am able to do from my local machine. If only there was a way to run VS Code directly on a remote server, it would be the best of both worlds.

Well, now there is! Thanks to code-server by coder.com

coder / code-server

VS Code in the browser

code-server

Run VS Code on any machine anywhere and access it in the browser.

Highlights

Code on any device with a consistent development environment
Use cloud servers to speed up tests, compilations, downloads, and more
Preserve battery life when you're on the go; all intensive tasks run on your server

Requirements

See requirements for minimum specs, as well as instructions on how to set up a Google VM on which you can install code-server.

TL;DR: Linux machine with WebSockets enabled, 1 GB RAM, and 2 vCPUs

Getting started

There are four ways to get started:

Using the install script, which automates most of the process. The script uses the system package manager if possible.
Manually installing code-server
Deploy code-server to your team with coder/coder
Using our one-click buttons and guides to deploy code-server to a cloud provider ⚡

If you use the install script, you can preview what occurs…

View on GitHub

Getting started

To get started, you'll need to log into your remote development server. This can be something like a Droplet from Digital Ocean, an AWS Lightsail instance, or any other cloud or internet connected server one would want to use. ssh access is needed.

One could then log into the remote server and either run code-server in docker or just use one of their binary releases. I used the the binary distribution for my purposes

https://github.com/codercom/code-server/releases

Here is an example of how that might go



mkdir ~/code-server
wget -qO- LINK_TO_DESIRED_BINARY \
  | tar xvz --strip-components=1 -C ~/code-server

The code-server binary comes with a few options. At the time of this writing, it seems that the application had some trouble when given a relative paths on my system. So I wrote a super simple wrapper around it in bash, decided to call it code and place that in ~/bin which is my PATH variable.

vim ~/bin/code



#!/usr/bin/env bash
abs=$(realpath .)
req=$1
if [[ ! $1 =~ ^\/ ]];
then
  req="$abs/$1"
fi;

if [[ ! -d $req ]];
then
  echo "ERROR: path does not exist"
  echo "$req"
  exit;
fi;

~/code-server/code-server $req --no-auth

chmod +x ~/bin/code

This script starts code-server with the no-auth option. The no-auth option disables the built-in encryption functionality and the password authentication page. I do this because I would rather encrypt the traffic through a proxy server or through a SSH tunnel. I can also password protect the page using the web server that proxies connections.

Now to start the server, I simply open a project similar to how I would with VS Code directly.

code /path/to/project

This will start serving VS Code over port 8443. There are two ways to connect to it; either through an SSH tunnel or by using a web server reverse proxy.

SSH Tunneling / Port Forwarding

You can forward a remote port from the server to your local client by using SSH. Here is how it would look to format port 8443 from the server to your local machine.



ssh -N -L 0.0.0.0:8443:localhost:8443 login@your-server \
  2> /dev/null

This command won't give you the remote shell, it will just do the port forwarding. Now you can open your browser and visit http://localhost:8443. Behold! You are now using VS Code, running on your server, from your browser!

What is pretty incredible is that you have access to the terminal as well! This is very powerful stuff--so beware!

One final piece is to proxy any other running services on unprivileged ports, like port 3000 or 8080. One way to do this is by opening another terminal and making another connection.



ssh -N -L0.0.0.0:3000:localhost:3000 login@your-server \
  2> /dev/null

Or proxy both ports at once



ssh -N \
  -L 0.0.0.0:8443:localhost:8443 \
  -L 0.0.0.0:3000:localhost:3000 \
  login@your-server \
  2> /dev/null

Web Server Reverse Proxy

Note: this option is for if you want to handle encryption and password protection yourself.




BE SURE TO ENCRYPT AND PASSWORD PROTECT PUBLIC URLS.

Correctly setting up a reverse proxy through a web server is a more involved process. I will provide only an overview of what you need to make this work.

Make sure you have an SSL certificate. You can get one using certbot by Let's Encrypt.
Configure a web server to create reverse proxy between port 8443 and your desired URL. Be sure to proxy websocket traffic as well.
Password protect access to the URL

In my case, I also want to proxy services running for development purposes, like port 3000 or 8080.

APACHE

You'll need to ensure that the proper modules are loaded



sudo a2enmod rewrite

Then a configuration might be something that starts like this



<VirtualHost ip_address:443>

  # Enable Modules

  RewriteEngine On

  SSLEngine On

# Configure basics

  ServerName your.address

  ServerAdmin whoever@your.address

# Proxy Traffic

  RewriteCond %{HTTP:Upgrade} =websocket

  RewriteRule /(.)           ws://localhost:8443/$1 [P,L]

  RewriteCond %{HTTP:Upgrade} !=websocket

  RewriteRule /(.)           http://localhost:8443/$1 [P,L]

# Require Password

  AuthUserFile /path/to/.htpasswd

  AuthGroupFile /dev/null

  AuthName "Title"

  AuthType Basic

  require valid-user

# Use SSL

  Include /etc/letsencrypt/options-ssl-apache.conf

  SSLCertificateFile /etc/letsencrypt/live/yourwebsite.com/fullchain.pem

  SSLCertificateKeyFile /etc/letsencrypt/live/yourwebsite.com/privkey.pem

SSLProtocol all

  SSLCipherSuite HIGH:MEDIUM

  # And so on...

NGINX

I've not tried doing this for code-server with NGINX yet. NGINX is particularly apt for this. Here are some references on where I would start:

Encrypt traffic and reverse proxy w/ websockets
https://gist.github.com/steve-ng/ed6de1fa702ef70bd6ce

Password protect
https://www.digitalocean.com/community/tutorials/how-to-set-up-password-authentication-with-nginx-on-ubuntu-14-04

Other options

Let `code-server` handle its own encryption

Another option is to not include the --no-auth option and let code-server do its thing. Here is a resource for more information on this would work on Digital Ocean

https://github.com/codercom/code-server/blob/master/doc/admin/install/digitalocean.md

Use coder.com

I should also mention that coder.com has a cloud service for this.

https://www.coder.com

Overview

Running VS Code on the cloud untethers the developer from their workstation. One could install their plugins, configure the editor to their liking, and work directly from the could. The environment is always there, ready to go.

4 reasons why you won't regret using a type system

Babak — Sat, 09 Mar 2019 09:04:52 +0000

To type or not to type

The debate on the benefits and limitations of type systems is ongoing and there are legitimate points on both side. In this article, I will explore a few benefits I've personally experienced from using type systems.

Refactoring - I'm always aiming to reduce complexity. It is a popular notion that it takes work express an idea concisely. So, when you're paying off technical debt, a type system can help tremendously. When the workings of some functionality or process is spread across many different files, libraries, and/or components, type systems are a boon.
Composition - writing unit tests is great practice. A type system can go further and test how different units compose and come together. In the example below, all the functions are working fine; the problem lies in our use of them. We are accessing a property that doesn't exist--thankfully, this well typed pipeline function caught this right away.

pipeline from soultrain library https://github.com/babakness/soultrain/blob/v0.0.43/src/function/pipeline.ts
Runtime errors - it's better to have compile-time errors than runtime errors--especially if they're hard to catch! // Detect dark theme var iframe = document.getElementById('tweet-1103507850553257984-226'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1103507850553257984&theme=dark" }
Collaborating - between colleagues, teammates, library authors, or yourself from the past or in the future, I've found that a type system helps me understand how data is transformed, how events are handled, and what parameters a component expects.

Yet, type systems are not necessarily the right solution all the time. One common scenario I find myself leaving them out is when I'm teaching. Other times include when I'm prototyping or kicking the tires on some new library. It makes sense to just sketch something out and see what happens.

That said, the way I see it, for projects that can grow in complexity, there are more benefits to using them than not. The debate will go on, and there are other valid points against them.

To paraphrase Kierkegaard, use a type system or don't use a type system; you may still regret it. Hopefully I've given four good reasons on why you should use them, without regret! 😉

Why you should use reduce instead of loops -- Part I

Babak — Thu, 07 Mar 2019 08:28:15 +0000

Here is a common scenario: you want to iterate over all items in a list to produce new data. In this article, we'll discuss reduce and how and why you'll likely want to use it instead of loop constructs like for-of or while for situations like this. The examples are will be JavaScript and TypeScript. First, let's compare what the sight of each tells you when spotted in code:

Reduce

Reduce is about data transformations. At a glance, when you see a reduce, it communicates five key things

That data will be transformed into another type
What type the final data will be
What the i/o of the transforming function will be
That no side-effects will occur here
That no mutations will occur here

That a lot of communication!

Loops

Loops are general purpose constructs. They don't communicate that any kind of transformation is happening. Literally anything can happen in a loop, its all fair game. Change data, don't change data, launch rockets into outer space... whatever!

Show me the reduce!

You might be familiar with the method Array.prototype.reduce. Yet in JavaScript you might be working with many iterable things, not just arrays. Some examples of iterables include strings, Maps, and asynchronous streams!

I'm going to write down a general purpose reduce as an abstraction of the for-of loop. One that not only works with arrays but anything iterable in JavaScript. For good measure I'll write down both a TypeScript version and a pure JS version.

Here is the TypeScript version. Its typed so you'll get all that IntelliSense goodness with this one.



type Reducer<V, D> = ( acc: V, item: D, count: number ) => V

function reduce<V, D>(
    initialValue: V,
    reducer: Reducer<V, D>,
    data: Iterable<D>,
  ): V {
    let acc = initialValue
    let count = 0
    for ( const item of data ) {
      acc = reducer( acc, item, count++ )
    }
    return acc
}

Here is the plain old JS version.



function reduce(
    initialValue,
    reducer,
    data,
  ) {
    let acc = initialValue
    let count = 0
    for ( const item of data ) {
      acc = reducer( acc, item, count++ )
    }
    return acc
}

As you can see, our iterator reduce is just an abstraction of the for-of loop. Its also an abstraction on mutation--our reduce implementation does the dirty work of mutating the initial value over our data.

So, how does it work?

parameter	description
`initialValue`	first, you set the initial value, which will match the final type. Meaning if you set the the initialValue to `0`, then the return type will be a number. If you set it to `[]`, the final type will be an array.
`reducer`	a callback function that will take two parameters. the first parameter is called the "accumulator". The first call to our callback will set the accumulator to our `initialValue`, after that, it will be the value our reducer callback returned the previous time it was called. the second parameter will be set to the next iteration of iterable item. So, in the case of a string, it will start with the first character in the string, the move to the second, third, and so on. finally, the third parameter is simply the current position in iterating through our iterable. First call, the value will be zero, then one, and son on.
`data`	this is the data we want to process

Now let's solve some problems using both for loops and reduce

Write a function that returns the length of the longest word in a string.

First up, the way of the loop




function longestWordLength( str ) {
  const words = split( /\W+/g )
  let longestLength = 0
  for ( const word of words ) {
    longestLength = Math.max( longestLength, word.length )
  }
  return longestLength
}

Now let's look at how you would do this using reduce. First, we need to write down our reducer.



const longestWordLengthReducer = ( longestLength, word ) => {
  return Math.max( longestLength, word.length )
}

Then we provide our solution by declaring our initial value, reducer, and data.



const longestWordLength = str => reduce( 
    0, 
    longestWordLengthReducer, 
    str.split( /\W+/g )
)

Notice how the reduce API gives us the ability to quickly understand what this function will do. We know right away that the initialValue is set to a number. So we know the end data type is a number. Of course anything is possible is JS, but using the TypeScript version will help ensure this.

Also note that we've extracted the "business logic" of the loop, the part about how we find the largest word given the previous word length, into a separate, testable, function.

Using reduce, we've solved our problem by combining our reduce function with a reducer and a function that splits the string into words. We didn't explicitly have to write a loop. We can easily swap parts in and out to solve different problems.

With the for-of loop, we think about the solution iteratively.

With reduce, we think about the solution declaratively. We're writing more maintainable code.

Performance

Update: Thanks to Krzysztof Miemiec, I was able to catch an error in my loop implementation. The results are in fact neck-and-neck.

Let's dispel a few myths about the performance of reduce. This kind of programming is not only more maintainable, but it can be just as fast or faster! Our reduce here is just an abstraction over the for-of loop. Here you can see the benchmark results for two different runs. Very close.

Comparing our reduce and for-of examples
https://jsperf.com/loop-vs-iterator-reduce-corrected/1

Generally speaking, composing re-used and well tested functions is safer. Our functions are centralized--so if we improve them, our entire application improves with them. Functional programming promotes re-using your code.

So, using our example here, consider that if at some point in the future, instead of Math.max we find a faster way to determine the larger of two values. If we do, then all functions that compose this function also benefit.

Stay tuned

In the next article we'll develop these ideas further. Stay tuned, subscribe, and find me on Twitter at @babakness.

Forem: Babak

Learning Algorithms Through Games

Algorithm

Game Design

Vanilla JS

Useful functions

Play around!

Understanding recursion using iteration (or vice versa)

Introduction

The Stack

The Approach

How To Do It

The Code

The Recursive Ways

Bonus: Other Ways To Solve Recursively

Conclusion

Use the correct version of Node when starting VS Code terminal session using Fish

An algorithm for picking random numbers in a range without repetition

Introduction

The Algorithm

The Code

Conclusion

Lazy Recursion Using JavaScript Generators

Introduction

Yield

The yield* keyword (with asterisk)

Conclusion

Dynamically Check Function Parameters Before Runtime

Prelude

Introduction

On Generics

Intersections

The Validation Type Alias as a Pattern

A Validation Type Standard

Conclusion

Introducing The Recursive `Pipe` and `Compose` Types

Introduction

Make a Recursive Pipe Type

Implementing The Pipe Function

Compose

Closing

Exhaustive Type Checking with TypeScript!

Introduction

Exhaustive Type Checking

Helper Library

Conclusion

How To Simplifiy Code By Removing Variables

The Typed Version

babakness / soultrain

Soultrain is a compact functional library written in Typescript.

Install

Soultrain

Motivation

Overview

Logging / Debugging

Functional Programming

ES-Next

tc39 / proposal-pipeline-operator

A proposal for adding a useful pipe operator to JavaScript.

Pipe Operator (|>) for JavaScript

Why a pipe operator

How to run VS Code on the server!

coder / code-server

VS Code in the browser

code-server

Highlights

Requirements

Getting started

Getting started

SSH Tunneling / Port Forwarding

Web Server Reverse Proxy

APACHE

NGINX

Other options

Let code-server handle its own encryption

Use coder.com

Overview

4 reasons why you won't regret using a type system

To type or not to type

Why you should use reduce instead of loops -- Part I

Pipe Operator (`|>`) for JavaScript

Let `code-server` handle its own encryption