Added in more posts from Medium

src/content/blog/_index.md

@@ -1,5 +1,5 @@
 ---
-title: "tea leaves"
+title: "blog"
 description: "A collection of my thoughts, insights, and experiences."
 date: 2023-03-27
 menu: "main"

src/content/blog/dev_diary-finding-the-fun.md

@@ -0,0 +1,52 @@
+---
+title: "dev.diary—Finding the Fun"
+date: 2023-01-23
+draft: false
+featured_image: "/Images/techcrunch-gen-art.jpg"
+---
+
+When building any kind of product it takes a little time before you figure out its shape. Famous games developer Sid Meier described this process as “finding the fun”. He would iterate compulsively on his ideas until those little changes in the little details would uncover something sufficiently new and engaging that he had the basis for a new game.
+
+This is the approach I take with my products. From my childhood writing toys in BBC Basic, to working on the amaroK music player for KDE in the early 2000s, to making the Android version of TweetDeck in 2010, to how I approached making Homebrew and now with its spiritual successor: tea.
+
+We released tea/cli a couple months ago. At that point I felt the product was “ready enough” for general consumption. We had a number of compelling features coupled with a good mission statement and together to me that seemed enough to present it to the community and start gathering wider ideas and interest.
+
+Which is a key differentiator between developing most products and developing open source: you bring your userbase in before you’ve “found the fun”.
+
+Before launch I jokingly would say that tea was not a package manager. I was being flippant. But also I wasn't being flippant. Package Managers as a class of tool haven’t evolved since their inception in the 90s. They are very much in the what I call “egotistical tool” category: that being: you *will* learn how it works thank you very much because the package manager is a very important tool and you are lucky to have it. I’ve not a fan of this attitude.
+
+I believe tools are a special class of utility. A well written tool completely eradicates entire classes of tedium enabling its users to reach new heights in productivity. A well written tool enables functionality that before was either too tricky to accomplish or completely impossible.
+
+At launch we said tea was a universal interpreter, a universal environment manager, a unified dependency manager and it could run executable markdown.
+
+Changelog rightly called me out on this, saying “might Max and the team be thinking too big this time around?”
+
+The truth is we hadn’t yet quite found the fun.
+
+Two months of passionate early adopter usage later and a few things were becoming apparent. tea’s real super powers were the underlying rethinking about the nature of package management, specifically that with tea the package manager disappeared. So I decided to experiment with doubling down on that.
+
+At launch you could type tea -X npm startand tea would look for npm and run start , but if it didn’t find npm it would fetch it first. This was in fact a very near launch addition by me but it was a truly wonderful reduction in friction for using the open source ecosystem. And fundamentally what this feature said was: the package manager needs to get out the way.
+
+tea doesn’t install packages—at least not in a conventional sense. In the above example npm is not available unless you type tea -X npm otherwise it is “stowed” in ~/.tea . This is important since I want using tea to complement your system. tea is not an operating system, it is a complement to whatever system (Mac, Linux, Windows, etc.) you are using.
+
+Soon after a passionate early adopter of tea suggested that symlinks to tea should behave as though tea -X foo bar was called. So we implemented that and immediately it was apparent that this was a seriously cool feature. I used this to create a symlink from tea to bpb (a tool that makes signing your git commits trivially easy) and immediately knew that forever more I would not have to piss about for an hour getting my git-signing set up whenever it stopped working or a had to set myself up on a new machine, remote server or when clean installing my OS.
+
+A developer at tea realized that you could make the shell’s command-not-found handler call tea -X . Command not found handlers have been used by the package manager before. For example, Ubuntu uses it to suggest packages that may satisfy whatever you typed. The idea made me laugh because it seemed so ill-advised! But we added it to the README as a hack that users may want to try out—for fun.
+
+But I got to wondering… had we in fact found the fun? I decided to add the command-not-found handler to my shell and see how I liked it.
+
+After a few days I stopped laughing. I started getting excited. This hack wasn’t a hack. It was awesome. It completely delivered on tea’s promise and significantly simplified our narrative.
+
+How do you use tea? You don’t. You use the tools that the open source ecosystem provides. If you read a blog post about a new tool then just type the commands you read into your Terminal and try it out. There’s no “figure out the package name and then install it step”. There’s no “will installing this break other stuff on my system” concerns. If you don’t like it then don’t worry about it—it’s already gone.
+
+
+
+tea still is a “universal interpreter” but that just falls under the general banner; we don’t have to explicitly name this feature; tea just knows how to make what you throw at it work. Be that a command or a script, tea makes it possible for you to get on with what matters: making your app.
+
+And so I dropped executable markdown completely. Part of the reason I added exe/md was the desire for tea to be a tool that makes development a dream. And we have achieved this because now if you want to use executable markdown to run the script build you just type xc build and tea installs xc transparently. Whatever “task runner” your project needs is transparently available. Having this feature in tea itself no longer made sense.
+
+When it comes to making great products you need to be able to drop entire features without ego or the sunk-cost fallacy holding you back. What matters is the entire product vision no matter how cool you think something is. I still think exe/md is a cool idea, and didn’t know about xc before writing it. I’m very glad someone else thought the same and built it. UNIX tools should do one thing and one thing well.
+
+tea 0.19 lives up to the UNIX philosophy and thanks to Changelog for reminding me about that. I revisited every part of the CLI and retooled it towards this purpose. Check out the new README for the deets, the caveats and what comes next:
+
+https://github.com/teaxyz/cli

src/content/blog/dev_diary-tea-is-env++.md

