tmcw

const [map, geojson] = await Promise.all([
  new Promise((resolve) => map.on("load", () => resolve(map))),
  fetch("foo.json").then((r) => r.json()),
]);

tmcw

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

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 `

tmcw

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.

tmcw

Hi Tom!

Here's what the Markdown for a book looks like on macwright.org:

---
categories:
  - book
layout: book
title: 'My Year of Rest and Relaxation'

tmcw

Optimization

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

tmcw

tmcw

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'

tmcw

(-------------List output---------- )
341 55
342 55
343 55
344 55
340 56
347 56
338 57
336 58
337 58

tmcw

(-------------List output---------- )
341 55
342 55
343 55
344 55
340 56
347 56
338 57
336 58
337 58