- KPI dashboard review
- Since our last retro, what's gone well?
- How do we feel about our productivity and work/life balance
- How is the product better than last week?
- How is the company better than last week?
- Is there anything we should ask a consultant about?
- How is the office/ops?
- How can we enjoy the journey more?
// Simple example, but the idea holds for more complex objects. | |
/* 1) Start with OO */ | |
// user.js | |
class User { | |
constructor(firstName, lastName, email) { | |
this.firstName = firstName | |
this.lastName = lastName |
I think I’ve figured out most parts of the cubical type theory papers; I’m going to take a shot to explain it informally in the format of Q&As. I prefer using syntax or terminologies that fit better rather than the more standard ones.
Q: What is cubical type theory?
A: It’s a type theory giving homotopy type theory its computational meaning.
Q: What is homotopy type theory then?
A: It’s traditional type theory (which refers to Martin-Löf type theory in this Q&A) augmented with higher inductive types and the univalence axiom.
FFMPEG '-i', file, '-c:v', 'libopenjpeg', "jpeg2000\\" + name + ".jp2"\ | |
Convert image to jpeg2000 | |
ffmpeg -i in.png -c:v libopenjpeg out.jp2 | |
Hex Edit out.jp2 | |
ffmpeg -i in.jp2 -c:v png out.png | |
General Edit | |
ffmpeg -i input.avi -c:v mpeg2video -g 999 -q:v 1 output.avi | |
*edit in avidemux/whatever* |
module Logic | |
-- Connective is a fancy word for operator. | |
namespace Connectives | |
-- Truth: Also known as the "unit" type, (there is only one truth in value, | |
-- literally). | |
-- Scala: type Truth = Unit | |
-- Haskell: type Truth = () | |
Truth : Type |
// Async/Await requirements: Latest Chrome/FF browser or Babel: https://babeljs.io/docs/plugins/transform-async-to-generator/ | |
// Fetch requirements: Latest Chrome/FF browser or Github fetch polyfill: https://github.com/github/fetch | |
// async function | |
async function fetchAsync () { | |
// await response of fetch call | |
let response = await fetch('https://api.github.com'); | |
// only proceed once promise is resolved | |
let data = await response.json(); | |
// only proceed once second promise is resolved |
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,