Blog

This release has three main changes:

1. A much improved onboarding experience. Better readme, more sensible vocabulary, and dtg init writes a working definition with the option to start with the Material or Tailwind examples.
2. UI and UX improvements to the editor. Yes, it’s just called the editor now (invoked with dtg edit). Particular attention was paid to how the color picker behaves and functions.
3. An important under-the-hood change: colors are now stored as unbounded OKLab values and each algorithm decides which math space to compute in. Previously, dtg guessed a color space from how the inputs were written and converted everything to it before computing. That could clip wide-gamut colors, and colors written in different notation could produce different results. Gamut now only matters on output.

Version 0.3 of dtg is out. Check it out on GitHub!

This is a substantial release. By the end of 0.2, I knew that the next version would entail major changes. I didn’t appreciate their extent until the work was underway:

• A new top-level palette keyword in the definition file. Palettes collect colors into a set for viewing and manipulating. They are for an earlier, more exploratory stage of color work, where designers puts colors side by side and adjust them until they work well together. Palettes also serve as inputs to roles and systems, and replace the use of constants today.
• System addressing now uses method parameters instead of paths. Use sky(3 tint) instead of sky/3/tint. Dot notation is still used for traversal, e.g., warm-wash.red(6). This syntax makes it easier to distinguish what’s being used from what’s being configured, while more closely resembling CSS color functions.
• A simpler set of out-of-the-box algorithms. ink-ramp became tint, oklch-scale became scale and blend was removed by a group of tint systems. The algorithms are also more focused, with simpler interfaces and fewer responsibilities. Definitions are more concise, and output is now explicitly controlled by the definition file rather than the algorithms.
• Modes support color-scheme and inheritance. Modes can now be associated with light or dark color schemes, and they can inherit from other declared modes as well. This makes it easier to build related themes, including high-contrast variants or themes that differ by only a handful of colors.
• Edit the definition file through the bundled web editor. As much as I like the syntax, color work is fundamentally visual. In 0.2, the web editor let you preview colors and how they are used. In 0.3, it supports editing and saving directly. I’ve paid particular attention to the color picker, making it easy to adjust colors, especially when working with dtg dev --build. A few things are still missing before it is possible to author a definition file from scratch, but we’re getting there.
• Quality of life updates to the web editor. Systems can now be simulated without requiring a reference. Color scales are displayed more clearly, and hovering over any swatch reveals its color information.
• And tons of changes to smooth out the rough edges while using dtg:
  • The config file dtg.yaml is renamed to dtg.config.yaml so that it’s both more differentiated from the definition file, and closer to other config files inside a codebase.
  • There is no longer a default path for definition files. Specify them in the config file.
  • dtg emit becomes dtg build and the --live flag got renamed to --watch to align the verbs to other tools.

The CLI can also generate static pages for publishing (dtg docs --out <dir>). Here are the colors that fifthrevision uses, along with a preview of Mosaic’s (my design system) colors and component library.

Truthfully, we’re still in the early stages of the project, where many of the building blocks are still being reconsidered and refined. Version 0.2 demonstrated the value of a color tool that captures how colors are derived. Version 0.3 focused on making the idea practical, with a coherent foundation and usable interface. The basic shape should now be largely stable, with fewer breaking changes going forward. The focus for the next release will be on from-scratch authoring and extension points, as well as support for gradients.

This tool has been invaluable to me and my coding agents as we iterate on Mosaic, and hopefully it will be for you as well.

I should make a habit of writing about releases when they come out. The weekly cadence means announcements sometimes get bunched up.

0.33 and 0.34 are substantive Axle and CLI releases that let me acheive a personal milestone: I have a agent doing financial research on a schedule and sending me a text message with recommendations.

On the CLI side, 0.33 added scheduling to Axle CLI on macOS via launchd. Tasks can now run on interval or schedule through the axle schedule subcommand, and can be retrieved using session and resumed as other Axle sessions. To make this useful, every CLI recipe gets a tool set unless specified.

0.34 completes the scenario above by adding Skills. CLI now supports the Agent Skills spec. Drop a skill in your local .axle/skills or .agent/skills folder and Axle will pick it up. Then, there are a lot of other changes under the hood to make sure the shape and ergonomics are right.

On Axle core itself, 0.33.0 and 0.34.0 bring in a grab bag of improvements. Skill support as a first class Agent concept. Pending Turns show up on Transcript, making it simple to render queued messages. New lifecycle hooks (async onSettled and onIdle) on the Agent object enable better lifecycle interactions. The static model registry got replaced with a dynamic one backed by models.dev so that consumers can look up real-time model info and pricing. There are tons of work under the hood as well: stability, robustness, protocol improvements, as well as a few breaking changes coming from implementing better mental models. Building a library is a process of understanding the problem, and then understanding the problem over and over again*.

And oh, TypeSafe’s decision API is in Core as experimental. I’m looking forward to integrating it as a first-class citizen for classification into Agent – more on that soon.

Full release notes can be found here.

The first commit of this version of the website happened in February 2017 (169e91e7). It went from a set of handcrafted HTML and CSS files (edit: I was wrong, it was a Wordpress site!) to a site statically generated with Jekyll.

Jekyll gave me the vocabulary and the confidence to do bigger things. The loose collection of pages turned into a coherent set of essays and portfolio entries. Then, a reading list and reviews I would write of them (that ended up being a tough thing to keep up on). Later, a microblog.

In the last few years, I’ve noticed creakiness in the Jekyll ecosystem. Once, I upgraded the Ruby version and the build broke. Plugins stopped getting maintained (I’m looking at you, jekyll-paginate-v2). Liquid 4.x is limited in what it can express (5.x looks like it’ll never get supported). Lastly, I’m not a Ruby person and I don’t want to maintain custom extensions.

Recently, I’ve used Astro for a few content-heavy static sites and I liked what I saw. Well, first and foremost, I’m a TypeScript person. My requirements for this site remain the same: static-site generation primary, JavaScript as an enhancement layer, and building on top of a variety of content types. Back then, I flirted with the idea of porting the site to Astro, but the idea of undoing years of technical debt felt daunting so I never took the next step.

Yesterday, I bit the bullet and ran the migration using Claude Code. It was done in a few hours with Fable 5.1 driving Opus 5.5 subagents and the entire process went as smoothly as one can hope. Layouts went from Liquid to Astro components. The content folders became more sane; it’s interesting how many Jekyll conventions can quickly become limitations once the use cases outgrow what they were designed for. I took the opportunity to convert SCSS to plain old CSS — CSS is mostly at parity these days with a few features in the pipe. The codebase reads better, runs better (no more fumbling with bundler, why no run scripts?), and the generated output is basically byte-identical.

Then, I shipped my first site change in years, a revamped projects list. Which is to say, fifthrevision is now officially on Astro. So far so good! I’m sure I’ve traded one set of constraints for another. Time will tell.

For nearly a decade, you served me well. Thank you, Jekyll.