- Set Light mode
defaults write -g NSRequiresAquaSystemAppearance -bool Yes
- Log out and log back in
- Set Dark mode
#!/usr/bin/env bash | |
set -e | |
if [ -e static ]; then | |
rm -r static | |
fi | |
mkdir -p static | |
sass src/sass/main.scss > static/application.css | |
$(npm bin)/browserify src/js/main.js > static/application.js |
State machines are everywhere in interactive systems, but they're rarely defined clearly and explicitly. Given some big blob of code including implicit state machines, which transitions are possible and under what conditions? What effects take place on what transitions?
There are existing design patterns for state machines, but all the patterns I've seen complect side effects with the structure of the state machine itself. Instances of these patterns are difficult to test without mocking, and they end up with more dependencies. Worse, the classic patterns compose poorly: hierarchical state machines are typically not straightforward extensions. The functional programming world has solutions, but they don't transpose neatly enough to be broadly usable in mainstream languages.
Here I present a composable pattern for pure state machiness with effects,
Around 2006-2007, it was a bit of a fashion to hook lava lamps up to the build server. Normally, the green lava lamp would be on, but if the build failed, it would turn off and the red lava lamp would turn on.
By coincidence, I've actually met, about that time, (probably) the first person to hook up a lava lamp to a build server. It was Alberto Savoia, who'd founded a testing tools company (that did some very interesting things around generative testing that have basically never been noticed). Alberto had noticed that people did not react with any urgency when the build broke. They'd check in broken code and go off to something else, only reacting to the breakage they'd caused when some other programmer pulled the change and had problems.
'use strict'; | |
// Licensed under a CC0 1.0 Universal (CC0 1.0) Public Domain Dedication | |
// http://creativecommons.org/publicdomain/zero/1.0/ | |
(function() { | |
// Update 'version' if you need to refresh the cache | |
var staticCacheName = 'static'; | |
var version = 'v1::'; |
img:hover { | |
-webkit-filter: grayscale(0%); | |
-webkit-transition: .5s ease-in-out; | |
-moz-filter: grayscale(0%); | |
-moz-transition: .5s ease-in-out; | |
-o-filter: grayscale(0%); | |
-o-transition: .5s ease-in-out; | |
filter: grayscale(0%); | |
} |
If possible, interactively rebase your feature branch against master
before merging, and condense your work-in-progress commits to clean, single-purpose commits.
Prereq: install git-up
git up
git checkout
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft
,elem.offsetTop
,elem.offsetWidth
,elem.offsetHeight
,elem.offsetParent
# Hello, and welcome to makefile basics. | |
# | |
# You will learn why `make` is so great, and why, despite its "weird" syntax, | |
# it is actually a highly expressive, efficient, and powerful way to build | |
# programs. | |
# | |
# Once you're done here, go to | |
# http://www.gnu.org/software/make/manual/make.html | |
# to learn SOOOO much more. |