Skip to content

Instantly share code, notes, and snippets.

merging your prs

Tom MacWright tmcw

merging your prs
View GitHub Profile
View scrape.js
const got = require("got");
const selectAll = require("hast-util-select").selectAll;
const unified = require("unified");
const parse = require("rehype-parse");
(async function () {
const { body } = await got("");
const ast = await unified()
.use(parse, { emitParseErrors: true, duplicateAttribute: false })
View load.js
const [map, geojson] = await Promise.all([
new Promise((resolve) => map.on("load", () => resolve(map))),
fetch("foo.json").then((r) => r.json()),

Here's a sort of unsolved logic/programming problem.

I made this site, Old Fashioned, for cocktail recipes. It has structured data for ingredients and recipes for cocktails. And one of its neat features is that, given certain ingredients, it shows you what's possible or what's nearly possible.

I've been thinking about the opposite angle: from which set of 5 ingredients can you make the highest number of different cocktails? How does one correctly solve this problem.

If formal descriptions are your jam: let's say:

  • You have 100 different ingredients
  • You have 20 cocktails, each of which use 2-6 ingredients
tmcw /
Last active Dec 8, 2020
Icons on the internet

Is there a fully great way to do icons on the internet?

What these are:

  • SVG as IMG: You have an SVG file. Create an img element. SVG is the src of that image element. It's an img tag.
  • Inline SVG: You put an <svg> element into your HTML.
View optimize.js
const glob = require("glob");
const fs = require("fs");
const path = require("path");
const { PurgeCSS } = require("purgecss");
const cssnano = require("cssnano");
const cheerio = require("cheerio");
const minify = require("html-minifier").minify;
const sharp = require("sharp");
// This runs on Netlify after Jekyll builds a full site.

Hi Tom!

Here's what the Markdown for a book looks like on

  - book
layout: book
title: 'My Year of Rest and Relaxation'
tmcw /
Last active Feb 14, 2021


Correctly prioritizing and targeting performance problems and optimization opportunities is one of the hardest things to master in programming. There are a lot of ways to do it wrong: by prematurely optimizing non-bottlenecks, or preferring fast solutions to clear solutions, or measuring problems incorrectly.

I'll try to summarize what I've learned about doing this right.

First, don't optimize until there's an issue. And issues should be defined as application issues: performance problems that are either detectable by the users (lag) or endanger the platform – i.e. problems that cause downtime, like out-of-memory issues. Until there's an issue, don't think about peformance at all: just solve the problem at hand, which is "creating value for the end-user," or some less-corporate translation of the same.

Second, only optimize with instruments. By instruments, I mean technology that lets you decipher which sub-part of the stack is the bottleneck. Let's say you see slowness around fet

View SP500.csv
2009-10-26 1066.95
2009-10-27 1063.41
2009-10-28 1042.63
2009-10-29 1066.11
2009-10-30 1036.19
2009-11-02 1042.88
2009-11-03 1045.41
2009-11-04 1046.50
2009-11-05 1066.63
View .vimrc
call plug#begin('~/.vim/plugged')
Plug 'justinmk/vim-dirvish'
Plug 'tpope/vim-vinegar'
Plug 'ElmCast/elm-vim'
" Git
Plug 'tpope/vim-rhubarb'
Plug 'tpope/vim-fugitive'
View gist:a5507b337d9fd05511ca50051ccd677e
(-------------List output---------- )
341 55
342 55
343 55
344 55
340 56
347 56
338 57
336 58
337 58