Journal entries in the last 31 days

last week | last month | last year | all entries

πŸ“… day [[2023-06-07]]
  • Wednesday, 06/07/2023 ** 10:03 Settings panels - particularly for UI - are so difficult.

There are three real ways to drill down into them:

  • Open a monolithic panel with form-like options. Navigate it like a document, with document tools that allow you to select parts and sub-parts of a page.
    • Pros: everything on one page, use the browser document tools, can write as much prose as you want about features
    • Cons: Discoverability is hard, documents are long and overwhelming
  • Universal search. VSCode and Emacs take this approach, as do some MacOS tools and chrome feature flags. Type what you're looking for and see the setting.
    • Pros: better discoverability
    • Cons: naming and language to describe features are hard
  • Visual. Newer paradigm, mostly explored with browser modification tools like Arc's. Visit the parts of the UI that you'd like to change and see how to change them on the UI itself. This can be a debugger overlay that feels similar to the dev tools; you could see a tray with a palette of options, selecting them to toggle them 'on' or 'off' on the screen. (This could be easily implemented for my website... whoah).
    • Pro: avoid language description whenever possible
    • Con: implementation is the most difficult, not possible for features that are strictly logical and don't have a corresponding visual pane

This Google Calendar settings menu that I have open is wonderful; it's document-style with a table of contents, and all of the settings have beautiful visual metaphors to help you understand how to navigate the page.

The Apple menu? Not so great, especially because they try to 'own' technical language and obscure actual features, like saying 'pro display' instead of 120hz or similar. This creates Apple tribalism and helps some die-hard fans feel more integrated - but choosing different names for products and settings from the colloquial standard basically alienates any casual user - which, IMO, is bad for a product like a MacBook that should be a tool usable by everyone. I don't want to have to look up what an 'epic pro max XDR ultra' is - just use the language everyone else does. Please!

Major shoutout to the browser company shader this morning. When you first open the app, the full-screen blob and intro animation with music is so, so beautiful - maybe the best animation I've seen from software in a long time. That intro sequence is immaculate. I'm blown away by the work that these teams are doing on MacOS native apps. Developing those tools to be mac-native is feeling awfully tempting... wondering how easy it would be to port beautiful animated features like this back to Linux and wayland.

Using this Mac has helped me develop a new appreciation for my Linux setup though. All of the animations are beautiful and expressive on MacOS, sure, but my minimal Sway setup feels cold and efficient. Everything happens pretty much instantly without 'affordances' or motion blur or 120fps animations - it 'just works'. The machine feels functional, efficient, and responsive. I would love to build more beautiful apps that feed into this 'feel' while taking some of the innovative visual cues from programs like MacOS. ** 10:16 Writing and recording these daily notes is probably - for better or worse - the highlight of my day. This is great practice. Keep noticing details and working on it! ** 11:10 Made another classic prioritization mistake today. Always make the minimum viable changes necessary to release a usable product for other people. I prioritized doing more 'in-depth' work before preparing a deployment of our product at work. Be more careful next time - propose a minimum viable plan, finish that plan, and iterate, adding more if we need. Do not do more up front than is necessary.

πŸ“… day [[2023-06-06]]
πŸ“… day [[2023-06-05]]
  • It's [[hard]] for [[people]] to [[copy]] something if they don't see it. To make it easy to copy, make it easy to [[see]]. collapsed:: true
    • [[Social]] [[influence]] is stronger when people can see others do the thing often.
      • What can people do that will let them [[show]] off your [[product]] or [[service]] for others to [[see]]?
  • A secret to [[persuasion]] is that you can't actually persuade anyone, you have to mine their [[mind]] for where they already have a [[position]] that [[fits]] yours and [[start]] there.
  • Monday, 06/05/2023 ** 11:30 Dreaming of a computer that 'just works' with software. A compact laptop with a ton of ports. Plugging in a device opens a program specifically associated with that device in a small window on the screen. Those windows compose, allowing you, the user of the device, to control how devices are composed in boht analog and digital ways; the computer knows what device is plugged in, but as a user you can change what that device controls and how that program might be connected to other programs on your computer. Visual nodes and wires on the screen - like max for live devices or similar - allow you to manipulate these separate, VST-like programs to tune them together.

These devices shouldn't be limited to controlling audio; they might be able to channel into some intermediary that can automate, send visual feedback back to the controller, and so on... a device could control a visual and a synthesizer at the same time, displaying art that reacts live to tactile knobs... the ability to touch something and for that thing to give visual and vibrational feedback is so, so important. Musicians know that how a tool feels changes how you think. Everyone should have the power to plug in new tools and change the way they think about problems.

Keyboard artisans know this too, in a different way; they 'optimize' or make pretty keyboards, play with knobs and ideas, itching to find this new input device of the future - or the one that works best for them. It's silly to me that this laptop has one keyboard and screen glued to it that can't be changed. Having good defaults is good - sure - so that the system can always be interacted with, but I should be able to swap these things out and keep the brain behind them. A 'complete' device that can't be customized or plugged into other things feels terrible. Same with battery power. All of these TE devices have built-in microphones, batteries, etc, each with different abilities and qualities, then they promote the idea of putting all of these tools together. They seem fixated on beauty and size at the cost of functionality - I cannot DJ or record with their TP-7 because the disk is too small and the microphone is so poor - but that beautiful brushless motor and notch on the side provide such seamless tangible and visual feedback, acting as the world's most polished tape deck. The knobs on their mixer are far too small - and that mixer has no business hosting expressive audio effects - but it works and works well.

To me, the failures of these physical audio devices are more interesting - like the OP-Z. The thing doesn't have a good way to provide visual feedback for most of its controls and its labels are too domain-specific for how general the device is meant to be. The thing has no screen! A sequencer needs lights under the buttons to show you when they're triggered. A disc needs lights or a screen to show you how that pot is tweaking your system on the fly. This visual feedback has to be built into the controller itself in some way. The Elektron model:cycles looks and feels like a toy, but the rubbery feel of those buttons - the way they light up - and the screen's waves shifting and responding to your changes to the sequencer - are brilliant design decisions for such a budget device. The mouse shows a cursor. Keys show text on the screen. Controls on any sort of device should do the same - or htey're confusing and do nothing. Audio feedback is not enough.

All of these grooveboxes work because they feature software tightly integrated with hardware - and the developers behind them do a brilliant job - but ultimately my laptop is a far more powerful and expressive piece of kit than dedicated 'hardware' (implemented in software as custom firmware). Limits like 24 samples, 256 tracks, whatever - what? My laptop has 16 gigs of RAM and a terabyte of storage. It can probably run the software of every sampler or 'groovebox' on the market combined and look better doing it. ** 11:52 Someday I'll make the clothes that I want to wear every day. Right now I'm focused on computer interaction. Income doesn't feel as stable and developing clothes seems like it costs big bucks - especially clothes without compromises. I have a whole life ahead of me to do that. ** 14:18 Incredibly frustrating that most high-quality hardware products have software built-in. Music tools are no different from SaaS platforms in this way - it's nearly impossible to purchase great hardware pots, knobs, and other buttons without them including some mediocre hardware in the box and gluing the tool to it. I understand wanting to control the complete experience, and that stepping away from a laptop is somehow an obsessive selling point for many people, but controllers should be just that - instruments that connect to powerful programs that run on your computer. Those distractions you have in your laptop are a software problem, not a hardware one that can be fixed with more money and more modulars; the bigger problem is that you do not have control over your computer and the ways in which the software should interact.

I want more companies like Monome that ship beautiful, high-quality, modular tools. Thankfully NI controllers can be hacked, and they have decent hardware, but that's not the point - we deserve better tactile tools for human-computer interaction that don't have to be the complete package. TE takes one step towards making no-compromise, beautiful products, but they aren't substantive or modular in the most important ways. The missing piece of this puzzle to empowering hardware is free software - we need to get there as well. ** 17:28 WebGPU is good, but starting a framework by implementing the GPU rendering is bad because this introduces a barrier to entry.

Using this macbook feels so clean and seamless though. Everyone deserves high-quality basic tools like this. I'm noticing that programs aren't as expressive for developers as the MacOS defaults, though. I am determined to make compelling, developer-oriented software that everyone can use - that can be ported back to MacOS with no issues.

Less configuration is better. Pick beautiful defaults and they'll be used. (Gnome doesn't have the best...)

Also realizing how important it is to be able to move a window around, to resize it and see how the website reacts, vertically and horizontally, on many different screen sizes. Getting some new insights for my website - like how important a responsive sidebar is. ** 19:51 One of the most beautiful things that anyone can do is make a tool that helps people express themselves - especially in a way they weren't able to before

πŸ“… day [[2023-06-04]]
  • [[Flancia]]!
    • [[AG]]
    • [[Diego de la Hera]]
    • PlaneΓ© cuatro pomodoros por la revoluciΓ³n despuΓ©s de las 22, fueron mayormete de conversaciΓ³n y juego -- sin arrepentimientos.

