It's 4:30 on a Friday and GitHub hits you with one of these:

How do you make this go away and still get home on time? If GitHub's automated security fixes feels like admitting defeat or errors out on you, Yarn can make it easy.

If Github's vulnerability report looks like this:

And you don't depend on lodash directly (meaning it's a transitive dependency), an easy solution is to add a "resolutions" field to your package.json with the patched version within its semver range. So in this case our package.json would include these lines:

  "resolutions": {
    "lodash": "^4.17.13"
  },

Now if you run yarn, it'll update your yarn.lock file to force every transitive dependency to use the patched version instead. Afterwards, if you push up your new yarn.lock to GitHub, the warning will disappear. 🎉

A common pattern I use when writing TypeScript applications is creating default objects and overwriting some or all of those defaults with data provided by the user. But there's a common mistake when implementing this pattern that can be fixed with a little knowledge of TypeScript's built in utilities.

Implementation of the default pattern

Here's some code you might see in an app where ReadingListEntry objects are generated from a mix of defaults and user input, for example.

I like this pattern a lot, and it's especially good as the complexity of data in an application scales up. When objects have many fields or when users have multiple ways of creating data entries, centralizing defaults like this reduces a lot of boilerplate code (especially when combined with the Stage 4 object spread operator). And when things go wrong, it makes finding the culprit a lot easier.

But there's a problem with the way we're setting our defaults. To satisfy the TypeScript compiler, the default reading list entry's createdOn and id properties are set to unusable values. It may not seem like a big deal because we can see that those fields are always being overwritten with data from the user. But say we call generateReadingListEntry and forget to overwrite the default id value? The compiler wouldn't tell us about our mistake and our application would fail silently.

A mistake like this can and should be caught at compile time. Otherwise, this could end in a poor user experience at best or be catastrophic to the integrity of the user's data at worst.

'Pick' to the rescue

The best way to architect this pattern is to declare which properties of the ReadingListEntry object are safe to leave as default values and which ones we should always make sure to set manually when creating a ReadingListEntry object.

Fortunately, TypeScript has built in tools to make this possible. We can remove the id and createdOn properties of defaultReadingList and instead of annotating it as a full ReadingListEntry we can use TypeScript's Pick type to declare which properties of ReadingListEntry it has.

Now, if we use defaultReadingList to create ReadingListEntry objects, the TypeScript compiler will throw an error when we forget to manually set the missing properties.

We can even add a bit of expressiveness by giving the keys we're Picking a name:

In my experience with TypeScript's mapped types Pick has proven to be the most useful. It allows for creating type-safe partial slices of objects without needing to rely on TypeScript's inferencing or a complex naming strategy.

The problem

You've written your create-react-app application using absolute imports resolved from e.g. a folder named src but when you run your tests you get a message like this:

The explanation

You may have configured Webpack or the TypeScript compiler to resolve absolute imports from the src folder but Jest doesn't yet know about that configuration.

You can tell Jest about your absolute import resolution strategy by passing another option to the default create-react-app test script. Specifically, it's Jest's modulePaths option that makes this possible.

The solution

To use Jest's modulePaths option, add --modulePaths=src to the end of the test script in your package.json. If your imports resolve from the src folder, for example, you would change the script to this:

Although the image above shows the option being passed to react-scripts-ts it should work for regular react-scripts as well. Now if you run your tests Jest is able to resolve your absolute imports.

Understanding FileReader

The FileReader API is event driven. You define custom behavior in its event handlers when it either succeeds or fails to read a file and then pass a File object to one of the methods, such as readAsText The result of the method, if successful, can finally be retrieved in the .result property.

The FileReader methods work asynchronously but don't return a Promise. And attempting to retrieve the result immediately after calling a method will not work, as the .onload event handler fires only after the FileReader has successfully finished reading the file and updates the FileReader's .result property. This can make FileReader a bit of a pain to work with when integrating it with an application.

Wrapping it With a Promise

A solution to make FileReader more pleasant to work with is to wrap its result in a Promise. Here's an example:

This function returns a Promise of a string that will resolve or reject only after the firing of the .onload and .onerror event handlers, respectively. If the Promise is rejected the FileReader will abort and, in this case, return a custom DOMException but you can reject with whatever you like. One good alternative is the FileReader's .error property, which will also be a DOMException.

A Simplified API with Async/Await

Wrapping the result of a FileReader in a Promise allows us to await the result of our readUploadedFileAsText function and expect a string. Here's an example onchange handler we could pass to a <input type="file /> element (Full example on CodePen)

React Examples

The CodePen link above shows the above code doing manual DOM manipulation. Here's an example of using the same readUploadedFileAsText function with async/await in a React application.

