Notes

About these notes A globally-available filesystem is a security liability A globally-available filesystem prevents access tracing A good hyperlink has enough context to work around broken URLs A good markup language is resilient against failure A microservices architecture is object-orientation with big objects An enum with two choices is different from a boolean Approaches to naming products A project is not a product Artificial slowdown as a way to guide deprecation A “shipped” Slack channel for celebration and release notes Asynchronous working environments make it easier to divide up time Audience of my web site A “users” table is a smell Auto-expanding CLI command invocations hinders forward compatibility Avoid naughty words in hex digest strings by changing the set of characters Backwards compatibility (for behavior) is tough to get right Budget for replacing past purchases Bug report format Build processes should only generate new files Code in a good programming language does not reveal its author Contents of my web site Double-entry bookkeeping is accounting’s law of conservation of energy Drive change by writing structured proposal documents Factorio teaches you about tech debt Fast code reviews are crucial for team velocity For a good gaming session, set a goal Get people on board with breaking changes by radiating intent Good human-usable tokens are not random strings Grammar must serve communication Have a dot-com domain for your full name Hierarchies are resilient How to grow friendship circles How to write a good README for a product Importing notes from Bear It is hard in Nanoc to use reusable view components Lightweight markup languages are inadequate for technical writing Logging and caching are (usually) acceptable side effects Minimal language with arrays in Ruby “Mirroring” is using hyperlinks for the mind Module systems in programming languages My pronouns Naming principles Nanoc needs file paths to be known before compilation starts Nanoc needs --json so that the CLI can be used programmatically Nanoc’s in-memory approach limits scalability Nanoc sites take too long to load Nanoc’s terminology is inconsistent with the industry Nanoc’s use of Ruby is not an appealing choice these days Notes are not articles Offices and creativity are at odds Organize electronic archive by year People are bad at identifying invisible threats Phrase suggestions as open questions Programming language design Ruby can be slow for short-running apps because it needs to load (require) dependencies Separate code reviews into feedback levels Short-form content doesn’t need to be written as a chronological sequence of blog posts Short-lived branches are indispensable for refactoring Sourdough bread Speed can mean latency or throughput Spreadsheets are fragile because they only deal with cells Standard exit codes stderr is for all diagnostic output Syntax styles in programming languages Taking a break is better than excess context switching The filesystem is global mutable state The format of a note There are many embedded plaintext metadata formats The type of projects I’d like to contribute to The web tooling in the Node ecosystem is closed Too easy in Nanoc to get undefined behavior Toolbox Tooling for a good programming language URLs and paths require special word-breaking rules Use Docker tags to document the lifecycle of an image Use stdin and stdout, but allow overriding UX matters for developer tools What’s top of mind What would I change about programming language X? What would I change about Ruby? Why can’t I git-push to a remote filesystem? You are not paid to be busy You might not need React