AmanecΓ­ y llegamos a la tarde con alegrΓ­a con [[AG]], y despuΓ©s comimos y caminamos con [[Diego]] y [[Dominic]].

  • How can a [[link]] be made between a [[new]] [[message]] and a message of an incumbent [[group]]? collapsed:: true
    • How often does an [[environmental]] [[trigger]] occur? How strong is the [[link]] between the [[message]] and the [[reminder]]?
      • How many links are there for any given [[cue]]? What will people connect to this thing? How many different answers would you get in [[association]] with this thing?
        • Pick cues that are [[near]] whatever you [[want]] someone to do, so it's easy for them to [[buy]] the [[product]] or [[service]] or [[act]].
          • [[When]] are people in a [[place]] to consider this thing? What is around them in that place? [[timing]]
          • Using environmental triggers to [[sell]] is equivalent to forming a [[trigger]] action [[plan]] for someone else.
  • What would give someone a sense of [[awe]]?
    • People share things that gave them a sense of [[awe]], as well as things that [[surprise]] or are of [[use]].
  • Sunday, 06/04/2023 ** 11:53 Website is almost there. Finishing a project feels so good. Once the build system and hot reloading is complete, I'll be able to seamlessly write content. After that, I'll start working on images and ways to feature my photo portfolio... maybe the project won't ever end.

Clojure really isn't useful here though. Fun but bad decision. JVM has slow start and doesn't really matter - we don't need to run cross-platform and the libraries we would use for that are implemented in many other languages. Should have used javascript - code would have run much faster. Clojure lost because it wasn't useful on the web.

Also, the stack traces are terrible... (I can't see any sort of program trace within my code? No syntax highlighting? What's up with that?). I'll wrap this project up but I'm feeling a strong rewrite it inclination. ** 13:45 Depending on a file means a few things things:

  • You want as much semantic information about that file as possible at compile time
  • You need to use information from the that file to build this one
  • You want to ensure that everything that that file needs is taken care of


  • imports must be named
  • Build scripts return File objects, not write to disk
  • Pass a single argument to build scripts; it's an object that contains all of the named imports

This means that if you depend on any file, you'll have the information about what you need to make your current component run at any time. You'll know what you have to build in order to make that component work. References to that component will have a real, semantic connection to the component itself.

This also allows the file to be interpreted in different ways! I can assemble a list of imports dynamically, then use an interpreter to resolve them. I can use a compiler to set up everything statically. I can make 'meta-components' that transform other components to augment them in clear ways. Good solution. ** 14:01 Watched some tiktoks (reels lol) this morning. Really clever tricks with the soundtrack - some reels through subtle discord, snapchat, iMessage, etc... sounds on in the background to stimulate attention. Really devious strategy. I'm kind of afraid of watching these things now. ** 14:41 For the site - need a way to figure out remote dependencies! Both at access time and at build time. These are network requests. (:type network? :type https? something like that.)

(Live dependencies would be really cool...) ** 19:46 A good test for cross-platform software - would a top company rely on that software to build beautiful products? React Native, Flutter, QT, Xamarin...

The answer is no because there are so many stopgaps and edge cases between platfomrs that have to be healed over. That cross-platform challenge is so incredibly difficult. The APIs are just too high-level to build technology that interoperates! ** 20:28 No GC is necessary for fluid UI. A single GC pause in the wrong place can kill a fluid animation. This is why Apple is behind Swift - and why Swift apps feel so much more fluid than other web tools, even Java - Swift apps have fine-grained control over their memory, which allows them to make UI animations feel incredibly polished. Brilliant!

πŸ“… day [[2023-06-03]]
  • Saturday, 06/03/2023 ** 00:31 The lack of a good Clojure stack trace is killing me. Clojure is great when you don't have errors. When you do, the language provides no diagnostic information (though maybe I'm just unacquainted with the debugging tools that the language offers...) ** 00:32 Fixed the fonts on my system. Berkeley Mono really is beautiful, as are Kate's terminal visualizations. I hope I'll be able to build some into the site and/or into my daily workflow - I'll continue to experiment with how data is shown. Learned a bit about shaders today, too, but I've decided not to spend much time on them - my focus is on perfecting 2D graphics and visuals. 3D is too advanced for me now (aside from some 3D css shading tricks, or a sort of '2.5d').

My site is becoming more and more 'reflective' though. The more I iterate on it, the better the features tend to 'flow together'; I have a bunch of ideas that seem unrelated, but over the course of a couple of days they combine to reveal some super powerful primitives, and those primitives can hten be used throughout the application to make the framework both faster and more expressive. Clojure's "for" laziness bit me today - but I can see laziness being super useful, like to retrieve git log information or to get information about files that are supposed to be dependent on one another. I'll see where that takes me. ** 18:14 The bit of isolation I hear feels lonely, but it's been really valuable; I'm very quickly finding an understanding of what I want to do with my life and how I want to go about it. I want ot make, to build creative tools, to make using a computer better; I want those tools to be freely available to anyone and for them to be the best tools available, so there is no decision between paying Adobe or Capture One or whoever else is adding artificial scarcity to limited commodities; I want to build tools that people both admire as objects and that can be used every day.

Progress isn't made with good work, not entirely; it's assembled between people making connections in the real world. Balue Coffee's pop-up was wonderful; he was so welcoming, the coffee was so good, and the community of people that Justin (?) seems to have fostered is beautiful. Some poeple drove or flew out from fairly far out to spend time hanging out in a parking lot to support this business; to support him. I love doing this for others, but am not sure how to foster a community quite like he has. Life could be so, so rich. Maybe San Francisco or New York would help; maybe I can change myself to foster such a community here.

πŸ“… day [[2023-06-02]]
  • How would this [[product]] or [[service]] give someone an [[experience]] they can use to [[signal]] their [[taste]]?
    • People are more likely to [[recommend]] things that give them [[surprise]] in a short [[time]] frame. The surprise does not translate into ongoing [[talk]] about the thing, though.
    • A specific association between things makes it more likely that people will make [[choices]] with that [[association]] in [[mind]]. Establish a [[relationship]] between something wanted and something people will [[see]], [[smell]], [[hear]], or [[touch]].
    • Things that are said in [[small]] [[talk]] last for a [[long]] [[time]], where things that [[surprise]] are said in other kinds of talk that last for a short time.
      • In [[small]] [[talk]], people say whatever is on their [[mind]]. Whatever is on their mind is often from something around them in the [[place]] they are in.
        • What is going on around them? How can it tie to a [[product]] or [[service]] of ours?
          • What is a part of what [[people]] in this [[group]] do in every [[place]] they go to? Including those parts in your [[story]] will make that story more relatable.
            • Is the [[message]] tied to a [[context]] that includes a part of any place a person might be in every day?
              • What is something this [[group]] does every day? How can this [[product]] or [[service]] be associated with that one thing?
  • Friday, 06/02/2023 ** 09:42 Our innovation budget can't include a new programming language. Use a modern subset of javascript and typescript. Maps, folds. Keep the concrete syntax and semantics; this is a 'dialect'. The toolkit should be as easy as possible for web developers and app developers to use. This means we need javascript. ** 09:48 All in on Rust and Zig. ** 14:50 Snapchat filters are so fun for everyone to use and see. Never fails to whip one out in a tough internal meeting to brighten up everyone in the room. What a brilliant use of AI tools.


πŸ“… day [[2023-06-01]]

Thursday, 06/01/2023


Client-side and server-side rendering are both necessary to make the best websites.

The most important role of a website is to communicate and present data in the best way possible. The best tool is often a static document; this allows you to communicate information that doesn't frequently change to a user.

The ability to take a snapshot - to download a single HTML file and have access to all of the information you'd like to see - allows users to save web documents for themselves and access them whenever they'd like. It's really important for websites to provide static data with the lowest lift possible. This allows snapshot tools to perfectly capture their state, giving the users of a website the ability to communicate data online or offline.

What if that information frequently changes, though?

I've written before about the 'three stages' of information on the web. Information can be retrieved at three times: at site deployment time (the developer deploying the site to a server), at user access time (when the user requests to see the information from the server by clicking a link), and at runtime (updating data while the user is viewing a page).

We know the user wants the most up-to-date information, but each stage comes with a performance penalty; delivering information at access time and runtime can introduce significant lag if not approached properly, as the live data has to be retrieved.

We can load data in 'after the fact' by having the browser request live data again after a page loads. This is a super common React strategy, and improves load times for the user - but means that the page served to the user initially is often kind of useless (it has none of the relevant data until a user spends some time on it!), preventing any sort of archival tool from properly preserving the site at a point in time.

This also may be irresponsible - do I want to render the data on my one computer or on the computers of every single one of my visitors? One clearly is much more expensive. We need to give users the most relevant live data though!

When considering how a platform is built, strive to store all information at site deployment time. If information might change between user access times, that data will have to be dynamically retrieved. If information might change when a user accesses the page, the data will have to be dynamically rendered by a client.

This also calls for three different ways of rendering a website. The first stage is supported by a compiler from source files to target files. The second stage is supported by a service that pulls in live data, sticks that data into a compiler pipeline, and sends the output over the wire. The third uses JavaScript to continuously request and render data from the user's computer.

Because rendering information at different times has these tradeoffs, switching between different rendering strategies for particular portions of the website should be as easy as possible. If I want my data to render statically but update live, I will have to render that data in two places - on the server and on the computer of the user. I will also need to obtain that data in both of those places - ideally from the same source.

How do we solve this?

  • The compiler can render information with any language.
  • The server can render information with any language.
  • The web renders information with javascript.

Cool. The UI development language has to either be javascript or support javascript.

What about alternative rendering strategies? What if I want my app to render easily on desktop and web?