For an example in a TypeScript and React application, look here. Though this particular code example is part of an application using Redux so there's a fair bit of indirection.

The usual pattern for rendering lists of components often ends with delegating all of the responsibilities of each child component to the entire list container component. But with a few optimizations, we can make a change in a child component not cause the parent component to re-render.

Let's make a list of React components go from this:

To this:

To be clear, the first example above doesn't actually cause wasted re-renders, according to react-addons-perf.

We'll be using TypeScript (for clarity and clearly defining what data our components receive) and Immutable.js. The source code of the finished app is available on github and a live demo is available here.

The problem

Let's imagine that we're building a website to list animals for adoption, and that each animal looks like this:

export interface Animal {
  readonly id: string;
  readonly name: string;
  readonly adopted: boolean;
  readonly type: 'Cat' | 'Dog';
}

Consider this react-redux implementation of rendering a list of DOM elements to display animals for adoption. The important stuff is in the Props and Handlers interfaces.

We get most of what we need to know from the Props and Handlers interfaces: AnimalTable accepts an immutable map of Animals. We see in the mapState function that it gets that data from subscribing to the store's animal property. It also receives the dispatching function to toggle an animal's adopted property (which we'll just trust is implemented properly, since it doesn't matter for this example).

In AnimalTable's render method, for each of the animals in the Animal Map it renders an AnimalListing, passing it the toggleStatus action creator and an Animal. We can guess that an AnimalListing will contain a button to invoke toggleStatus and will display the information specific to its animal.

To summarize, AnimalTable does a lot. Without even looking at the code for AnimalListing we can guess at everything it does because AnimalTable is responsible for all of the functionality of each AnimalListing. AnimalTable doesn't even do anything with the callback its passed in, it only passes it along to each AnimalListing. And does it really need the entire map of animals, complete with the entire Animal object?

We can simplify this massively. Each AnimalListing can be a connected react-redux component that subscribes only to one particular animal. But how do we know which animal to give to which AnimalListing? The key is in the second, optional argument that can be passed in to the first argument of connect (which is idiomatically called mapStateToProps). The second argument of mapStateToProps are the props that the parent of a component passes down to a connected component, which we can call OwnProps.

Connecting individual AnimalListings

If AnimalTable passes down just an id to each AnimalListing, AnimalListing could use that id to subscribe to a specific animal in the store. Let's look at an AnimalListing that implements this pattern:

The important part here are the Props and OwnProps interfaces, and the mapState function. When mapState is called on an AnimalListing, AnimalListing already has the id that AnimalTable gives it, and we use that id to assign it a specific Animal.

Also notice that we were able to move the action that dispatches toggleAdoption to the component that actually uses it, AnimalListing.

Fixing AnimalTable

With this pattern, AnimalTable really only needs an array of ids, so it could look like this:

Now AnimalTable receives just an immutable List of strings, which are animalIds it passes down to each AnimalListing. The only problem here is that we're doing a lot of logic in our mapState function, which we'll solve in the next section.

Adding reselect

To hide the logic we're now implementing in AnimalTable's mapState function, we can use the ultra-light reselect library.

// src/selectors.ts

import { createSelector } from 'reselect';
import { RootState, Animal } from './types';

const animalsSelector = (state: RootState) => state.animals;

export const animalIdsSelector = createSelector(
  [ animalsSelector ],
  (animals) => animals.map((animal: Animal) => animal.id).toList()
);

And now we can use it in AnimalTable's mapState:

import { animalIdsSelector } from '../selectors';

...

const mapState = (state: RootState): Props => ({
  animalIds: animalIdsSelector(state)
});
...

Although it isn't doing much in this example, reselect is a valuable tool when you start sorting, filtering, and otherwise manipulating data before you pass it to a component (here's an example from one of my own projects). And if a change in one selector doesn't change the result of another, your component won't re-render.

The final touch

At this point we have implemented everything we need to leverage immutable data structures to prevent re-rendering the entire AnimalTable when we adopt a single animal: a custom shouldComponentUpdate.