@@ -0,0 +1,81 @@
+---
+title: "dev.diary—tea is env++"
+date: 2023-01-31
+draft: false
+featured_image: "/Images/techcrunch-gen-art.jpg"
+---
+
+A few aspects of the shape of tea’s CLI have been bothering me.
+
+While building out the pre-release tea began to take shape as a “universal interpreter”. I have long thought package managers were depressingly basic in operation, a strange thing for such a (potentially) powerful part of the stack. It seemed somehow backwards that if I obtain a script, I first must figure out what package runs it, and then possibly even install a bunch of dependencies in order for it to run. Why can’t the package manager figure this stuff out for you? And thus tea script.ext did just that.
+
+want https://charm.sh’s amazing vhs terminal recorder? Just type `vhs`
+While iterating around this I realized that it wasn’t laziness that was holding me back from implementing tea install , it was a desire to find something better; a better paradigm for using open source; a better paradigm than managing it. So I held off. My coworkers complained that they still needed brew even though we were building its spiritual successor.
+
+Yet I held off because I know that if I make parts of my workflow tedious, I will come up with a solution. I suffer a little now to reap the rewards later.
+
+I would joke with people that “tea wasn’t a package manager”. This was tongue in cheek—of course tea was and is a package manager. But it didn’t seem much like one. I wanted people to stop thinking about the package manager altogether. I wanted to make something where managing packages stops being a part of your workflow at all. You have apps to build, and I want you to build them with tools like mine getting out of your way entirely.
+
+In pursuit of being a universal interpreter without installing packages one must build environments that create a kind of container for the software. It seemed useful to make those environments available more generally.
+
+With tea you build an environment by adding packages with +pkg.com syntax. With the environment assembled you then execute a command. Plus package syntax was a wonderful discovery allowing entirely new categories of workflows.
+
+What was tea? It seemed to have become a tool for assembling environments of open source software which you then apply to other tooling. If we can figure out those environments for you, we do, if we cannot we need you to tell us.
+
+tea was a universal interpreter. So I looked to other interpreters to see if the similarities should go further.
+
+It’s typical with interpreters for just typing them to start a REPL (a read eval print loop). You exchange your Bash prompt for a Python, Ruby, etc. prompt. Should tea do this? We tried it, so tea +deno.land would start a new shell with deno available. It was somewhat a good feature and it was idiomatic with the concept that tea was a kind of interpreter.
+
+But something about it irked me.
+
+tea described itself as a unified package manager, a universal interpreter, a universal environment manager. It was all these things, but you can’t sell a product if you can’t put your finger on what the product *is*.
+
+Last week I talked about how we resolved the messaging by more clearly seeing what tea was. tea is a magical package manager, it’s invisible and powerful. Stop thinking about installing stuff—get on with your work instead. If you don’t need to even think about managing packages entirely you can use new tools and workflows effortlessly, but also other people who make tools, scripts or workflows can know you, the end user for their efforts, have the entire open source ecosystem at your fingertips too. They don’t need to tell you how to install a bunch of stuff, with a bunch of different versions, for a bunch of different platforms in their README—you have tea.
+
+This week I realized that during the history of UNIX there was another innovation in this area. As developers for UNIX like systems exploded, new tools began to appear all over. Each UNIX had different conventions and preferences for where such tools may be installed. This would be problematic for the shebang.
+
+Shebangs
+Perl was one of the first interpreted languages. It grabbed the minds of all UNIX users since it was fast to dev like shell scripting but powerful like “proper” languages (eg. C). It supported being “shebanged”, the #! at the front of a text file that told your shell who interprets the file you want it to run:
+
+#!/usr/bin/perl
+The problem is: perl was new and not POSIX with an associated “this is where it should be installed” path. It might be installed anywhere! Shebangs were not designed to search PATH (for security reasons presumably) but this impeded the possibility of distributing a perl script to other communities.
+
+So/usr/bin/env was built. It was designed to construct environments† and then execute commands inside those environments searching the specified PATH for the command to run. POSIX declared its path to be /usr/bin/env so now shebangs could be:
+
+#!/usr/bin/env perl
+Thus alleviating the location problem.
+
+However the user still needed to install perl themselves.
+
+† though not commonly used env FOO=bar baz and other environment management features are a primary part of env’s CLI.
+
+tea is env++
+#!/usr/bin/env -S tea perl
+
+## see `man env` to understand the `-S`
+Like env we construct an environment for perl and run it, but as supplemental functionality we install perl and its dependencies first.
+
+One day perhaps we’ll be POSIX and we can reduce this to:
+
+#!/usr/bin/tea perl
+One can only dream…
+
+Adapting tea/cli Based on this Realization
+tea is a more capable env. Should this be something we document? Should this adapt how we introduce it and talk about it? I began exploring that.
+
+Firstly, our REPL like feature tea +rust-lang.org starts a new shell that contains the environment for rust. Should instead we output the environment like env does?
+
+I tried it and it felt right. We already use this functionality for tea’s magic, so now instead of that being a special mode it was a idiomatic use of tea as a CLI.
+
+However the REPL functionality is neat, so do we really dare lose it?
+
+Fortuantely an idiomatic way to do the REPL presented itself to me, simply append sh, eg. tea +rust-lang.org sh. This is all our REPL was doing underneath anyway. Now tea doesn’t have any special modes, we are communicating to the user intuitively that tea installs packages, creates environments and executes commands within them. To see the environment that will be created, stop typing (eg tea +rust-lang.org). To use the environment, add commands.
+
+Typing tea by itself dumps the current supplemented environment. If you have our magic installed then inside a developer environment you can see what tea did to create that environment.
+
+I’m super happy with these changes as now I feel tea is close to being very well scoped, intuitive to understand, composable, flexible and useful to many different tasks along the lines of its utility proposition. We are both more powerful than all other package managers while also being more intuitive.
+
+I foresee a v1 in the near future.
+
+Breaking Change
+This is a breaking change, but we are pre v1. After v1 we will not break the CLI API unless we bump the major version.