If we want to draw with pixels, we can 'sideload' rendering on the web in with the HTML canvas. This would allow users to program in their language of choice. This also sacrifices all of the tools that the web browser provides and prevents static rendering entirely (it is not possible to draw a canvas statically).

If we want to draw with the GPU instead of just putting pixels on the screen, a presumably faster strategy, we can program against the WebGPU API on both the web and the desktop - but again we lose all of those advantages of HTML on the web.

Cool, maybe we can bring the web to us. Let's wrap our app in a web browser and have users download our application code, then tell the browser to render that.

Some problems:

  • Web browsers are huge - several hundred megabytes at the least. It is irresponsible to ship an application that's probably a few thousand lines of code (< 1 mb) as a 300mb app.
  • Web browsers update frequently. Many of these updates introduce new APIs or fix security vulnerabilities. The former is fine - we can avoid those APIs - but unknowingly leaving outdated, vulnerable code on the computers of our users that we cannot easily fix is rough.
  • The web API may not be the best paradigm for rendering. If I need expressive and performant 3d tools, GPU through JS might be too slow. I want the browser's native hardware and optimized, low-level code.

Because our documents are glued to the browser - the most expressive document viewer ever - everyone expects their applications to be accessible there, too. Links are really powerful. Requiring a user to download software to try it out simply is not a good option nowadays.

This is why comprehensive rendering solutions are so difficult. There are two APIs we have to glue into if we want both fast and browser-optimal code to be available everywhere, both with very large surface areas.

We have two paths to move forward:

  • Reinvent the wheel. Deny that people use browsers and require users to download new software that reinvents the idea of the browser as a platform. We can write optimal code with good APIs that runs everywhere. For portability, we can pre-compile software for every platform that uses it and statically link it, or we can distribute a virtual machine that our software runs on. This requires significant user buy-in, but it means that we can ship native-feeling apps with small application sizes that are available off of link. We also lose all of the external work in the browser on extensions or other development tools. A compatibility layer to HTML canvas can be implemented here, but that loses all of the accessibility features and lots of the performance benefits.
  • Develop against a very large API surface. We have red functions and blue functions that can't be mixed - HTML/CSS compatible functions and WebGPU/Canvas compatible functions. Somehow both types have to be both executable on the browser and on the server. We have to preserve the information about the context in which these can be used - GPU has to happen inside of a canvas, which has to be inside of HTML - which means we're glued to a strongly typed language if we want to produce code that has a decent performance profile.

Things that are not up for discussion:

  • Reactivity. The consensus is that reactive frameworks are obviously good for displaying complex information. Parts of every application should have the ability to be written with a high-level, reactive API because this is such an expressive paradigm and development velocity win. Imperative GUI modes are best for real-time rendering - and can be more performant in some cases - but the cacheing control that reactive frameworks provide can also save lots of compute that we don't want to spend if we don't want to re-render something complex.
  • Expressive rendering with GPU. We want the most performant software possible. The web is disrespectful.

All I'm saying is that reinventing the wheel is looking really good right now...


Why can't we just target HTML/CSS with business logic in JS / WebAssembly?

We always want accessibility hints, and we always want debuggability - a document flow is ideal for those. A lot of the time, though, the web presents problems to us. The DOM cannot render pixel-perfect documents without the canvas.

Google Docs moved to render entirely with canvas recently, and though they didn't state why, I have some suspicions:

  • Implementing an expressive, interactive layout engine with the DOM is really rough. You want to be able to shift margins and boxes by specific pixel sizes and make adjustments at different scales. The DOM becomes a bottleneck.
  • Font rendering on the web is a moving target. You aren't in control of the font rendering strategy that your client's browser uses, so you can't control what font rendering primitives they have access to, if they can support variable fonts or certain points or certain glyphs. Downloading fonts only solves half the battle, and injecting a custom renderer for text is reinventing the wheel but in a more complex way.
  • Fonts and layout engines interact in really complex ways; it's been hard to get this right at work, even for our web application that isn't doing anything unique at all with fonts or font rendering. Rendering all of the fonts and the layout to canvas allows the implementer to be in complete control of rendering logic - not the browser.
  • Interacting with the DOM prevents you from being completely in control of your data sync story. Google Docs wants to always render real-time synced text and formatting data. To change how the DOM looks, code has to iterate through all of the DOM nodes, making small changes and adjustments. The two ways of doing this - modifying the existing DOM to incorporate the new changes in real time and completely re-flowing the doc - introduce significant performance bottlenecks. Low latency for text documents is incredibly important. Application sync over the internet seamlessly is really important to their real-time, collaborative platform. They cannot afford to take the performance hit that DOM re-flowing incurs.

The docs team also added a feature to support static web rendering via the DOM. This allows those live, view-only previews and snapshots to be taken, efficiently rendering a static site that is served to others without the issues discussed. Unfortunately, they have to write all of the same code twice - one for the static doc that's distributed to others and another for canvas editing version.

Thankfully, the canvas doesn't sacrifice all of the browser tools - its api does offer some accessibility tags and primitives:

This means that if we want to give application developers expressive and fast tools, we cannot rely on DOM rendering to support every use case. There must be a seamless way for them to fall back to pixels. The canvas API, I'd argue, is not seamless - those accessibility hints and tools cannot be rendered statically in documents, for one (unless you count images and SVGs - but then you sacrifice the interactivity that makes HTML docs so brilliant to an opaque image).

The conclusion here is basically that we need to be able to develop custom, pixel-perfect tools within the canvas that the browser will render statically to a document, but that can be interactive when that document is open. I haven't explored why static HTML - rather than JS augmented HTML - is important, but mostly because JS is a mess and is too expressive for what we want it for most of the time. Documents should be usable without executing a general purpose programming language - users should never have to incur that performance hit.

I'll have to rewrite this whole article when formalizing it.

πŸ“… day [[2023-05-31]]
πŸ“… day [[2023-05-30]]
  • Tuesday, 05/30/2023 ** 11:21 A bit ashamed that my OP-1 tweet has gotten so much more traction than anything else I've made. It's cool that I was able to get my hands on a development unit - and the photo is decent - but it's embarrassing to me that the thing I've put out into the world with the most 'impressions' is a photo of a device that someone else made. I feel the same way about hundreds - maybe thousands - of people see what I curate on the platform, but ** 23:28 Nah... getting more exposure always seems good. I've put so much effort into the site - and am so glad that Tommy loves my web design. : )
πŸ“… day [[2023-05-29]]
  • Monday, 05/29/2023 ** 22:45 I hope that these notes never stop. I want them to continue forever. Twitter clout posting rather than actually making music or my website better. Learned the OP-1 today. This might be the most beautiful piece of technology I've ever tocuhed. It's so responsive and dynamic. Everything is instant. Confirms my want to reroll everything myself - that'll get us to 0 latency. The visual metaphors that every TE instrument presents you with are insane. I can't wait to keep learning. ** 23:13 Testing git weather v2. ** 23:17 Nothing to commit? Not anymore.


πŸ“… day [[2023-05-28]]
  • Looked into [[keyoxide]] again after seeing a reference in the profile of [[youronlyone]]
  • [[]]
    • [[wiki]]
      • changed links to registration form to point to
      • posted maintenance announcement
      • redoing [[wiki migration]] on
      • disabled parsoid
      • enabled registrations
      • done, it seems, pretty much! \o/
  • #push [[pfeilstorch]]
    • showed up in my open tabs, is interesting, but I don't remember how I got there :)
πŸ“… day [[2023-05-27]]
  • Saturday, 05/27/2023 ** 13:19 Tried watching some "Tsoding" streams to see what steaming for programming looks like. I'm not sure if I'll start streaming again, but his investigation of Zig was very insightful.

Almost-quote of a language: "Developing a language could be just like discovering a game. A game is designed to teach you how to play it - to discover new tips and tricks without realizing that the system is teaching you how to progress. The process of using a language - from the starting process, the error messages, and so on - should be designed like a game, to inform the user to navigate the language and teach them features."

All computer programs are the same; a program is a tool that a user has to learn. Choosing the right way to help your users is vital to helping your users understand how to use your program.

Do I provide a manpage? A --help flag? Good error messages? A website with a great search bar? An interactive tutorial? A supportive Discord community? How do I determine what the best way is to teach my users to use my software?

Today I've also been testing out the Helix editor, software that claims to be a modern replacement from neovim. The program claims to be a complete rewrite, but effectively rewrites and compiles in expressive neovim packages and configurations to produce the best source code editing experience out of the box. The best aspecf of this is the help menu, though - as soon as I started typing and saw a keybind that I didn't expect, I was (1) shown a menu of all possible keyboard shortcuts, and (2) shown an English explanation of my action in a pop-up. I felt encouraged to play - trying more keyboard shortcuts helped me understand more about the system! - and it was incredibly easy to find tools like the file browser and to start using the modal editing features. It's still a bit confusing to open the program to an empty buffer - but their onboarding experience is doing a lot of things right.

At work, a principle design focus is killing any sort of product tour. We include one as a crutch - it allows us to explain features we're quickly adding support for to the platform because we're building a product without clear competitors or comparators - but making UX feel seamless - teaching the user to use the product as they explore - is our primary focus. Presenting information-dense views with affordances to attract the eyes to particular aspects of the interface encourages the user to look at - and interact with - parts of the screen, and in doing so, I hope they learn. ** 13:40 Test for my website's sidebar hierarchy:

home β”œβ•΄pages β”œβ•΄c β”œβ•΄c-style β”œβ•΄ helpers β”œβ•΄making-c β”œβ•΄journals β”œβ•΄2020-10-10 β”œβ•΄2020-10-05 β”œβ•΄files

and questions:

  • How do I better visualize deep nesting? (The above isn't very clear.).
  • How deep should a website go?
  • What should be visualized? Connections? Graphs? Headings? What is important enough to visualize?

Some pros:

  • I love the table style that I have going so far, and think it will apply wonderfully to ascii art. It's a wonderful pattern to reuse.
  • The website should feel as configurable and as interconnected as possible; things changing on one page should affect others, information should be shared whenever possible.

Thoughts on the framework so far:

  • I am loving zig's 'comptime' features. I can feel the paradigm in my website framework too. The framework has three distinct stages: the static generation stage, the javascript integration stage, and the deployment to user stage. Each has different information available, and our goals are to both minimize the amount of work necessary to redo that information and to make use of that information in a way that's as expressive as possible. There are still lots of things to solve, i.e.: How does hot reloading function for pages depending on source files? What information do we want to show on the site that's "live" (loaded when the client visits the website - as opposed to loading the information when the file is built or when the file is served). ** 13:56 I want a git commit that tracks not only when it was made, but also where it was made, how the weather was, etc... ** 20:10 Taste is changing. I used to think that keeping photos flat, collapsed, straightforward, with lines pinned and corners all at sharp angles, was the way to go. The more work I do and the more time I spend outside, the more I realize that I want my screen to feel expansive and broad, to include as much information as possible, to make the viewer feel a real sense of depth - like they're not just squaring up with a digital screen, but that they're seeing another place.
πŸ“… day [[2023-05-26]]


πŸ“… day [[2023-05-25]]
  • Thursday, 05/25/2023 ** 16:17 Every time I read a new geohot essay I want to win Incredibly lean Incredibly direct Ultimate 'the proof is in the pudding' - speak with your actions and your work. ** 23:48 Lots of personal website work this week. Starting to become seriously frustrated with
πŸ“… day [[2023-05-24]]
  • Wednesday, 05/24/2023 ** 18:33 What have I learned about fonts in the past day or so?
  • Variable fonts are fascinating and the best tool to use.
  • Open-source font culture is brillant, but the design and type community are so far behind software in this regard. Open-source font projects exist - and many of those that do are truly exceptional - but most of the leading type foundries keep their work proprietary (and inaccessibly expensive). The tools to build fonts with free software are still immature, especially if you can't program.
  • Bitmap fonts are brilliant in their own way - for their ease of use. I wonder if there are technologies to 'smooth them over' to convert them to TTF fonts if they're specified at a high enough resolution. This also seems impossible, as the decision to 'smooth something over' is entirely aesthetic, and the small details of these details is so important.
  • Rendering fonts is a mess.
  • Ligatures can be used for so many brilliant things. I love the '99 balloons' look.
  • New appreciation for 'Inter'. I'm not happy with some of the parts of the font that have been rounded off - loose ends and such (without a better word) - but the fact that inter is brilliant for legibility in every use case is incredible. I wouldn't choose another free font for a user interface after trying it - it's the best default imaginable.
  • Even great type designers miss little details. I keep finding little edges - little cracks - of designs that don't feel as thought-out as the type designer would like to have you believe. Studying type teaches you to appreciate pixel-perfect detail in a way that not many other crafts can.
  • I like 'neo-grotesk' fonts with sharp edges.
  • Univers might be the best font. All of the principled fonts that I like are variations of Univers.
  • Tricks for making fonts more readable:
    • Fonts must be incredibly legible at their most thin to readability on small screens.
    • Perfect the spacing, the punctuation, and particular letters.
    • Picking a few letters to make 'flash' can help your font stand out in a competition, but particular letters that are distracting significantly hinder readability.
    • Multi-language support is insane. Practically impossible. I'm immensely appreciative of type designers who work across language boundaries - especially when deviating from Latin characters.
πŸ“… day [[2023-05-23]]
  • Tuesday, 05/23/2023 ** 11:48 ULN Industries will be the operating system of the future. Our hook is seamless native application development, rolled from scratch, that feels like the future. We support mobile application development through an ULN mobile app. Our services are open-souce and interoperable but not necessarily friendly to all contributions. Programs are strongly opinionated and work seamlessly with one another and with a select group of boundary-pushing external tools.

Goal 0: A great framework for building desktop applications.

Goal 1: The best made GUI Linux desktop applications for everyday business applications. Text editor, calendar, email, and so forth.

Goal 2: An everyday software suite that users of Apple devices are compelled to use instead. Apple is a direct competitor. Our tools are more seamlessly interoperable, open source, more consistent, and just as beautiful. You want your computer to feel like our system. No data moats - but we seamlessly wrap and distribute beautiful free software services.

Goal 3: A toolkit for any user to develop ** 13:24 nushell: when creating the signature struct for a command, if the command is 'main', replace 'main' with the name of the file

(Later/harder: if i write a bunch of commands with the same name as the file i'm writing them in - i.e. 'hey $cmd' in the file 'hey' - the command to execute hey $cmd should be hey $cmd, not hey hey $cmd)

also, if 'help @' command fails, try to execute @ --help to see what happens?


  • Another day, another coat of wood stain on the desktop.
  • I'm thinking about maybe starting a monthly or bimonthly newsletter. As a good nudge to make packaged pieces of writing on a regular basis.
    • I saw that Ghost has a thing for sending newsletters, and that you can host Ghost on Yunohost.
  • Paid some invoices, replied to some emails. Amazing how quickly these things pile up.
πŸ“… day [[2023-05-22]]
  • [[flancia]]
    • I had an allergy attack yesterday but at some point it turned -- it stopped getting worse, started getting better. Was able to have a normal night after that.
    • Slept a solid 8h+ after that
    • Woke up feeling finally recovered from disease!
  • [[work]]
    • Starting the week energized.
    • It was a solid day!
    • Actually looking forward to the week.
  • [[AG]]
  • [[791]] == #7 x #13
  • Monday, 05/22/2023 ** 10:57 Writing for clear communication
  • Do not start a sentence with 'it'. Whenever a sentence addresses a subject, use a specifier that will either provide additional context to the subject or
  • Use the simplest words that you can. The English language has too many words. Using words that are not very common can cause confusion. Assuming a definition or having an incorrect understanding of the definition of a word or structure can confuse the reader.
  • Use the simplest sentence structure that you can. Sentences that are more concise are more easily read and understood by more people.
  • Use proper English with as much parallel structure as is reasonable. Parallel structure can help recipients read faster.
  • Use a proper subset of English. Just like programming or mathematics, if a well-defined specification exists, your intention will be more easily understood. The English language relies heavily on context. This complexity can add ambiguity to sentences. Avoid complex sentence structures and vocabulary to avoid this ambiguity.
  • Use as much detail as is necessary to include for the subject.
  • Break down long passages or essays into more easily understood contents with clear headings that summarize the purpose of the passage. Introducing differences in font size, spacing, and formatting adds additional structure to the text, informing the reader of the document's structure explicitly.
  • Use examples if your description is abstract. [Descriptive examples should be added here].
  • If using an expressive platform for writing, use all of the tools available to you. Include images, drawings, and diagrams if possible. The interactive diagram, if executed correctly, is the best tool available to explain information today. Make heavy use of tags, links, and other expressive tools that your writing allows. Improving the user interface to your writing can communicate your ideas in a more expressive way. Linking to other people, documents, tables, and other information throughout your knowledge base can help readers understand how your document relates to other parts of the project or business. ** 11:52
  • Don't omit context from the document. If all of the context is available in writing, everyone reading the document can understand the motivation. If context is missing, a reader might not be aware that the context exists. Avoid including an unreasonable amount of context, but if someone who reads the document does not have an easy way to find that context, the document loses purpose.
  • Define abstract concepts and use those definitions exclusively when referencing the concept. If words are not chosen carefully, different people are speaking different languages and therefore saying different things. Definitions are vital to communication. ** 23:00 Technology appreciation thread!

Nix is getting better and better. This new Emacs interface - running on Wayland and natively compiled - feels so, so fast compared to earlier today. Glad I rebuilt.

Nushell is the easiest tool I've ever used to write comprehensive shell scripts. I'm incredibly impressed - casual-looking comments fit the 'vibe' of an ad-hoc script but they're instantly used as documentation for their associated commands. Crazy! Check jakeisnt/nixcfg on github at today's date - the hey command was rewritten from an 85mb clojure bundle to a 'free' (because we're already using nushell) shell script that's a third of the number of lines of code and far, far easier to understand - while preserving the same kinds of type information that clojure was (just under the hood). JT and the rest of the nushell crowd are brilliant creators of user interfaces.

Can't wait to see how I can get interactive polling commands working and similar - would love to make reactive tables.

Zig feels just as modern. Still sort of undecided on the Rust vs. Zig spectrum, but I've gotten quite tired with the typed baggage of Rust while Zig lets me goof off and do more or less whatever I'd like (for good or bad). My flipbook project is definitely rendering a raw pointer instead of the buffer that it's supposed to right now, but we'll figure it out.

Blown away by the comptime feature and how dynamic it feels. I've never been able to create a data structure on the fly before and use it in normal code with a strongly typed language such as this - but comptime feels magical, automatically shifting 'meta' code to the compile time step to interpret normal Zig code and bake in the results. I've used it to create rendering engine that uses a fixed-size buffer - without any heap allocations! The buffer struct definition is inlined (? i think) up front at compile time so that the instantiation can be so seamless.

I'm lacking the proper programming language words to describe this, but I also love the build system and how seamlessly I can integrate with C code - a process that's quite difficult for C <-> Rust, javascript <-> typescript, etc... both systems that claim to be easy to do but that, in practice, require modifying the build system of your project and introducing typed headers (which can be real or fake).

Zig builds Clang into its own compiler and simply has all of the information from the C headers and their types available, and has a memory model that maps cleanly to the same LLVM types that clang's C code uses. Brilliant. I don't have to learn Bazel's Python dialect after all - I can just get to work.

Wondering if Rust or Zig with hot reloading would be possible. Zig's anytype annotation is lovely - letting you wing it with systems code and test solutions fast - but not sure how well systems like that scale. Rust is slow with binaries that are too big - Trying to get my launch program - a simple egui app - to work on my computer was a disgusting mess when having to build from source. We'll stick to Zig and stick to boring libraries that can be dynamically linked (when necessary) or my own code (when possible) to make transpilation from scratch a fast process for as long as we can. Fast compile times are so, so wonderful for creating and distributing software. No messing around with caches or storage. You can send someone the source code and they can change it and compile their own tool. Simply brilliant. ** 23:33 Software keeps getting better and better, but only as a result of the significant amount of effort put behind making open-source software faster and more useful for the prople on the other side of the screen. Incredibly reassuring to see great projects succeed and to feel my computer become faster and use resources with greater optimality.

Hurts me how slow darktable is. I'm not sure why it's that way but I want it to be faster. that tool is the weakest link of my graphics programs and I'd love a replacement - or for the developers of that software to make it better and faster and more beautiful. The code runs and works for sure, but does not look great - and you can feel that pain as an end user. The external interface and feel of software closely mirrors the structure of the code and the organization of the team behind it.

Just opened my web browser. Half the websites I open feel like software going backwards. Feels like web software gets slower no matter how fast my computer is. Upsetting.


πŸ“… day [[2023-05-21]]
  • Sunday, 05/21/2023 ** 17:37

Back at ilcaffe drottninggatan. Great place to work.


πŸ“… day [[2023-05-20]]
  • Saturday, 05/20/2023 ** 15:13 More work on personal style today. Extremely formal doesn't fit. Those fabrics are stiff and not breathable. It's hard to feel comfortable! Loving the modern 'workwear' brands - some cuts of Our Legacy, AFFXWRKS, ACNE Studios - and silver jewelry with chunks taken out of it. Completely avant-garde is too impractical - I'm not out to win any awards - but repairable Rick boots are a great compromise. I want clothes that can be worn every day without wearing out, that can be repaired and maintained and reworn and that show their age slowly, but don't have to be carefully taken care of; fabrics that look hard-wearing rather than fuzzy or fragile.

This puts Our Legacy's lyocell experiments out of the picture. Unsustainability aside, the fabrics so quickly stretch and reform and are so so fragile - I don't want to have something else to take care of. Linen is a beautiful fabric for sheets - and feels great as a garment - but doesn't look like it's robust. I don't want something I wear to tear and fall apart as I live daily life.

Clothing that wears texturally without losing color also seems important. Denim wear is visible in the dye; as the cotton stretches, color is lost in some places and gained in others. In the meantime, the clothes are absurdly uncomfortable. 'Futuristic' fabrics, by contrast, stretch and contract and scratch - and these blemishes are visible in the texture of the items but not in the color. Paint and stains show, sure - but those are added, not removed from the garment.

Also loving neutral and deep blues. Beige is great for sheets but doesn't feel like it fits me - something to do with my skin tone. Warm blues match the eyes. AFFXWRKS work is brilliant - futuristic workwear. A bit too colorful and too Prada-infused to like most of the items - but some of the pants are masterpieces. They nail the workwear pant construction but use futuristic-feeling breathable, robust fabric. More of that please. ** 16:53 How do I know whether other people are open to being reached out to? How do I reach out to them?

This is easy in New York or Italy or Portland or Seattle or Boston - it was so easy to approach people and ask questions about them, their outfit, what they were up to, and so on... but here people feel far more reserved and the language barrier is difficult.


  • Spent fucking ages getting the layer of varnish off the top of the desktop. Using a 40 grit sanding disc.
πŸ“… day [[2023-05-19]]
  • #push [[31]]
    • Un mantra:
    • Las Jaras, quΓ© jaras?
  • Friday, 05/19/2023 ** 11:59 Justifying you dislike, aversion, or repulsion is incredibly important. The next time you see something and dislike it, spend five minutes thinking about why... the visceral reaction is real, but it ccomes from somewhere. Find a logical explanation for the distaste, drawing the idea back to either customs you're used to, or principles humans share, or both. You can only talk about what you'd rather have when you understand what you don't want. ** 12:05 Through middle and high school, instead of bringing our calculators to school every day, most students had a calculator ROM app. Users could pirate a TI-84 ROM, run it on this calculator emulator, and have all of the functionality of the original calculator available. ** 15:22 Finally understanding more and more of 100 Rabbits' radicalization principles and why I might want to deviate from them.
  • GPU programming is a proprietary mess.
  • Window managers are a disorganized mess with largely overlapping APIs that have small (but significant) differences.
  • SDL2 is the easiest way to get access to a device framebuffer that you can write pixels to the screen without intermediate complexity.
  • SDL2 handles all of the window manager abstraction work for you, from allowing you to open windows with different settings to receiving window manager input events. These are necessary to make any sort of cross-platform software.
  • Virtual machines are necessary for making software portable. C is a good idea - a good start - but expecting C compilers to work the same way on every system is a mistake.
  • The best way to write cross-platform code would be to standardize a machine language across everything (impossible). The second best way to stay portable is to make a virtual machine that can execute platform-independent code, then distribute software for that machine.
  • The third best way is to use the most popular existing virtual machine - the web browser. Users can't discover your work without being able to view examples of it and try it out on the clearweb.
  • A fixed size window means no thinking about changes of layout when making the screen size larger or smaller. Building only for a single screen size eliminates lots of considerations and problems.
  • Refusing to support modern formats, standards, and software allows you to significantly reduce code bundles and complexity.
  • Interoperability - both aesthetically and logically - is beautiful. Unifying on standards is really cool.


  • I'm less interested in minimizing resources and more interested in maximizing creativity than they are. I want modern tools that are easily understood, free, and widely available.
  • I want to support larger ecosystems like the language-server protocol, modern font families, and modern image formats so that non-technical people can use my tools in their everyday lives.
  • I care just as much about making software beautiful and minimal, but I will always compromise minimality for ecosystem support.
  • Supporting multiple screen sizes can be a good decision, but it's not as necessary as the modern web and mobile devices would like you to think. Use fixed screen sizes when possible to simplify tools.
  • Portability requires sharing. I need to make sure not only that it's as easy as possible to download and use GUI applications as a part of a normal OS workflow, but also that it's easy to find and share those applications.
  • Web app users expect to be able to try and use free tools in the browser, then download them later. Our engine will have to support a web backend in some way.
  • Keeping the core of an engine incredibly minimal pays off. All of your software will run instantly everywhere.
  • Abstracting away concepts besides files to share between applications is really useful. Text buffers are a great example - they can hold anything UTF-8.

Other thoughts:

  • I'll eventually need to make a reactive GUI system to get this all to work right. This will require a compilation step on every platform. Hopefully I'll be able to devise some smooth incremental compilation scheme.
  • Ideally someone can just use/download/update their program with a single command passed a URL. That will work for technical users. How do we make non-technical use feel just as seamless (no '!Update' banners from web browsers or silly Adobe notifications)?
  • Nailing your website design and web copy is the most important tool for being seen on the internet - more important than any social media use or post. Instagram, Twitter, TikTok, etc... are secondary to a beautiful, impressive, and clear personal website.
  • Diagrams and images are vital to your web work. Without them your writing is kind of meaningless. Interactive visualizations are ideal, but barring those, diagrams as pictures are great.


  • Yesterday I submitted my final output for [[YXM830]]!

  • Reading [[Capital is Dead]] (again, didn't finish last time) and loving it. I really like [[McKenzie Wark]]'s writing style in this. I'm finding the argument about there now being an information-based [[Vectoralism]] - something even worse than capitalism - quite compelling, though I know many disagree.

  • Used the borrowed orbital sander to sand down garden table and chairs that are a bit weather beaten.

πŸ“… day [[2023-05-18]]
  • [[People]] want to [[talk]] about things that highlight how they're a part of a [[group]].
    • If they were selected for some [[game]] or something is [[name]]d after them, they are more likely to [[talk]] about it.
    • People like having something they can point to that shows how they were recognized, such as [[medals]], trophies, or [[awards]].
  • Thursday, 05/18/2023 ** 19:39 Radicalized by GPUs - and needing something to do - I'm going to make interpretable graphics from scratch.

We're starting with SDL2.


We need a library to manage window manager events to write code that runs on multiple platforms. Our two options here are GLFW and SDL2. (Other options are immature. Rolling our own is a waste of time and impossible to keep up with.)

For simplicity's sake, we also want to be able to access the framebuffer and all of its information. GLFW makes the assumption that you will be passing its framebuffer directly to a supplementary graphics library for you that will query information such as window dimensions. GPU drivers and APIs are a proprietary mess, so we will not be using them. SDL2 gives us all of the information we need about the window we open. Hell yeah!

Later, we might want to underpin the interfaces that are developed for software rendering with GPU code for performance. This will not happen unless there is a significant performance bottleneck. For now, we'll use SDL2's framebuffer to handle everything. ** 21:16 I've been waffling around minimal computing for awhile now - and now I've got it. Largely inspired by ideas from 100 rabbits - - but considering that their approach butts heads with everything I know about programming language and user interface design, I couldn't entirely buy in. I wanted to learn more first.

We're starting with a simple Zig experiment - render an 8x8 grid of pixels with a moving animation. From here, we'll explore fonts,


  • Issue with publishing on my server
    • Loading home/…
    • β€˜org-publish-cache-file-needs-publishing’ called, but no cache present
    • The file in question is there, but it's empty - is that is what is meant by not present?
      • wonder why it's empty?
πŸ“… day [[2023-05-17]]
  • What can someone do with an everyday thing that would cause a lot of [[surprise]]? What would help [[spread]] this thing?
    • How does talking about this thing make someone look? How does it help their [[mask]]? collapsed:: true
      • Is this a [[cool]] thing they could share with the people who are around them?
      • Will this make them look worldly?
      • Will this make them feel like they're [[ingroup]]?
      • What about this can they show off to others?
    • What would remind someone about our stuff? What do they [[move]] by everyday that would bring our stuff up?
    • What about our stuff has them [[feeling]] things? What would they feel?
    • Can people [[see]] other people use our stuff? collapsed:: true
      • How can we make it easier to see our stuff?
    • How can they [[use]] our stuff to get where they [[want]] to go?
    • What kind of [[story]] would they [[want]] to [[spread]]?
      • People [[spread]] things they [[want]] to [[talk]] about.
        • What could be given to them to [[talk]] about that will make them seem [[cool]] or in the know? collapsed:: true
        • How would this turn into a [[game]] that they can [[play]] and [[talk]] about trying to [[win]]?
          • [[People]] will give up [[absolute]] gain if it means they will look better than others. Most college-attendees would choose to be a big fish in a small pond, rather than a smaller fish in a bigger pond that has more food for everyone.
  • Wednesday, 05/17/2023 ** 13:55 The rideshare / transportation service industry is messed up and governments need to stop trusting services that lie. Every company competing in the space is operating in a 'zero to lyft' market. Every customer wants all of the capabilities of the app they're most familiar with - and whether they use BlueBikes or CitiBikes, Uber or Lyft, X or Y, they're accustomed to very mature user interfaces and expect all of those features from a new product right away.

Small teams building in this space are then contractually required to build those features - they have to reproduce the work of a major player, but with much less time and with many fewer resources. Because everyone who operates in the space sees a clear target - 'we have to build from zero to Lyft' - they think they can do all of that and improve on the platform UX and customers expect that of them.

Companies in this space have to learn to disappoint in some ways, compromising on feature set instead of functional quality. The social problems that get them into the space to begin with - maintaining the bikes or scooters, improving the relationship the company has with the people who maintain the vehicles, and ensuring that all of the items are in good condition - are far more important than the technical issues that have to be solved. I'd advocate for eschewing the map at first - the app can open the default map app on the mobile device - in favor of focusing on perfecting all of the non-technical tools and ensuring that my small featureset works. Companies in this space reach for the technical issues - those seem easy to solve and measurable - but this is precisely why they shouldn't focus on them. Because these goals are so tangible, accomplishing them does not solve new problems; it just makes the companies less differentiable, in doing so both sacrificing vehicle operating quality and losing any sort of identity to begin with.

Sponsored by the failure of the Stockholm E-bike service. ** 14:19 Corporate identity merchandise

Do not require it. People have the right to choose their own clothing and express themselves the way they want - especially as employees of your company. The strength of a company is not in operating as an island; rather, it's in ** 16:58 Dad called a few hours ago. My grandfather died last night.

What business do I have being so far away from home? What does being here do for me? What does being here do for the people I care about?

I can't come up with a good enough answer.

Lunch today was spent discussing the merits of sustainability of company merchandise. I regret even contributing to the discussion and prolonging the meeting. I'd never use a t-shirt but ultimately the t-shirts don't matter. I wish I could have redirected that hour of life to helping reduce climate emissions. Be more judicious about what you invest your time and energy into. The time you have really matters.

What's the point of life if your time isn't spent caring about the people you love? In a perfect world, your work should care for them just as much as your time does.

I didn't know what questions to ask my grandfather - about growing up in Chicago as a Swedish immigrant, about how he met and felt about my grandfather, about their beautiful cabin in Wisconsin, about train engineering, about his life growing up - and I'm ashamed that I didn't try before this January - which was far too late. I'll never get back a second of the time I spent playing with fucking trading cards instead of doing things with family. I have no idea what game I was playing at the time or what activity I was doing on my DS or the family iPad or whatever the hell I was up to when at their Boise house. I can't remember that time at all, but I can absolutely remember not spending more time with them, learning about or learning from them.

I realized how useless the days I spent felt when I found out that Isaac died. I didn't change anything about the way I lived my life. I have to change now.

πŸ“… day [[2023-05-16]]
  • How to create something that people will want to [[talk]] about?
  • Tuesday, 05/16/2023 ** 10:12 Search anything bar. Text input anything. Awesome as calculator ** 10:46 How do I search for a sound? Shazam exists - but what's the most seamless tool I can have for transmitting what I've heard out?

Want some kind of 'active memory' - audio, video - recorded around you that you can reference. Words aren't good enough ** 13:45 "The goal of the interview is to set the interviewee up for success." When someone is hired, they bring their expertise. Give them the kind of work that they would be doing every day anyways! They can pair program through the repository so that I can show you how we work? Brilliant.

Worth looking into this document:

Bring your own interview plan? Show that you've been interviewed in a particular way?? Incredible! People work in different ways, and the decision to force just one method on people can give a potentially excellent employee a bad experience.

Give more interviews! This is the best way to learn what you want from someone. ** 14:38 Now that I have a good foundation for project work, this journal will become a bit more of a devlog. This journal is a space for recording day-to-day progress and learning as I learn to build beautiful applications from the ground up, from component systems nad libraries to graphics technique experiments to fast, reactive systems.

What am I working on?

  • Building beautiful applications for people to use every day.
  • Experimenting with new forms of user interaction. What's the best way to interact with a computer? How can we share programs with each other?
  • Learning about graphics and hardware design. Beautiful software needs to have the correct physical interface.
πŸ“… day [[2023-05-15]]
  • To encourage [[change]], look for what suggests that they don't like how things are. collapsed:: true
    • Look for anything good they have to say about what [[change]] might do.
    • Look for anything that suggests that they could [[change]] if they wanted to.
    • Look for anything that sounds like a [[commitment]] to [[change]].
    • What makes it difficult for them to consider [[change]]? collapsed:: true
      • What would it take to go where they want to go? collapsed:: true
        • What worries them about how things are?
        • What makes them think they need to do something about it?
        • What happens from what they are doing now?
        • Is there anything about what they are doing now that is a reason other people might [[worry]] about them?
        • How has this stopped them from being where they want to be?
        • What will happen if they don't [[change]] what they're doing?
    • How would [[change]] help them? collapsed:: true
      • What would they like to be different?
      • What would be good about the [[change]]?
      • Where would they like to be in the future?
      • If the [[change]] happened now, what would [[fit]] them better?
      • What's a reason to [[change]]?
      • What would they get from a [[change]]?
    • How would they see [[change]] as [[possible]]? collapsed:: true
      • What would make it so they could [[change]]?
      • What gives them [[energy]] to [[change]]?
      • When else did they make a [[change]] like this? How did they do it?
      • What do they have that no one else has that would help them [[change]]?
      • Who could help them [[change]]?
    • When would they tell you that they want to [[change]]? collapsed:: true
      • What are they thinking about the thing that might [[change]]?
      • Are they feeling stuck?
      • What might they do?
      • How much do they [[want]] a [[change]]?
      • What would they try?
      • Of the things they might try, what would [[fit]] them best?
      • What do they [[want]] to happen?
      • What do they [[want]] to do?
    • Look for what they think might happen if they [[change]] vs. what they think might happen if they don't change. collapsed:: true
      • What do they like about how things are now?
      • What do they dislike about how things are now?
      • How can these be illustrated visually?
    • What is a day in their [[life]] like?
    • What do you [[worry]] most about the thing that might [[change]]? collapsed:: true
      • What's the worst that might happen?
      • How might that happen? What else might happen as a result of that?
    • What's the best thing that might happen?
    • How would things [[change]], if you changed?
    • Ask them about a different [[time]] in their [[life]]. Both what was, and what might be. collapsed:: true
      • What happens if things don't [[change]]?
    • How is what they're doing consistent with what they want? How does it work against what they [[want]]?
  • Monday, 05/15/2023 ** 18:06 What am I doing right now?
  • Package up returns
  • Put clothes in a pile to get rid of
  • Edit a photo
  • Render a square of pixels on the screen with raylib and change them every second
  • Make a plan for lunchboxes ** 22:15 Today I've been radicalized by GPUs. I've spent my life up until this point assuming that graphics libraries all start and end with turning pixels on the screen on and off. This is just not true.

The short of it is that the GPU on your computer - either 'integrated' (built into the CPU as an optimised subsection) or 'discrete' (a separate card entirely) hold a data structure called a framebuffer that represents the pixels that will be written to the screen. This information is written to a buffer then sent to the screen. The framebuffer is a data structure that represents the pixels of a monitor.

Cool, so I can just turn pixels on the framebuffer on and off?


First, the framebuffer isn't just exposed. Whatever windowing system you're using does not allow you to write to the framebuffer at will. That would be a security vulnerability at best - applications could write pixels into one another to make you see something - and at worst make your computer unusable without a standard protocol that tells them how to write to the framebuffer and where. (If you aren't in a graphical session, you can get raw access to the framebuffer:

You'll want to use a windowing library that abstracts requesting this framebuffer for you over various windowing systems (as Windows, MacOS, etc. have all concocted slightly different ways of doing this, nad they love making extra work for programmers) and gives you a reference to it. GLFW is historically the most popular, but systems like SDL2 and winit (Rust) provide similar functionality. You can then write pixels to this buffer following a standard, straightforward protocol nad they'll show up on the screen.

Unfortunately, though, the framebuffer doesn't live on the CPU or in the screen or whatever you think would be sane. Yes, screens have framebuffers, but it's your operating system's job to mediate between its representation and the data the screen is given. It lives on the GPU. GPUs are not optimized for drawing pixels on screens. They're complex mathematical hardware with complex APIs, optimized for rendering lines and rays and curves for modern 3D graphics, originally created to optimize for rendering perfect fonts with PostScript rather than in a bitwise fashion. The good news: they make playing video games fast, performing complex application tasks in parallel. How they do this is to be learned and probably under NDA. The bad news: GPUs expose complex, proprietary APIs that are inelegant and expose very large surface areas to program against. This makes learning to program for optimal graphics a mess, mostly because you're protecting corporate secrets. CUDA - the fundamental API exposed to empower parallel programming on the GPU - is not open. This makes computing a complex, ugly, mess - you'll always be programming against this nasty, abstracted API that's been artificially created, rather than being able to write to the machine and have the machine just render the text. This makes leveraging modern computing power a disgusting mess.

The good news here is that you can just ask GLFW for a reference to the framebuffer and write to it.

My goal with learning computer graphics has been to build small, beautiful applications that people - people who don't know much at all about using computers - can use every day to accomplish things in their life more seamlessly. Two paths to move forward:

  1. Learn to implement graphics tools by pretending modern graphics don't work that way and start developing abstractions over the framebuffer.
  2. Commit to learning a modern graphics library or abstraction. WebGPU and Vulkan are both compelling ways forward here. Vulkan has a solid Linux compatibility layer and is guaranteed Windows/Linux/other platform support. Metal (classic proprietary MacOS work) is DOA. WebGPU is incredibly compelling but the API doesn't have sustainability guarantees. It's made for the browser - so it's made to run anywhere and everywhere - but the API could be a moving target.

Whoah - Mach Engine solved this.

πŸ“… day [[2023-05-14]]
  • When people [[talk]] about [[change]], some things said point toward change, while other things said point against change. collapsed:: true
    • When changing, people [[talk]] about the following things: collapsed:: true
      • How things as they are don't work for them.
      • How changing things may work for them.
      • Talking about a [[want]] to [[change]].
      • [[Moving]] like they think [[change]] is something they can do.
    • When pushing back [[against]] [[change]], people [[talk]] about the following things: collapsed:: true
      • How things as they are work for everyone.
      • How things wouldn't work if they changed.
      • Talking about wanting things to stay the same.
      • [[Freezing]] and stuttering like they don't think [[change]] is possible.
  • Something that fits with a [[goal]] is often much harder to [[see]] than when it really doesn't [[fit]]. What's right is more [[invisible]], what's wrong is relatively easy to spot. In light of this, it makes sense that [[teaching]] at [[scale]] will focus on avoiding what's [[wrong]] instead of learning how to look for what's right.
  • Sunday, 05/14/2023 ** 15:40 What makes a wardrobe?

Why do I want more?

I only like two of my shirts. Three or four on a good day. The rest feel uncomfortable. Why did I buy this one?

It's beautiful - but unnecessarily. I don't want to stand out, to balloon or showboat or stunt or whatever you'd like to call it. I don't want to baby my clothing, spending too much money on a garment then having to carefully treat it. I don't want to be flashy. I just want comfort and consistency. This elaborate shirt is giving me a headache.

πŸ“… day [[2023-05-13]]
  • Triggering [[resistance]] in someone makes it more likely that they will commit to the position they talked about- after they've talked about it. So, it will make it harder for them to [[change]] if they talk with a position against the change.
    • "[[Turn]] in the [[direction]] of the skid" while [[driving]] on [[ice]]. Once [[traction]] is established, then turn.
      • The person who is to be changed has to be the one to [[talk]] about why they should [[change]].
        • To [[change]], [[people]] need to see a difference between what they [[want]] and what is.
          • When something someone is doing goes against something they deeply [[want]], it is what they are doing that will [[change]]. collapsed:: true
            • Mis[[alignment]] can be necessary for [[change]], since it is the first step to noticing a [[difference]] between what they [[want]] and what they do. collapsed:: true
              • What would make someone consider how the way things are doesn't [[fit]] them?
              • What would make someone consider a [[change]] to [[fit]] them?
              • What would make someone consider that [[change]] is possible?
              • What would make someone [[talk]] about how they are going to [[change]]?
            • [[Change]] can only come to people if a part of them really does [[want]] to change.
            • [[Change]] is easier when it is drawn out gently, instead of pushed.
          • A kind of [[talk]] to people to help [[change]]. collapsed:: true
            • collapsed:: true
              1. [[Accept]] where people are. [[Listen]] to them to hear where they are.
              2. Help [[explore]] what they [[want]] until they see a difference between what they want and what is.
              3. Go in the direction of their [[resistance]] to [[change]]. This is [[Kuzushi]].
              4. Give [[energy]] to anything they say that [[moves]] toward [[change]].
              • When something is seen as a [[block]] to their [[want]], they will be more likely to [[change]] it.
              • The perceived [[difference]] between what they [[want]] and what is has to be amplified to bridge the difficulty of [[moving]] to get what they want.
              • Ask about wants that might be blocked by the thing they are doing that needs to [[change]].
              • People are most persuaded by what they say. What do they [[notice]] that they say to themselves? What feels interesting to them? What are they excited at having said?
              • When there is [[push]] back, [[pull]] and [[move]] to [[change]] an [[angle]] very slightly.
              • Involve them in solving the [[problem]]. The [[solution]] has to be theirs, for them, to [[trust]] it.
              • When there is [[push]] back, [[shift]] to another [[angle]].
              • Someone cannot be [[responsible]] for [[change]] if they think they cannot change.
              • Offer help to [[change]], and give them the [[choice]] of taking it or leaving it.
          • A [[talk]] can move toward [[harmony]] or [[dissonance]].
πŸ“… day [[2023-05-11]]
  • In [[fighting]], it is often easier to [[move]] around a [[frame]] instead of trying to take the frame off.
  • Thursday, 05/11/2023 ** 18:37 STOP WHAT YOU"RE DOING AND DROP YOUR PHONE ** 22:31 Every time I pick up Rust again I'm radicalized by build times. I should be able to build a package from 0 - including downloading the compiler and its dependencies - off of a fresh git clone with a single command in 1 minute max. It's insane that Rust takes so long and pulls in gigs of information. This just isn't sustainable. My launch software didn't even work on my own system by default, even when using nix, when working in isolation... I'm missing some dynamic linking package that needs to be part of the path.

There are two paths we can take here;

  1. Use Java. The JVM solves our dynamic linking problem. HumbleUI is somewhat promising and I'll likely have access to most of the libraries I need. This code is 'fast enough' - but I'm not sure whether HumbleUI and Clojure desktop apps will have a future in industry at large.
  2. Use Zig. Write code at a low level with a toolchain that's focused on minimal interfaces and performance. Code is small and fast but at the cost of my time. Learning Zig is a huge pro. Supposedly the compiler iterates fast but there is also no package version control. Zig absolutely has a future but I'll have to learn more myself.

Zig is probably the way to go here. It'll take longer to get started, but the toolchain is fast and has a promising future. I'll be able to write very fast code and learn a lot about systems programming in the process. It'll allow me to help build good infrastructure, work with games code to make beautiful desktop apps, and contribute to a fresh ecosystem.


πŸ“… day [[2023-05-10]]

I will show you the shape of my [[heart]] if you want to.

  • Wednesday, 05/10/2023 ** 21:07 Refactoring to make new features easy to add feels so cool. By reworking abstraction boundaries, you play with interfaces; you introduce new concepts, new users, new features, making language and text and code a streamlined relationship between definitions and the code that works with them. Any form of abstraction creates a domain-specific language; creating the right language allows you to completely reframe a problme in your favor. Today at work I was having trouble with some complex data management and control task - so I changed the interface of the core data type, making it more extensible, and all of the features I wanted fell out automatically from such a beautiful abstraction. Don't let anyone tell you that reactive programming is bad practice - the paradigm is so clearly the right way to make GUI applications. With the right abstractions, you can change upstream functionality and downstream work adapts instantly if you continue to adhere to its interfaces. I can't wait to keep writing beautiful code fast.
πŸ“… day [[2023-05-09]]
  • Tuesday, 05/09/2023 ** 17:25 Work today was all about naming. Coming up with good names - for components, for ideas, for discussions - is extremely difficult, but without the right name, all the appropriate context gets lost in the noise. Names are abbreviations for concepts - if you want to talk about something, you must first give it a name. Names are better than backlinks - they're references in prose and in the mind, which is far more poweerful than any knowledge management or task pushing system can be. If your code and prose use the same - correct - names, you are suddenly able to speak about code and concepts with so much more clarity. This allows you to do things faster, better, with more control than before.

Then types - types add names to values wherever they go. The value of TypeScript doesn't come from the language's capabilities and static errors. There are some benefits to transpilation and to compile-time errors, sure - but far more important is the ability to see definitions on hover and receive competent suggestions from the typechecker. The better your types, the better you become at writing in the language that the code speaks - and the less discipline you have to have when revisiting and maintaining it. Your own types - your own language - is pushed back on you. ** 17:40 This ikea mirror is both the best fit for my home and a super affordable. Incredible combination! I love the oblong porthole look. (Stockholm curved mirror). The porthole is a brilliant touch - adds visual interest from the side and depth from the front. Shadows are worth exploring. ** 18:18 🦧 Awesome emoji ** 18:38 Some American-accented tea specialist is consulting with a future manager of a tea company in front of me. He's younger than me and is dressed very functionally - but he's a tea expert. She's bringing him in as a professional to work on and with tea, and he's extremely assertive about his work; I'm impressed by his level of expertise and control over the subject. He's able to explain tea to everyone here, and is making suggestions in both an assertive and an incredibly friendly manner. ** 18:45 "You would not love to meet [the people who will work under you at the restaurant]. You have to." Assertive!

πŸ“… day [[2023-05-08]]
  • A [[story]] interests someone when there is more than one way that what is shown in the story can go, and the audience would like it more if only one of those ways happen. collapsed:: true
  • [[Questions]] to ask if you are giving people a [[product]] or [[service]]. From [[Michele Hansen]]. collapsed:: true
    • What are they trying to do?
    • What are the steps of the [[workflow]]?
    • Where are they now?
    • Where in their workflow is the problem?
    • How often do they get blocked from what they're trying to do?
    • What have they tried? collapsed:: true
    • What do they want?
    • What did they use to try to get what they want? (esp MacGyvered stuff)
    • What does it [[cost]] if they get it wrong?
    • What goes into their [[decisions]]? In their words, [[why]] do they choose the [[solutions]] that they choose?
    • What happens if they don't solve the [[problem]] well?
    • Who else is part of the [[decisions]] they make about the [[problem]]?
    • How will they [[feel]] is the [[problem]] is or isn't solved?
    • Who might they [[talk]] to if the [[problem]] is or isn't solved?
      • What would they say about how they solved the [[problem]]?
      • What would they be proud or ashamed of sharing?
  • Is this something [[people]] [[want]]? Is this something they can figure out how to [[use]]? Will it make [[money]]? Is this something we can [[make]] or do?
  • Five people is often enough [[interviews]] to make a [[business]] [[decision]] that requires interviews, but another heuristic is "stop when you start hearing the same things over and over again".
  • Framing [[questions]] based on [[time]] often works better than asking [[why]]. This is probably because 'why' summons [[causal]] [[explanations]]. So, "what did you do before this?" instead of "why did you start doing this?".
  • Talk to your happiest customers to see how to bring more [[happy]] customers.
  • Help them forget you are a [[person]].
  • Monday, 05/08/2023 ** 11:02 Don't ever fall into the 'long tail' of an idea. ** 20:23 Back on my work. The company name isn't trademarked and the domain is cheap. Edited a photo today for the first time in forever. Can't wait to edit many more. What consumer software should I build first?
πŸ“… day [[2023-05-07]]
  • [[petrichor]]
  • [[ostranenie]]
  • [[flancia]]!
    • [[aj]] ~ [[ag]]
      • happy, joyful!
    • [[Avalokiteshvara]]!
    • I paid my taxes for the remainder of the year (or scheduled all payments). This small detail made me feel freer; it was indeed on my todo list.
    • In the spirit of a Sunday I made some [[magnetic art]] and I enjoyed it. It's interesting to do things with one's fingers, thinking about space and color as we go.
    • [[social coop]]
      • read some discussion
      • wiki next steps -> testing
    • [[donated]]
    • [[sila]] -> CL
  • the Agora is a bit slow -- pages are taking >7s to render when the cache is cleared.
    • It's also buggy, like [[petrichor]] above which strangely redirects to wikipedia :)
    • I love it anyway, but this says I have to allot some time to [[fixes]].
  • #push [[poemas]]
  • What does this [[product]] or [[service]] give [[people]]?
  • How else can [[people]] [[learn]] to turn [[loss]] into [[growth]]?
  • Lagging [[signs]] are easy enough, what are [[leading]] signs of something?
  • [[Who]] is this for? What will we get by giving them a [[way]] to get what they [[want]]? How will what we're doing [[give]] them a way to get what they want?
  • Sunday, 05/07/2023 ** 13:14 Most of this weekend has been spent thinking about names and interior design. I have a name for the studio that I'm happy with - finally - and the domain name is extremely affordable (No spoilers). Spent some time walking around, some time shopping, some time writing at Brod & Salt (I don't have a European keyboard yet, so it's difficult for me to hunt down the omljud on the fly). I'm excited to have the apartment finished and start working under this new umbrella to make something real. We'll start with an email sign-in box : )

Spending time online I can't help but wonder what I'm missing out on by not living in one of these innovation epicenters: San Francisco, New York, Berlin. San Francisco is the most beautiful place in the world but I've never seen a world so adulterated by tech that the fabric of the city outside of the office is ruined. Culture in San Francisco stinks - it's commodified and distilled into Blue Bottle and Allbirds, turning self-expression into a series of checkboxes, a manual, and the number on your bank account. The big players in SV, from my understanding, are brilliant and analytically stubborn to a fault, unwilling to consider 'unquantified' or 'soft' benefits to their lives - why do you think San Francisco looks like it does outside of the office? They need to learn to remove metrics from aesthetics and revert to their psychadelic dreams of the 70s. The wage gap is too broad there to ever realize this without proper housing. The only way to live in the valley is to live in a bubble and to curate the right bubble for you.

Cool - that leaves NYC and Berlin. Is Berlin monocultural? I haven't made friends with enough Berliners to know. I do know that enough people I keep in touch with online frequently commute between the three (SF included) to make them each a place where you'll be able to meet and know everyone. My work and ego aren't yet strong enough, though, to enter those spaces. I'll have to work twice as hard in Stockholm before leveraging the reputation I'm going to force my work to build. ** 13:28 Completely forgot to write about interiors. They're difficult! You don't notice the details until you really dedicate yourself to making a place home - why are the countertops like this? How are the tiles misaligned just slightly? Why is this asymmetric? Earlier I ranted against symmetry - but like all things symmetry is a balance. The four potted plants on my windowsill, all different breeds, were in radically different pots - and this looked absurd. Normalizing the pots - using four of the same pot and replacing terra-cotta with glass to better highlight the plants themselves - improved the room demonstrably. Terra-cotta feels uncomfortable to the touch. Caring for your belongings is more difficult if you don't enjoy them.

And the carpet! Generally the same rules of outside apply to inside. As you look from the ground to the sky, colors should get lighter and more vibrant. The really bright colors should be sparse and carefully curated - these are the areas that the eyes of a visitor should focus on when they enter the room. Everything else should be plain and muddy and pastel or black or white or anything that could blend into the background as a tool should. Surfaces should be distinct from the items on them without distracting from them - marble is too detailed and places the focus on the table ratether than the items on top of it, much like the wood grain of the table my laptop rests on as I type this.

Adorning the walls is just as important. Smell is more important than sound, and sound is more important than light; smell can indicate immediate or lasting danger, while sound implies near-term danger and light just controls whether something could be present or absent. It's therefore far more important to consider sound and echo than the details of furnishings in the house. (Segway: wow, these IKEA panels are brilliant: Design that is functional and accessible to anyone is far more important than design that is beautiful. More later.) The more detail you introduce to the home, the less noise you hear.

Finding the perfect furniture is incredibly difficult. I can picture the particular table that I want but I can't make it - I don't have access to metal fabrication facilities to cut the table to size and acquiring the raw materials would be super difficult. The process reminds me of why I love computers - digitally, anything I can imagine or picture I can make real. Experimenting with physical spaces is expensive and carries with it far more material limitation than the infinite computing power that I've become accustomed to having access to! + it's so difficult to imagine something filling in a space without having it. My walls are empty and I can hear it throughout the apartment.

Still don't understand:

  • Fringes. This piece of fabric is beautiful - why leave vulnerable tassles hanging off of it?
  • Triangular slants in furniture. Every design company and system uses a slightly different triangular slant. None of them match well with one another in a room or stack well. Snow peak knows this - they make glasses with vertical walls of varying sizes so they can slot into one another. Forget stacking. Just go smaller and taller.
  • Uncomfortable textures. Maybe I'm more sensitive to texture than other people, but lots of interior furniture is uncomfortable! I wouldn't want to have to hold half of the objects I see in stores or sleep on half of the sheets I touch. This holds regardless of the store's prices. Why would I buy something that I wouldn't want to use every day? ** 13:53 Granit store charged me for an extra item. Employee didn't seem to be concerned by it. Do I look too much like a rich American?