class AnimalTable extends React.Component<Props, never> {
  shouldComponentUpdate(nextProps: Props) {
    return !nextProps.animalIds.equals(this.props.animalIds);
  }
  ...

shouldComponentUpdate will return false if the props its receiving are equal to the props it already has. And because the AnimalTable is receiving just a List of string IDs, a change in the adoption status won't cause AnimalTable to receive a different set of IDs.

Serverless plugins make developing Lambda apps with TypeScript painless (no webpack required!)

This guide assumes you have TypeScript and Node installed as well as an AWS account. We'll be using serverless to set up our development environment and to package our app for deployment.

From mkdir to Deploy

Let's get the boring stuff out of the way first. We'll install serverless and configure our AWS credentials. After that we're ready for our first deploy.

First, let's install the serverless CLI:

npm i serverless -g

We can now generate the minimum deployable boilerplate for our app:

mkdir node-typescript-lambda && cd node-typescript-lambda
serverless create --template aws-nodejs

We now have a simple Lambda function in handlers.js and a serverless.yml which will tell serverless how to deploy our function to AWS.

Now let's configure our AWS credentials so we can deploy our function. If you already have an access key and secret access key in ~/.aws/credentials then you can skip this step. First, sign in to the AWS console. At the top right, click on your name to toggle the dropdown and navigate to "My Security Credentials. Then on the left navigation pane, click on "Users" and select a user with appropriate access. Click on the "Security credentials tab" to bring up the pane we're interested in. Under the section "Access keys" click "Create Acccess key"

Take note of the two keys you've generated and then run the following command in your terminal, replacing YOUR_ACCESS_KEY and YOUR_SECRET_KEY with their actual values.

serverless config credentials --provider aws --key YOUR_ACCESS_KEY --secret YOUR_SECRET_KEY

You can now choose to deploy with serverless deploy, but be warned this will count as a request made on your AWS account, and may incur a charge.

Serverless plugins

We're going to be using two serverless plugins. serverless-offline will allow us to test changes to our app locally. serverless-plugin-typescript will automatically compile our TypeScript files down to JavaScript both when we're developing locally and when we deploy our app.

To keep your deployment payload small, it's important to declare these plugins as dev dependencies, otherwise serverless will install them before deploying them, increasing your lambda function's size from <1kB to >30MB

npm init
npm i serverless-offline serverless-plugin-typescript --save-dev

We'll run our local environment with severless offline start but first we we need to edit serverless.yml to include the plugins we just installed.

Anywhere at the lowest indendation level in serverless.yml include these lines.

plugins:
  - serverless-plugin-typescript
  - serverless-offline

If you were to remove serverless-plugin-typescript you would be able to start your dev server, but we'll first need a tsconfig.json to tell the TypeScript compiler what to do. While we're at it, let's install the type definitions for aws-lambda.

tsc --init
npm i @types/aws-lambda --save-dev

You can configure your tsconfig.json to your personal preference, the only requirement is: "rootDir": "./" so that the compiler knows to look for .ts files in the current directory. If you choose to move all your .ts files to a new folder called ./src, for example, make sure to change the setting to "rootDir": "./src". You can also set "es6" as your compilation target because Lambda uses Node 6, which supports it. I've included a sample tsconfig.json here:

Adding Types

Our handler.js could use a makeover. Let's rename it to handlers.ts and run our development server with serverless offline start.

We'll first import the relevant types from 'aws-lambda' and then add types to each of the function's parameters as well as the response object.

import { Handler, Context, Callback } from 'aws-lambda';

interface HelloResponse {
  statusCode: number;
  body: string;
}

const hello: Handler = (event: any, context: Context, callback: Callback) => {
  const response: HelloResponse = {
    statusCode: 200,
    body: JSON.stringify({
      message: Math.floor(Math.random() * 10)
    })
  };

  callback(undefined, response);
};

export { hello }

With these type definitions, our editor will loudly warn us when we try to add a key that shouldn't exist and provide suggestions based off the type definitions.

We're almost ready to deploy this test function, but first let's exclude node_modules from our serverless.yml so we don't deploy aws-lambda and all of its dependencies.

Anywhere at the lowest indendation level of serverless.yml add the following lines:

package:
  exclude:
    - node_modules/**/*
  include:
    handler.ts

Making Our Lambda Function an Endpoint

By editing our serverless.yml once more, we can configure our Lambda function to be a visitable URL with AWS APIGateway.

functions:
  hello:
    handler: handler.hello

    events:
      - http:
          path: hello
          method: get

By adding the last four lines, we configure our hello Lambda function to expose the path /hello to an HTTP GET request. If we run serverless deploy now it will generate a URL that you can visit in your browser.

If you've ever looked at the syntax for sorting an array in JavaScript, you may have wondered how it works under the hood. The ECMAScript Spec is (intentionally, I would guess) vague about it.

Perform an implementation-dependent sequence of calls to the [[Get]] and [[Set]] internal methods of [...] - ECMAScript 2015 Specification

So it's up to the implementation authors. Got it. Let's first take a look at how to use the .sort method in JavaScript, then see how V8 chooses to implement it, and analyze its time and space complexity.

TL;DR

For arrays containing 10 or fewer elements, time complexity of .sort is O(n^2), and space complexity is O(1). For longer arrays time complexity is Θ(n log(n)) (average case), and space complexity is O(log(n))

Using .sort

.sort accepts an optional callback that takes 2 parameters and returns either a negative number, a positive number, or 0. The two parameters are the two elements of the array that are being compared. If the return value is positive, the first parameter is placed after the second. If it's negative, the first parameter is placed before the second. And if it's 0, they are equal. The callback will continually execute until the array is sorted. To make it less abstract, here's two examples.

const ascending = (a, b) => return a - b;

const descending = (a, b) => return b - a; 

The first function will sort an array from lowest value to highest, and the second function will sort an array from highest value to lowest. In .ascending, the expression (a - b) will evaluate to a positive number if a is greater than b, so the underlying sorting algorithm knows to put a after b. The opposite is true for the descending function. In both functions, 0 will be the return value if a and b are equal.

const x = [4,3,5,1,9,2,7,7,2] // Our initial unsorted array
x.sort(ascending) // => [1, 2, 2, 3, 4, 5, 7, 7, 9]
x.sort(descending) // => [9, 7, 7, 5, 4, 3, 2, 2, 1]

The V8 Implementation

V8 is Google's JavaScript engine that powers Chrome and Node. Their implementation is quite clever. If we go directly to the master branch of the V8 source code we can see that Quick Sort is used by default. A check is made, however, to see if the length of the array to be sorted is less than or equal to 10.

function QuickSort(a, from, to) {
    var third_index = 0;
    while (true) {
      // Insertion sort is faster for short arrays.
      if (to - from <= 10) {
        InsertionSort(a, from, to);
        return;
    } 
    ...

So the V8 engine uses Insertion Sort for super short arrays and Quick Sort for longer arrays. Interesting.

Time and Space Complexity.

There's nothing magical going on in the QuickSort and InsertionSort functions in V8. QuickSort appears to use a simple two-way partition so its time complexity can be described as Θ(n log(n)) in the average case. Quicksort's space complexity is O(log(n)).

InsertionSort uses the usual nested for loop so its time complexity is O(n^2) and its space complexity is O(1) because it sorts the array in place.

A few weeks ago on reddit I read a question that asked for a solution to a fairly simple looking array balancing problem. But it turns out that a satisfactory solution isn't easy to come by, and I didn't see any offered in the comments. In fact, I'm not even completely happy with the solution I'll present in this post.

The problem

The requirements are as follows: write a function that takes a number and divides that number among the elements of a given array such that it brings the difference between the elements to be as small as possible.

To make it more concrete, let's set up our test cases and our expected values. Our function will be called .balance and it will be added to the Array prototype:

Two important caveats:

• An element should never decrease in value to balance out the rest of the array.
• The output should have non-whole numbers if it produces the least difference between the elements of the array.

[2, 3, 0].balance(5)    // => Expected output: [3.3, 3.3, 3.3]
[2, 3, 0].balance(1)    // => Expected output: [2, 3, 1]
[5, 7].balance(4)       // => Expected output: [8, 8]
[2, 0, 0, 0].balance(2) // => Expected output: [2, 0.66, 0.66, 0.66]

The creator of the reddit post wanted to simulate the behavior of adding liquid to a grid containing various amounts of liquid and making sure the added liquid balanced itself out.

The quick and dirty way

I posted my solution to the problem in the comments section here. A naïve (but fast) implementation that others suggested was to calculate the average value of the array if the parameter of .balance was added to the array, and then set every element of the array equal to that value. The suggested averaging algorithm would look like this:

Array.prototype.balance = function(input) {
  let currentSum = this.reduce((accumulator, el) => {
    { return accumulator + el }
  })
  let avg = (currentSum + input)/this.length
  return this.map(() => avg)  
}

[2, 3, 0].balance(4) // =>    [3,3,3]        PASS
[2, 3, 0].balance(1) // =>    [2, 2, 2]      FAIL
[5, 7].balance(4) // =>       [8,8]          PASS
[2, 0, 0, 0].balance(1) // => [ 1, 1, 1, 1 ] FAIL

This implementation finishes in O(n) time and passes our first and third test cases but fails the second and fourth. In fact, any time the average of the array is less than any of the elements in the array, the method will fail. A more comprehensive solution is needed.

The slow but sure solution

Because we're trying to distribute a value as fairly as possible among the elements of an array, we can assume that we'll always be "giving" to the lowest values in the array. Written out step by step, it's this:

1. Find the lowest value in the array.
2. Find all the values in the array that have that value and store their indexes.
3. Divide 1 by the number of elements that contain the lowest value. Store that value.
4. Add the number calculated in step three to each of the elements you found in step 2.
5. Decrement the parameter by 1.
6. If the parameter is greater than 0, go to step 1.

Because we're making the locally optimal choice for each 'point' we're distributing among the array, this would constitute a greedy algorithm. An implementation of this algorithm in JavaScript might look like this:

Array.prototype.balance = function(input) {
  let ret = this;

  for (let i = input; i > 0; i--){
    // Find the lowest value of the array
    let lowestVal = Math.min(...ret);

    // Find indexes of lowest values in the array
    let indexesOfLowestVals = [];
    ret.map((el, index) => {
      if (el === lowestVal){
        indexesOfLowestVals.push(index);
      }
    });

    // Distribute 1 point among the lowest values equally
    let avgValue = 1/indexesOfLowestVals.length;
    indexesOfLowestVals.map(index => ret[index] += avgValue);
  }

  // Round the final elements to two decimal places and return.
  return ret.map(el => { return parseFloat(el.toFixed(2)) });
};

This passes the following tests:

[2, 3, 0].balance(4) // => [3,3,3]
[2, 3, 0].balance(5) // => [3.3, 3.3, 3.3]
[2, 3, 0].balance(1) // => [2,3,1]
[5, 7].balance(4) // => [8,8]
[2, 0, 0, 0].balance(2); // => [2, 0.66, 0.66, 0.66]

As with anything written in JavaScript you can test this method in your browser's console.

Conclusion

This method is slow. We pass through the entire array once just to find the lowest value, then again to record the indexes that match the lowest value, and then distribute to the indexes we recorded, which could possibly be the entire array. We would do that entire process 77 times if we called .balance with 77, with one additional pass through to do the rounding. I'd be interested to see a better implementation, however, even in a different language.

TL;DR: Splitting a string into an array is about 70 times faster with 'a string'.split('') than Array.from('a string').

In my interview prep I came across an article on three ways of reversing a string in JavaScript by Sonya Moisset. The problem of reversing a string may seem trivial (and it is), but I'm never "too good" to come up with an answer for a problem. The author of the article showed three perfectly acceptable ways of reversing a string, but I'll share a fourth way that I like. I've been on a .reduce binge lately, and I've been thinking of ways to shoehorn it into every iterator I write, so I figure I'll do it again here.

The normal way

If you were a sane person confronted with the problem of reversing a string, your first instinct might be to avoid reinventing the wheel and just use the built in Array.prototype.reverse method. And to do that you would have to turn your string into an array so you would probably write something like this:

String.prototype.reverseNormal = function(){  
  return this.split('').reverse().join('');
};

Easy and readable. If you wrote this on the whiteboard during an interview you'd probably get the nod. But what if you wanted a confused look instead?

The .reduce() way

String.prototype.reverseReduce = function(){  
  return Array.from(this).reduceRight( (prev, current) => { 
    return prev + current;
  });
};

This algorithm uses Array.from to convert the string into an array such that each element is a character in the string. It then calls .reduceRight which functions similarly to regular old .reduce except it iterates from right to left. Since we're not passing a second argument into .reduceRight to define a starting point, it will set prev, which is our accumulator, to the last element by default. And current, which is the current element at each call, will begin as the second to last element. At each call we build a reversed string through return prev + current by the nature of working backwards from the end of the string. Since we iterate through the array once linearly, the time complexity is O(n).

Benchmarks

I wont bury the lede: the reduce way is significantly slower. Benchmarks were run on a Cloud9 Free Workspace using Benchmark.js in Node v7.9.0. Each method was tested twice: once with a long string ('abcdefg'.repeat(99)) and once with a short string ('abcdefg'). Here are the results:

String#reverseNormal Long x 39,643 ops/sec ±4.08% (73 runs sampled)
String#reverseNormal Short x 845,394 ops/sec ±3.59% (69 runs sampled)
String#reverseReduce Long x 5,955 ops/sec ±3.70% (75 runs sampled)
String#reverseReduce Short x 175,195 ops/sec ±4.40% (68 runs sampled)
Fastest is String#reverseNormal Short

The results are fairly clear: reversing a string the normal way is faster. The bottleneck, however, seems to be in the Array.from method. I set up a test suite in which the only action was splitting a string. Two tests performed it with Array.from(someString) and two tests performed it with someString.split(''). The tested strings were the same as the ones used in the previous benchmarks.

Array#from Long x 10,322 ops/sec ±1.88% (75 runs sampled)
Array#from Short x 326,023 ops/sec ±2.11% (76 runs sampled)
String#split Long x 762,177 ops/sec ±3.33% (83 runs sampled)
String#split Short x 6,611,921 ops/sec ±2.53% (76 runs sampled)

String.prototype.split is almost 74 times faster than Array.from for converting long strings to arrays. Interestingly, if we substitute in this.split into the String.reverseReduce method instead of Array.from(this), the results get a lot closer:

String#reverseNormal Long x 27,795 ops/sec ±3.43% (69 runs sampled)
String#reverseNormal Short x 814,784 ops/sec ±5.00% (67 runs sampled)
String#reverseReduce Long x 36,910 ops/sec ±3.65% (75 runs sampled)
String#reverseReduce short x 1,061,802 ops/sec ±4.60% (68 runs sampled)

The two algorithms are almost equally performant when we do it this way. So the final .reverseReduce method looks like this:

String.prototype.reverseReduce = function(){  
  return this.split('').reduceRight( (prev, current) => { 
    return prev + current;
  });
};

Conclusion

Never use Array.from() to convert a string of any length to an array. Instead, prefer String.prototype.split. The 2016 ECMAScript spec for String.prototype.split and 2016 ECMAScript spec for Array.from are available here. Someone with a deeper understanding of JavaScript can probably do a much better job than I at explaining the performance disparity.

After working through Gordon Zhu's fantastic "Practical JavaScript" course, I wanted to make an app to put my newfound knowledge to the test. I like World of Warcraft, and I play an Outlaw Rogue in that game, so I created rollthebones, a single page, one-button webapp.

If you're not familiar, "Roll the Bones" is an ability in the game World of Warcraft. The ability allows a player to generate some random "buffs" that enhance the player's character for a brief time.

Under the hood

Roll the Bones works like this:

• A numbered six sided die is rolled six times.
• The numbers that occurred the most are kept, the others are discarded
• The kept numbers are translated into the buffs that the players receive.

To make it less abstract, imagine that your six rolls yielded these results [1,1,1,2,3,4]. Since 1 is the most common result, your result would just be an array containing [1].

A few more examples:

[1,1,2,2,3,4] => [1,2]
[4,5,4,3,5,3] => [3,4,5]
[6,2,3,4,1,5] => [1,2,3,4,5,6]

Those collated results would be translated to corresponding buff(s). There are six buffs, and they're all pirate themed:

• "Grand Melee"
• "Buried Treasure"
• "Jolly Roger"
• "Broadsides"
• "Shark-infested Waters"
• "True Bearing

Simulating a roll

This behavior should be fairly simple to replicate in JavaScript. Let's set up the die first. We can skip the translation from numbers to buff-names just by making each side of the die, instead of being plain numbers, correspond to a buff-name right from the beginning. This has the added benefit of ensuring that we're working with strings the whole way through.

const BUFFS_ARRAY = [
  'Grand Melee',
  'Jolly Roger',
  'Buried Treasure',
  'Broadsides',
  'Shark Infested Waters',
  'True Bearing'
];

The next step is to simulate rolling the die (from now on called "bones", let's be thematic). We can do that by using JavaScript's .map method.

const rawRoll = () =>
  BUFFS_ARRAY.map(
    () => BUFFS_ARRAY[Math.floor(Math.random() * BUFFS_ARRAY.length)]
  );
}

The code above independently samples a random element from BUFFS_ARRAY 6 times into a new array. It generates a random number between 0 and 5 and returns the element of BUFFS_ARRAY at that index. It does this BUFFS_ARRAY.length times because we're running .map which iterates through an array and returns a new one.

Generating a histogram

The next step is to find out which value occurs most. We can do that in two parts. The first step is to generate a histogram object where each key is a buff name and each value is the number of times that buff occurred in our rawRoll array.

const generateHistogram = (ary) => {
  return ary.reduce((counter, el) => {
    counter[el] = counter[el] ? counter[el] + 1 : 1;
    return counter;
  }, {})
}

ary in our case will always be a six item array containing only strings that we create with rawRoll();.

Since we're taking an array and making an object out of it, .reduce will fit our needs perfectly. We provide {} as the last parameter to make an empty object the starting point for counter. Then, for each element in the given array, if the element does not exist as a key in our counter object, we create a key and assign it a value of one, letting us know that the element has occurred once so far. Otherwise we simply increment the value of that key by 1 to account for the fact that it has shown up again.

Recap

Let's recap. At this point we can roll the bones six times and generate a histogram of how often we get each buff. If we call rawRoll(); in our browser's console we might get something like this:

let x = rawRoll();
Array [ "Shark Infested Waters", "True Bearing", "True Bearing", "True Bearing", "Jolly Roger", "Grand Melee" ]

And if we call generateHistogram(); on that array we end up with an object that looks like this:

generateHistogram(x)
Object { Shark Infested Waters: 1, True Bearing: 3, Jolly Roger: 1, Grand Melee: 1 }

If these are our results, then our character would end up with a single buff called "True Bearing" (which is the best one by the way) because it occurred most frequently. We haven't programmed that part yet though, so the next and final step is to keep only the buffs that occurred most often.

Finding the modes

Let's write a method to find the modal values of the object and return the corresponding keys.

const findModes = (histogram) => {
  const mode = Math.max(...Object.values(histogram))
  return Object.keys(histogram).filter(el => histogram[el] == mode)
}

In this case the triple dot ... is the spread operator, not the rest operator. Math.max accepts comma separated arguments, each of which is a number, and returns the highest number. We use it here to spread the array of numbers from our histogram's values as the argument to Math.max. This will give us the modal value of our histogram.

We use that modal value to determine which keys (which are at strings like "True Bearing" or "Jolly Roger" or "Grand Melee" etc.) correspond to a frequency that equals that modal value. We filter out the buffs that don't occur the most and keep the ones that do, giving us our final result.

After speaking with a user on the r/learnprogramming discord, I was shown a different implementation.

let max = -1;
let keys = [];

Object.keys(histogram).forEach(key => {
    if (histogram[key] > max) {
        max = histogram[key];
        keys = [key];
    } else if (histogram[key] === max) {
        keys.push(key);
    }
});

I like this implementation a lot. Whereas mine iterated through the given histogram object twice (once to determine the max value, and once to filter out the unwanted keys), the other implementation runs through the histogram a single time, changing the max value and emptying the keys array as necessary. This implementation would be better if we're feeding findModes very very large histograms but for my purposes I'm deciding to stick with my implementation because it's easier to read and correctly guess the purpose of. There's also an imaginary "worst-case" scenario for this implementation in which, because modes might change constantly, the keys array might also constantly be being appended to, emptied, and remade. Additionally, this implementation won't work for histograms containing only negative numbers.

Wrapping it up

We now have everything we need to simulate the Roll the Bones ability. And in doing so we were able to apply our knowledge of the three most common functional programming methods in JavaScript: .map, .filter, and .reduce.

Since we only care about the final result of Rolling the Bones and don't care about the underlying functionality, all we need now is a function to abstract away all the little stuff.

const generateRoll = () => return (findModes(generateHistogram(rawRoll())))

That many parentheses always makes me nervous. But now that we've successfully created the core functionality of rolling the bones, everything else will follow.

It seems natural to me that the first post on my programming blog should be how I got the blog up and running. I started with a clear vision in mind: I wanted a clean, professional looking personal website to show off my growing portfolio and to blog about my growth as a developer.

Why now?

I think many people my age didn't take the internet very seriously growing up. The internet was, in my perspective, still young and mostly the territory of nerdy teenagers and 20-somethings. Sure, some people used it for serious, professional purposes but those were stinky adults. Most of what I used the internet for in my teenage years was hanging around forums with other teenagers pretending to be in their 20s. I swapped from website to website as my interests changed, using different identities and personas for each one, always making sure not to leave a trail of bread crumbs from one username to another. I was a consumer, devouring media and the words of people much smarter than me in the form of blog posts and long reddit comments.

But I didn't want to just be a consumer anymore. I wanted to build things. Making this blog, in a real sense, is making my mark on the internet. I'm no longer an anonymous internet nomad moving from website to website. For the first time, I'm accountable for every word I write. And they won't just belong to AnonymousUser123 and be doomed to archival in shuttered forums and reddit threads. They'll have a voice and a face behind them.

Choosing Ghost

So I understood the problem and I understood my goals. The next step is deciding on the path I would take and the technologies I would use. I'd heard a lot of buzz about Ghost as a publishing technology but I was absolutely convinced after reading Ghost's founder John O'Nolan's interview on IndieHackers. I needed to use Ghost. I loved their goals, I loved the fact that they were non-profit, and I was blown away by my experience using Ghost during my free trial of Ghost Pro. The editor just made sense. And if I was gonna spend hours writing blogs posts this is how I would want to do it.

Using Ghost was also a fantastic opportunity to start learning Node.js. I had originally been reticent to do so but my recent foray into Vue.js left me hungry to learn more JavaScript and I was impressed by the sample Node app that Cloud9 starts you with when you make a Node workspace: a working live chat app written in just a few files.

I wanted to keep it simple and free as I dip my toes into Node so I figured I could keep with my usual M.O. of using Cloud9 for my development environment and Heroku for deployment. I want to give a special thanks to Cloud9 for their excellent documentation and autodidacts.io for their tutorial on configuring node to work with Heroku PostgreSQL. I would have never figured out any of that on my own.

Installing Ghost

Ghost is very clear that they put their full support behind Node.js v4 so I figured I would just pick a version in that generation. Fortunately Cloud9 has nvm built in.

In our Cloud9 terminal:

$ nvm install 4.7.3
$ nvm use 4.7.3
$ node -v
v4.7.3

Now it's time to download ghost and get started.

$ curl  -L https://ghost.org/zip/ghost-latest.zip -o ghost.zip
$ unzip  -up ghost.zip -d
$ npm install --production
$ rm ghost.zip

Since we're running it on Cloud9 and not on a local machine, we'll have to edit config.js (rename config.example.js to config.js if config.js is missing).

config: {
    development: {
        url: 'https://' + process.env.C9_HOSTNAME,
    },
    server: {
        host: process.env.IP,
        port: process.env.PORT
    }
}

We should now be able to access the blog in our development environment just by running npm start in our terminal.

Creating the blog

Next up is getting it ready for deployment with Heroku. First we'll need to get the right files ready in git.

$ git init
$ git add -A
$ git commit -m "First commit"

For quality of life purposes we'll add a .gitignore that prevents the very large node_modules folder from being tracked so we can save some time each time we deploy.

$ sudo echo node_modules > .gitignore

Now it's time to make the app.

$ heroku create name-of-app

Whatever name-of-app is will be the url of your blog. For example heroku create shovonhasan will make shovonhasan.herokuapp.com.

Setting up PostgreSQL

The trickiest part of this whole process is setting up the database. Ghost's default setting is SQLite which doesn't work well with Heroku. So we'll use PostgreSQL instead.

$ heroku addons:add heroku-postgresql:hobby-dev --app name-of-app

You could have substituted hobby-dev with whatever tier of the addon you're using. hobby-dev is just the free version. Take note of the name of the database that was just created. You'll need it for this next step.

The next step is a little annoying. You'll have to go to Heroku's Database dashboard Find the database you just created, scroll down and hit the button that says "View Credentials...". Then use the information there to type the next few commands.

$ heroku config:set POSTGRES_DATABASE=<value>  
$ heroku config:set POSTGRES_HOST=<value>  
$ heroku config:set POSTGRES_PASSWORD=<value>  
$ heroku config:set POSTGRES_USER=<value>  
$ heroku config:set MY_URL=http://your-url.com  
$ heroku config:set NODE_ENV=production  

Configuring things for production

With the database out of the way we need to get our configurations for our production environment correct. In config.js edit the line

production : {
  url: 'http://my-ghost-blog.com',  

to

production: {
        url: 'http://name-of-app.herokuapp.com',
        fileStorage: false,

Make sure the url is the actual url of your website. In my case it was 'http://shovonhasan.herokuapp.com'.
Just a few lines below that you'll have your database settings.

database: {  
  client: 'sqlite3',
  connection: {
    filename: path.join(__dirname, '/content/data/ghost.db')
  },
  debug: false
},

Since we're not using SQLite anymore we'll have to change that to:

database: {  
  client: 'postgres',
  connection: {
    host: process.env.POSTGRES_HOST,
    user: process.env.POSTGRES_USER,
    password: process.env.POSTGRES_PASSWORD,
    database: process.env.POSTGRES_DATABASE,
    port: '5432'
  },
  debug: false
},

And then change the server settings from the default

server: {  
  host: '127.0.0.1',
  port: '2368'
}

to

server: {  
  host: '0.0.0.0',
  port: process.env.PORT
}

Lastly we'll need to make a Procfile to tell Heroku to use the new production settings we just made.

$ echo "web: NODE_ENV=production node index.js" > Procfile  

Deploy

In theory, we should be ready to deploy our application to Heroku.

git add -A 
git commit -m "Configure for Heroku + PostgreSQL"  
git push heroku master
heroku run npm install --production

In my case, however, I got a silly error telling me that my version of Node was unsupported. This seems to be a common problem. If it happens to you just run

$ heroku config:set GHOST_NODE_VERSION_CHECK=false

and deploy again.

Looking forward

Although I didn't actually write any Node code it's a nice confidence boost to be up and running with a good looking website in such a small amount of time. I'm super excited to learn more about Node and blog about my progress. I also wish I had done this sooner so I could have written about learning Vue.js while making rollthebones.herokuapp.com. I'm glad I at least did it now, though, because there's still so much more to learn.