I was skimming old blog articles and realized it\nhas been a while since I've done small posts. Some\nquick updates:
\n"AI-Driven Innovation" is an oxymoron to excuse over-relying on "legacy\ncode as a service". I don't think there is any sort of paradox here in\nthe way that "AI-Driven Innovation" as a strategy is in consequence risk\nadverse and not a strategy for innovation and creativity. I don't see a\nneed to bury any ledes here and I think this is awful on multiple levels.\nI worry it is going to take too many years for companies to realize the\nmistakes that they are making right now. It's had me making too many\njokes to hide the depression that I feel that I need to find a new\ncareer altogether.
\n"AI-Driven Innovation" is an investment in a rental economy of "legacy\ncode as a service". Legacy code is always an indicator of some of the\nmost risk adverse pieces of a company's software portfolio.
\nI have spent so much of my career in "the legacy code mines". It's\nalways been a skill set I've tried to downplay on my resume. It's always\nbeen a skill set I've kept being asked to return to because I've earned\na lot of experience in it, often the hard way. For decades, I've joked\nthat my "retirement" plan was to find a cushy high paying, low effort\nCOBOL job.
\nBut now I don't think those joked about jobs are going to be so easy to\nfind, not because the LLMs are going to replace all that COBOL code but\nthat the LLMs are going to help companies build so much more, equivalent\nor worse legacy code faster than ever. The LLMs are (unfortunately for\nmy retirement fancies) commoditizing legacy code. They are making it\nplentiful. They are giving tomorrow's legacy code experts more work than\never before at an unprecedented scale.
\nI've been accused about being overly unfair to LLMs by calling their\noutput "legacy code as a service", but think about it: which companies\noffered their truly innovative, proprietary, most modern, most\ndomain-driven codebases to LLMs for training? LLMs were trained on open\nsource and a lot of open source is just a funny place to stash "someone\nelse's legacy code" or at least in the most generous cases "some other\nbusiness' complement".
\nIf AI can't train on the innovative software, how can it help you find\ninnovation in your own software strategies?
\nShow me the part of the LLM family of algorithms that is the "creativity"\nand I can show you a slot machine and try to teach you about the Gambler's\nFallacy.
\nPeople are inherently bad at reasoning about probability-based algorithms\n(and probability and statistics math in general) and some of the current\nlove affair of LLMs seems explicitly to be that people don't understand\nthe randomness of algorithms deeply associated with probability and are\nhappy to anthropomorphize it or assign to it a creativity or "surprise"\nthat is really just random variation on a theme (and eventual regression\nto the mean).
\nYou could put a lot of creativity into the input of the system, so called\n"prompt engineering", but what good is laundering that much creativity\nthrough a machine designed to produce the most statistically average\noutputs from it?
\nThat of course entirely relies on people seeing "prompt engineering" as\na creative tool for innovation. Most of the companies seeking "AI\nInnovation" wrote off software as "overhead" and "cost centers" decades\nago. In a lot of those companies the creativity of the software engineer\nis a defect in what should be cogs in a well-oiled machine that takes\nbusiness requirements and spits out software. "AI-Driven Innovation"\nonly continues to further misplace and confuse the sources of creativity\nin software development. These companies aren't going to learn anything\nfrom the mistakes they are about to make. (The mistakes they are already\nmaking.)
\nWhen you hire a software engineer, they have an ownership and a\nresponsibility to the code they write. When working on legacy code, that\nperson with any sort of ownership is already gone, and that is almost\nalways an impediment. Some of the key skills on working on a legacy code\ncodebase are essentially mind-reading, trying to read everything that\nperson wrote around the time they wrote that software that you can get\nsome semblance of feeling like you can at least temporarily think like\nthey used to think in those days on that project.
\nLLMs are incredible in how much they are a (soylent) sausage factory for\ntaking all those human pieces (the poetry hidden in the required poetry\nforms) and smearing them into a reconstituted meat slurry. The output\ncode has no ownership and is divorced from any ownership it might have\nonce had in a gelatinous puree. There's no way to read everything "that\ndeveloper" wrote at the time an LLM output what it did. We don't have\naccess to the full training sets. Even if we did, the major models\nthemselves fully retrain at a roughly six month cadence and aren't the\nsame from "version to version". Sometimes they aren't the same from\nmonth to month due to partial retraining that the model makers don't\nfeel is worth a version bump. (An LLM is a Ship of Theseus by design.)
\nEven if you could somehow connect the code that the LLM has produced to\nspecific open source code via the training set that you don't have access\nto, one of the first safety gates in almost every open source license is\na "No Warranty" clause. It's one of the foundations that keeps open\nsource a viable practice. (Just as software developers generally don't\nkeep ownership when they are severed from a company is a sort of a\nfoundational creator of legacy code.) Many open source projects will\noffer services similar to a "warranty" or "support contract" for some\nmaterial cost (sometimes even just as volunteer effort returned the open\nsource community). Yet the LLM can't provide even this disclosure, can't\nsell you that service, can't tell you what exactly you have "licensed"\nor how many "No Warranty" clauses are between you and whoever originally\nowned the code it just output. There's not just "no owner" there is a\nmulti-layer onion of "negative ownership". Your EULA with the LLM\ndeclares "No Warranty". Most of the code the LLM trained on declares\n"No Warranty". Who really owns anything? It's all just a rental to some\nlandlord, as a service.
\nThen there is the added awful layer in that onion that much of the code\nthe LLM trained on was also effectively stolen, according to the licenses\nand agreements in place around that code. A lot of the open source world\nis built on "copyleft" licenses designed to legally encourage "what you\ntake from the open source community you volunteer to bring back and\ncontinue to enrich the community with your own contributions". LLMs\ntoday are ignoring these legal requirements. LLMs are not attempting to\nenrich the community with their sausage factories, they are trying to\nclaim that they don't need to because the sausage is so different from\nthe animals it was processed out of. In the process of reconstituting\nthat meat slurry they claim that they've liberated it from such concerns\nas "this is an illegal slaughterhouse" and "this is a health code\nviolation" and "this is just generally a violation of common sense human\ndecency".
\nIs that a great foundation for "AI-Driven Innovation"? Does a\nnasty-smelling onion of "no one owns this code", "no one wants to know\nwhat the real ingredients in this code are", and "if they did know all\nthe ingredients in this it would be illegal" sound like "innovation"?\nThere was an era in American economics when companies innovated on how\nmuch diseased rat meat they could get away with in their sausage. I\ncan't be alone in thinking this will all end poorly. I'm also sure I'm\nnot alone in thinking this won't end poorly fast enough to save us from\nso many of the worst mistakes.
\n"AI-Driven Innovation" is a garbage plan of creating garbage inputs to\nsoftware that produce nothing but statistically probable legacy code, as\na service. It's a simple oxymoron. There's no real "innovation" to be\nfound in the output. It's going to keep checking boxes in PowerPoint\nslides to an investor class that has bought into "AI-Driven Innovation"\nas a shared delusion of their (inherent disconnect from) reality rather\nthan accepting it to be a sad improbable dream that makes no sense when\neasily questioned. In the meantime a lot of software is going to regress\nto some ugly averages and real software innovation will take a huge hit.
\nIn the mean time, the truly innovative, experienced software engineers\nare encouraged to accept layoffs if they can't "align" on "AI-Driven\nInnovation". (Leaving plenty of now immediately legacy code behind in so\ndoing.) In the mean time, tomorrow's truly innovative software engineers\nare told to avoid growing real experience and instead feed LLMs to\ngenerate so much mediocrity, if they have jobs at all. In the mean time,\n"AI-Driven Innovation" is crafting a mesmerizing illusion that software\nas a labor practice is over and companies don't really need software\ndevelopers at all.
\nGarbage in, garbage out, in a feedback loop threatening to spiral to\ndestroy real innovation in software development.
\n","date_published":"2026-04-29T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2026/04/07/redux-net/","url":"https://blog.worldmaker.net/2026/04/07/redux-net/","title":"A Pattern for Redux with Epics in C# Dependency Injection","content_html":"This is a day job project that for a bit I thought might spin out into\nan open source library but the funny thing about it is that it has been\nmore of a chisel the statue out of the marble type of project. It\nstarted from a complicated place and the further we've pushed it towards\nRedux best practices the more it disappears into "just" being primarily\na pattern of C#'s out-of-the-box dependency injection.
\n(For some small context, the original design that this design migrated\naway from was far more inspired as something of a telephone game to\nAngular's libraries such as NgRx, which themselves were a telephone\ngame away from Redux.)
\nIt still seems worth publicly documenting for the next team looking for\nthis pattern. I wish there was a library I could point to to install\nthis pattern into your project, hopefully this documentation will\nsuffice as a good starting point. To some extent, the lack of a need for\nan external library is a small triumph and a proof that this can be a\ngood way to build your C# "view state" model, for projects that want a\nReactiveX-"native" alternative to state management and/or event bus\npatterns such as MVC, MVVM, Mediatr.
\nRootActionThe core type for this Redux design is RootAction. This is not a\nparticularly great name, but it does avoid conflict with\nSystem.Action<T> (the void-relative of System.Func<T, U>). In\nproper Redux fashion, this is a very simple type with only a required\nfield name Type.
public record RootAction\n{\n public virtual string Type => $"{GetType().Name}";\n}\nThere are a bunch of strong notes to be made here, some of which remained\ndebates for some time after moving to this pattern. The NgRx family never\nfully understood the importance of Actions as a serializable type, but\nit is a useful core principle to many Redux pattern benefits. Serializable\ntypes can be output to logs for replay, for instance.
\nRelated to replay, that is something the day job project never got around\nto implementing. At one point Source Generators were explored to replace\nthe reflection-based Type seen here with something more useful to\nSystem.Text.Json's polymorphic support.
The advantage to this form of base Type implementation was that a tree\nof types was relatively easy to build. Example:
public record CoolFeatureAction : RootAction\n{\n public override string Type => $"CoolFeature/{GetType().Name}"\n}\n\npublic sealed record CoolFeatureInitialized(bool IsCool) : CoolFeatureAction;\nOne of the things that this also highlights is that the Redux world\nbest practice of writing "action creators" is handled automatically by\nC# record syntax. The primary record constructor is already laid out as\na Redux-like "action creator", and provides similar refactoring benefits.
\nA few of the other tips about Actions from the Redux pattern best\npractices that may be useful to keep in mind at this point: Actions are\ngenerally named like Events, they are named as the "user interaction that\njust happened" in the past tense. Actions should generally not be "mere\nsetters" (FieldASet, FieldBSet) but rather State transactions as\na high-level event (EntireFeatureInitialized with everything needed\nto update FieldA and FieldB all at once).
Another brief digression from JSON polymorphic debates was if the\nRootAction's Type property implementation should have been, assuming\nReflection was still fine:
public record RootAction\n{\n public string Type => $"{GetType().FullName.Replace('.', '/')}";\n}\nIn which case the inheritance tree might have been a little flatter in\nexchange for using the namespace hierarchy automatically. (With the idea\nof the Replace being to still prefer the Redux dev tools suggested /\nnamespace separator instead of .NET's ..)
In part from references libraries that heavily relied on .NET's value\ntypes (typically, but not just, readonly record struct) to deeply\navoid nulls (at the risk of sometimes equally confusing "zeroed"\ndefault(T) from structs) the application had picked up the premature\noptimization of using value types for a lot of internal state data.
This was a performance problem that we caught early in the Redux\npattern refactor. It is easy to forget that value types are generally\npassed by value which means by copy in many cases. Especially in a Redux\ndesign you often can't afford all the memory of every State and every\nAction to be copied for every Reducer (and Epic and view component, etc).
\nDon't forget that public record is shorter than\npublic readonly record struct for a good reason and is a good default.\nReference types aren't an enemy to performance in .NET, they are just as\noften the solution. Don't forget to apply performance profiling tools\nfor real data from your applications and not just default to value types\nbecause they sometimes help performance or null safety.
The heart of the Redux pattern is Reducers to apply Actions to State. In\nC# we used a very simple IReducer definition from which a number of\nthings inherited, include a Reducer<Action, State> base type for single\nAction reducers.
public interface IReducer<State>\n{\n public State Handle(RootAction action, State state);\n}\n\npublic abstract class Reducer<Action, State>\n : IReducer<State> where Action : RootAction\n{\n public abstract State Reduce(Action action, State state);\n\n public State Handle(RootAction rootAction, State state) => rootAction switch\n {\n Action action => Reduce(action, state),\n _ => state,\n };\n}\nThe base class is a pattern in C# you also see in things like Authorization\nPolicy Handlers, a type-safe "trampoline" from the generic RootAction\nto a specific Action (we had less of a problem with a type parameter\nsometimes shadowing System.Action<T> than a top-level type doing so).\n(This is also Typescript influence here of dropping the T-prefix\nsemi-Hungarian notation for type parameters; though as with most C#\nnaming schemes the I-prefix for interfaces is maybe eternal at this\npoint.)
Because the trampoline is often the shortest way to write many Reducers,\nthe IReducer<State> method borrows the name Handle from places like\nPolicy Handlers so that Reducer<Action, State> can use the more domain\nfriendly Reduce as its more specific abstract function.
It's also important to note that IReducer<State> is intentionally and\nonly synchronous. That's an ancient Redux best practice. That will also\nbe something we return to as we get to Epics.
To round out our CoolFeature example we might have an example Reducer\nlike so:
public record CoolThing(string Name, /* … */ DateTimeOffset Created);\n\npublic record CoolFeatureState(\n bool IsCool,\n DateTimeOffset CoolStarted,\n IEnumerable<CoolThing> CoolThings)\n{\n public static readonly CoolFeatureState Disabled = new(false, DateTimeOffset.MinValue, []);\n}\n\npublic class CoolFeatureInitializedReducer(TimeProvider timeProvider)\n : Reducer<CoolFeatureInitialized, CoolFeatureState>\n{\n public override CoolFeatureState Reduce(\n CoolFeatureInitialized action,\n CoolFeatureState state) => state with\n {\n IsCool = action.IsCool,\n CoolStarted = timeProvider.GetLocalNow(),\n // ASIDE: Injecting a TimeProvider is a great way to increase\n // unit testing powers of this reducer because you can test in\n // fake time with a FakeTimeProvider.\n };\n}\n\npublic static class CoolFeatureExtensions\n{\n public static IServiceCollection AddCoolFeature(this IServiceCollection services) => services\n .AddTransient<IReducer<CoolFeatureState>, CoolFeatureInitializedReducer>();\n}\nNote that while Reducers are required to be synchronous, they are still\nfree to inject and use other dependencies (so long as they are also\nsynchronous). Similarly, reducers may be state machines that use complex\ncalculations based on the current state to produce the next state. The\nbig restriction is synchronous.
\nLens<A, B>Before we can talk about the Store and Slices, we need one more tool in\nour toolbox.
\nIn Typescript, ala the original Redux pattern, we can easily "slice" a\nState via a string key of that state. Typescript is also friendly in that\nthis can be relatively type safe thanks to meta-typing tools like\nT[keyof T].
Doing that type-safely in C# is a bit more work. One of the tools we can\nuse to do it that is useful as a generic type for immutable data structures\ncan be borrowed from functional programming and is called a Lens. A Lens\nis really just a type-safe getter from one item to another (given an\nA, I want a B), and a type-safe setter in the other direction\n(given a B, I would like an updated A).
There are several functional programming libraries that provide a\nLens<A, B> useful in C#, including LanguageExt, but Lens<A, B>\nreally is just as simple as described, so we can also just implement our\nown quite simply:
public record Lens<A, B>(\n Func<A, B> Get,\n Func<B, Func<A, A>> SetF\n)\n{\n public A Set(B value, A container) => SetF(value)(container);\n}\nThere's a few other convenience functions you could implement (often\nnamed Update), but that's the important heart of Lens<A, B>.
The importance of SetF in this form as Func<B, Func<A, A>> as the\nunderlying setter is maybe not obvious if you haven't spent enough time\nin languages that support currying such as F# and Haskell, but is one of\nthe useful properties for making Lens<A, B> generically useful to\nseveral of our needs.
One useful way to see it from Redux points of view is that\nSetF(someFixedValue) creates just about the most simple type of Reducer\npossible (given a State, yield the next State). It's a handy abstraction.
ShareReplayWe are taking a ReactiveX native approach to our Store that follows to\nencourage consistent use of Epics (more on them later). I bounce enough\nbetween RxJS and classic C# ReactiveX that I find these utility extension\nmethods handy to keep around to save my poor memory some small bit of\ntrouble:
\npublic static class ObservableExtensions\n{\n public static IObservable<T> Share<T>(this IObservable<T> source) =>\n source.Publish().RefCount();\n\n public static IObservable<T> ShareReplay<T>(\n this IObservable<T> source,\n int bufferCount) =>\n source.Replay(bufferCount).RefCount();\n}\nThe RxJS names are little more evocative to me than remembering when to\nuse RefCount().
ISlice<State>Redux best practices are to use a single Store to collect your entire\napplication state. This allows for easier debugging serialization and\ncentralization of some forms of developer tooling.
\nBut you often don't want to reason with an entire application state all\nat once. You are often working on a specific vertical feature and want\nto write your Reducers and Epics (more on those later) from the\nperspective of only a slice of your Store.
\nWe start with the general interface design:
\npublic interface ISlice<State>\n{\n public IObservable<State> States { get; }\n}\n\npublic interface ISubSlice<ParentState> : IReducer<ParentState>\n{\n public void RegisterParentSlice(ISlice<ParentState> parent);\n}\nISubSlice<ParentState> is the stranger of the two interfaces in this\ndesign because it is designed to facilitate the dependency injection of\ncircular references. Each Slice can be seen as a large reducer in its\nown parent. Each Slice also needs a reference to its parent to be able\nto do that slicing work of outputting the subset of states relevant to\nthe slice.
The implementation of Slice follows from this dependency injection trick\nplus one other simple one: the .NET DI container like many DI containers\nsupports injecting IEnumerable<T> to get all implementations of an\ninterface that have been injected.
public class Slice<ParentState, State>\n : ISlice<State>, ISubSlice<ParentState>, IDisposable\n{\n private readonly IEnumerable<IReducer<State>> reducers;\n private readonly Lens<ParentState, State> lens;\n private readonly BehaviorSubject<ISlice<ParentState>?> parentSlice = new(null);\n\n public IObservable<State> States => parentSlice\n .Select(parent => parent is null\n ? Observable.Empty<State>()\n : parent.States\n .Select(lens.Get)\n .DistinctUntilChanged())\n .Switch()\n .ShareReplay(1);\n\n public void RegisterParentSlice(ISlice<ParentState> parent) =>\n parentSlice.Next(parent);\n\n public Slice(\n IEnumerable<IReducer<State>> reducers,\n Lens<ParentState, State> lens\n )\n {\n this.reducers = reducers;\n this.lens = lens;\n foreach (var reducer in this.reducers)\n {\n if (reducer is ISubSlice<State> subslice)\n {\n subslice.RegisterParentSlice(this);\n }\n }\n }\n\n public ParentState Handle(RootAction action, ParentState parent) =>\n lens.Set(\n reducers.Aggregate(lens.Get(parent), (acc, reducer) =>\n reducer.Handle(action, acc)),\n parent);\n // or with an Update helper implemented:\n // lens.Update(parent, parentState =>\n // reducers.Aggregate(parentState, (acc, reducer) =>\n // reducer.Handle(action, acc)))\n\n public void Dispose()\n {\n GC.SuppressFinalize(this);\n parentSlice.Dispose();\n }\n}\n\npublic static class SliceExtensions\n{\n public static IServiceCollection AddSlice<ParentState, State>(\n Lens<ParentState, State> lens) => services\n .AddSingleton(provider => new Slice(\n provider.GetServices<IReducer<State>>(),\n lens))\n // allow direct injection IObservable<State>\n .AddSingleton(provider => provider\n .GetRequiredService<Slice<ParentState, State>>()\n .States)\n .AddSingleton<ISlice<State>>(provider => provider\n .GetRequiredService<Slice<ParentState, State>>())\n // register for pickup by its parent\n .AddSingleton<IReducer<ParentState>>(provider => provider\n .GetRequiredService<Slice<ParentState, State>>());\n}\nOur CoolFeatureState might be part of a larger RootState:
public record RootState(CoolFeatureState CoolFeature)\n{\n public static readonly RootState Initial = new(CoolFeatureState.Disabled);\n\n public static readonly Lens<RootState, CoolFeatureState> CoolFeatureLens =>\n new(state => state.CoolFeature, state => coolFeature => state with\n {\n CoolFeature = coolFeature,\n });\n}\nWith Slice implemented we can fill out our example CoolFeatureExtensions\nwith the next registration piece:
public static class CoolFeatureExtensions\n{\n public static IServiceCollection AddCoolFeature(this IServiceCollection services) => services\n .AddTransient<IReducer<CoolFeatureState>, CoolFeatureInitializedReducer>()\n .AddSlice(RootState.CoolFeatureLens);\n}\nNote that both generic parameters to AddSlice are cleanly picked up from\nLens<A, B> matching those parameters.
StoreI think the implementation of our central Redux Store follows pretty\ndirectly from our Slice implementation above:
\npublic IActions\n{\n public IObservable<RootAction> Actions;\n}\n\npublic IDispatch\n{\n public void Dispatch(RootAction action);\n}\n\npublic sealed class Store\n : ISlice<RootState>, IActions, IDispatch, IDisposable\n{\n private readonly IEnumerable<IReducer<RootState>> reducers;\n private readonly Subject<RootAction> actions = new();\n private readonly BehaviorSubject<RootState> states = new(RootState.Initial);\n\n public IObservable<RootState> States => states;\n public IObservable<RootAction> Actions => actions;\n\n public Store(IEnumerable<IReducer<RootState>> reducers)\n {\n this.reducers = reducers;\n foreach (var reducer in reducers)\n {\n if (reducer is ISubSlice<RootState> subslice)\n {\n subslice.RegisterParentSlice(this);\n }\n }\n }\n\n public void Dispatch(RootAction action)\n {\n var nextState = reducers.Aggregate(states.Value, (acc, reducer) =>\n reducer.Handle(action, acc))\n if (nextState != states.Value)\n {\n states.OnNext(nextState);\n }\n actions.OnNext(action);\n }\n\n public void IDispose()\n {\n GC.SuppressFinalize(this);\n states.Dispose();\n actions.Dispose();\n }\n}\n\npublic static class StoreExtensions\n{\n public static IServiceCollection AddStore(this IServiceCollection services) => services\n .AddCoolFeature()\n .AddSingleton<Store>()\n .AddSingleton(provider => provider.GetRequiredService<Store>().States)\n .AddSingleton<ISlice<RootState>>(provider => provider.GetRequiredService<Store>())\n .AddSingleton(provider => provider.GetRequiredService<Store>().Actions)\n .AddSingleton<IActions>(provider => provider.GetRequiredService<Store>())\n .AddSingleton<IDispatch>(provider => provider.GetRequiredService<Store>());\n}\nIEpic<State>The final part to this pattern that does a surprising amount of heavy\nlifting is the concept of an Epic. Named after "lengthy story", an Epic\nis the asynchronous workflow relative of the Reducer. Where Reducers\nmust be synchronous, the Epic can do anything Observables can do,\nincluding calling async/await methods and running all sorts of side\neffects.
Generally Epics observe Actions, the current state after an Action, and\nreturn Actions.
\npublic interface IEpic<State>\n{\n public string Name { get; }\n\n public IObservable<RootAction> Create(\n IObservable<RootAction> actions,\n IObservable<State> states,\n IScheduler scheduler);\n}\nThe IScheduler is explicitly provided to encourage testing with\nTestScheduler and also because we found reasons at runtime to inject\nspecific schedulers without the Epic needing to be aware which.
The Name is useful for logging and debugging.
An example "Cool Feature" Epic might look something like:
\npublic record CoolFeatureLoaded(IEnumerable<CoolThing> CoolThings)\n : CoolFeatureAction;\n\npublic class CoolFeatureLoadedReducer : Reducer<CoolFeatureLoaded, CoolFeatureState>\n{\n public CoolFeatureState Reduce(\n CoolFeatureLoaded action,\n CoolFeatureState state\n ) =>\n state with { CoolThings = action.CoolThings };\n}\n\n/// <summary>\n/// When Cool Feature has initialized, load any applicable CoolThings.\n/// </summary>\npublic class CoolThingLoader(ICoolThingService service)\n : IEpic<CoolFeatureState>\n{\n public string Name => nameof(CoolThingLoader);\n\n public IObservable<RootAction> Create(\n IObservable<RootAction> actions,\n IObservable<CoolFeatureState> states,\n IScheduler scheduler\n ) =>\n actions.OfType<CoolFeatureInitialized>()\n // Sometimes a .WithLatestFrom() is useful here if the\n // reducer calculates something, say in this case the\n // API wants the calculated CoolStarted time. Actions are\n // the "transaction model" for the Store, so the state\n // after an Action is observed should always reflect all of\n // the Reducers have run.\n .Select(action => action.IsCool\n ? Observable.FromAsync(async (ct) =>\n new CoolFeatureLoaded(\n await service.LoadCoolThings(ct)),\n scheduler)\n : Observable.Return(new CoolFeatureLoaded([])))\n .Switch();\n}\n\n// updated registration\npublic static class CoolFeatureExtensions\n{\n public static IServiceCollection AddCoolFeature(this IServiceCollection services) => services\n .AddTransient<IReducer<CoolFeatureState>, CoolFeatureInitializedReducer>()\n .AddTransient<IReducer<CoolFeatureState>, CoolFeatureLoadedReducer>()\n .AddTransient<IEpic<CoolFeatureState>, CoolThingLoader>()\n .AddSlice(RootState.CoolFeatureLens);\n}\nOne thing that should be obvious from the Epic interface is that an Epic\nmay return the same Action it observes in the first place. This is a\nrecipe for an infinite loop.
\nThe key wisdom when writing an Epic is that often attributed to\nSpider-Man's Uncle Ben:
\n\n\nWith great power comes great responsibility.
\n
Loops are a key flow control power in software development. Just as you\nmight use a while loop, you may find needs for Action loops in your\nEpics. Just like working with a while loop, you need to make sure that\nyour loop condition is solid enough to avoid infinite loops, and you want\nto make sure that your loop has all the other fast exits it may need.
EpicHost<State>The last big piece of pattern is initializing all the Epics at the right\npoint in application startup. This effort is left to a simple class\nknown as the EpicHost<State>.
public interface IEpicHost\n{\n public void Initialize();\n public IEnumerable<string> EpicNames { get; }\n}\n\npublic class EpicHost<State>(\n ILogger<EpicHost<State>> logger,\n IEnumerable<IEpic<State>> epics,\n IAction action,\n IDispatch dispatch,\n ISlice<State> state)\n : IEpicHost, IDisposable\n{\n private bool initialized;\n private ISubscription? subscription;\n private IScheduler scheduler = Scheduler.Default;\n\n public IEnumerable<string> EpicNames => epics.Select(epic => epic.Name);\n \n private IObservable<RootAction> CreateEpic(IEpic<State> epic)\n {\n logger.LogDebug("Epic {Epic} starting in {Host}", epic.Name, GetType().Name);\n return epic.Create(action.Actions, state.States, scheduler)\n .Catch(error =>\n {\n logger.LogError(error, "Error in epic {Epic}", epic.Name);\n // Restart:\n return CreateEpic(epic);\n // NOTE: You might want to include a backoff strategy for\n // restarts or other additional debugging tools here.\n });\n }\n\n private IObservable<RootAction> CreateEpics() =>\n Observable.Merge(epics.Select(CreateEpic));\n\n public void Initialize()\n {\n if (initialized)\n {\n return;\n }\n initialized = true;\n subscription = CreateEpics()\n .Subscribe(\n action => dispatch.Dispatch(action),\n error => logger.LogError(error, "Error in {Host}", GetType().Name),\n () => logger.LogError("{Host} completed", GetType().Name),\n );\n }\n\n public void Dispose()\n {\n GC.SuppressFinalize(this);\n subscription?.Dispose();\n }\n}\n\npublic static class EpicHostExtensions\n{\n public static IServiceCollection AddEpicHost<State>(\n this IServiceCollection services\n ) => services\n .AddSingleton<IEpicHost, EpicHost<State>>();\n}\nEpicNames can be handy for debugging and testing.
Somewhere in your application startup path where it makes the most sense:
\nvar epicHosts = services.GetServices<IEpicHost>(); // or constructor injection\nforeach (var host in epicHosts)\n{\n host.Initialize();\n}\nTo finish up our Cool Feature example registration, it's final shape is:
\npublic static class CoolFeatureExtensions\n{\n public static IServiceCollection AddCoolFeature(this IServiceCollection services) => services\n .AddTransient<IReducer<CoolFeatureState>, CoolFeatureInitializedReducer>()\n .AddTransient<IReducer<CoolFeatureState>, CoolFeatureLoadedReducer>()\n .AddTransient<IEpic<CoolFeatureState>, CoolThingLoader>()\n .AddSlice(RootState.CoolFeatureLens)\n .AddEpicHost<CoolFeatureState>();\n}\n(You might want to inject an Epic Host for the RootState as well.)
I found it useful to test that all Reducers and Epics were registered\nin DI to avoid forgetting to register one (and then being confused why\nit wasn't working).
\nIt needs this helper function for Reflection:
\npublic Func<Type, bool> ImplementsGenericInterface(Type interface)\n{\n var genericInterface = interface.GetGenericTypeDefinition();\n return (Type targetType) => targetType\n .GetInterfaces()\n .Any(x => x.IsGenericInterface && x.GetGenericTypeDefinition() == genericInterface\n || x.GetInterfaces().Where(i => i.IsGenericInterface).Select(i => i.GetGenericTypeDefinition()).Contains(genericInterface));\n}\nWith that in hand in a test context where you can test your appropriately\nregistered DI container, you should be able to use tests that look\nsomething like (modulo your test framework and assertion framework\ndifferences):
\n[Fact]\npublic void ReducersAreRegistered()\n{\n var isReducer = ImplementsGenericInterface(typeof(IReducer<>));\n var reducers = typeof(Store).Assembly.GetTypes()\n .Where(t => !t.IsAbstract && t != typeof(Slice<>) && isReducer(t));\n foreach (var reducer in reducers)\n {\n Assert.IsTrue(\n Services.Any(desc => desc.ImplementationType == reducer),\n $"Reducer {reducer.FullName} should be registered");\n }\n}\n\n[Fact]\npublic void EpicsAreRegistered()\n{\n var isEpic = ImplementsGenericInterface(typeof(IEpic<>));\n var epics = typeof(Store).Assembly.GetTypes()\n .Where(t => !t.IsAbstract && isEpic(t));\n foreach (var epic in epics)\n {\n Assert.IsTrue(\n Services.Any(desc => desc.ImplementationType == epic),\n $"Epic {epic.FullName} should be registered");\n }\n}\nI think this pattern should feel built out of a lot of simple parts.\nI feel like most of the work in this particular pattern is just the DI\n"glue" to connect all the small lego parts of the pattern together.
\nI've had good success with the Epic Pattern for Redux in JS and I think\nwe saw some good use of this pattern in the C# project we were using this\npattern for (the view states and much of the business logic of a frontend\nbuilt in Blazor WASM).
\nThe reliance of C# Dependency Injection in the way this pattern uses it\nI think helps keep individual pieces small, focused, and easy to unit\ntest. I wrote a lot of Reducers and Epics in this pattern, with high test\ncoverage, and I appreciated it.
\nGiven how much of the pattern seems to me to be most "DI glue" and\nI couldn't see enough of a case to convert it to a C# library, I thought\nit may still be useful to at least blog the pattern for posterity, as it\nmay be useful to other projects. In so far as this is copy and pasteable\ncode rather than an uncopyrightable generic description of a software\npattern, I believe the MIT license applies (no warranty, especially).
\n","date_published":"2026-04-07T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2025/11/23/tiny-paychecks/","url":"https://blog.worldmaker.net/2025/11/23/tiny-paychecks/","title":"Tiny Little Game Developer Paychecks","content_html":"About a year ago, I put together a small add-on for Fantasy Grounds to\nadd a metric calendar (or Stardate calendar) to the extensible calendar\nsystem of the virtual tabletop (VTT) Fantasy Grounds because I was\ncontemplating an attempt to GM a one-off session, maybe two, for "Star\nTrek Adventures" and thought it would be nice to include Stardate logs\nin the campaign's calendar.
\nThe metric calendar addon is open source and you can pick up a\ncopy for free from its releases, or build it yourself with the attached\nbuild script, if you want to save a (literal) quarter or see what add-on\ndevelopment looks like for Fantasy Grounds.
\nI put it on the Fantasy Grounds Forge for a quarter, and out of every\nquarter spent on it I get roughly 15 cents. After about a year and change\nof it being on the Forge I can safely say that I've made "candy bar" money\nfrom sales of it. It amuses me each time one of these payments arrives,\nthey truly are tiny, but it also makes me happy that scratching my own\nlittle itch resulted in enough side income pay to buy a whole candy bar.
\nAfter many decades of failed or unfinished projects, I suppose that I'm\nofficially now a "professional game developer" having received candy bar\nmoney for at least one effort. (That also amuses me about this.)
\nAs far as I can tell I'm one of the few Fantasy Grounds add-on developers\nusing source control and source control automation, so I think I've now\npromised at least a small article/guide on doing that, to help that\ncommunity take some of their efforts to the next level. I would like to\ndo that for them.
\nAlso, if you haven't yet tried Fantasy Grounds yet, I can recommend it\nas a nice VTT for many game systems. Just recently\nFantasy Grounds became free-to-play (YouTube announcement video),\nfocusing on a business model of selling the books for game systems over\nthe software itself. I think it's got some advantages over other VTTs\nbecause it is "offline-first" rather than "cloud-native". It's\nUnity-based game client copies everything needed to play locally and a\nGM can use it offline or even allow play over a LAN disconnected from\nthe internet (as long as everyone's client versions are synchronized).\n(Not that I've attempted that yet, but I may in the future. I like that\nit is possible.) Of course you don't have to take my word for it, it is\ncheaper than ever to start trying out Fantasy Grounds, and of course I'm\na little biased because Fantasy Grounds has now made me enough side\nincome to buy a candy bar. I'd love to see them continue to succeed in a\never more competitive VTT market.
\n","date_published":"2025-11-23T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2025/04/27/book-club/","url":"https://blog.worldmaker.net/2025/04/27/book-club/","title":"Some of the Surprising Complexities of Voting on Books","content_html":"I offered to write a new voting tool for my favorite book club. It\nseemed a good use of winter doldrums and new tools. I had several ideas\nI thought would be good for the club. I wanted another, easily open source\nportfolio site for Butterfloat and to try to show off some of the\ntechniques I've been concerned with in my professional life that aren't\nalways obvious because most of that code lives (and dies) behind closed\ndoors. I had a couple other pieces of technology I wanted to play with,\neither to learn them better or because they were cheap new options or\nboth.
\nI got further along in this nights and weekends hobby project than I\nexpected I would, especially as someone who has had to explicitly take a\n"no moonlighting" stance for most of my career in a needed boundary to\navoid burnout. Some of that is the new tools at my disposal. Some of\nthat is because this project turned out to be fun in some surprising\nways.
\nI've taken technical liberties in how almost everything worked, but it's\nalso been interesting after the major efforts were done seeking "Product\nOwner approval" from the current book club admin (who is not me). I\ndidn't want to take over club admin, I wanted to try to work to make\nthis something friendly for an existing admin to work with.
\nWhile I kept talking about wanting to build a cool new voting site for\nmy favorite book club, I was rubbing up against my own boundaries on "No\nMoonlighting". As users have been starting to use and settle into the\nnew site, I have been making a lot of jokes that this site is especially\nbrought to them thanks to my Junior Developers on this project: GitHub\nCopilot and Good Scotch.
\nThis is one of the best kinds of jokes because it is surprisingly true.\nThere's a style of LLM coding that has been called vibe coding. One\nJanuary weekend I realized I had a fun vibe coding relative of my own\nwithin this project. My Mastodon subject line (or the Welsh spelling\nCWbject if you prefer) was even "Weird Vibes (Software Engineering)",\nconvergent evolution at work in describing the difference in a new\nworkflow. (I was not aware of "vibe coding" at the time, but now it's\nsuch a common term.) My vibe was different from the one making the rounds\nas the titular "vibe coding". That January day I realized that my vibe\nwas sort of distinctly "bougie" in a fun way. I realized that I'd spent\nmost of that coding session feeling as if I was "leaned back", in a nice\nbath robe, a rocks glass of Scotch in hand, code reviewing the output of\nGitHub Copilot, much more than "leaned in" and directly writing code as\nI would normally be on a day job project.
\nI loved that vibe of leaned back, bougie code review enough that I was\nimmediately joking about starting a new consultancy focused entirely on\nbeing "What if Masterpiece Theater was about Code Reviews?" I still kind\nof think that would be a cool company. I don't know how much of a market\nthere would be for "We rent nice mahogany offices, set up a good whiskey\nbar, wear cool robes and smoking jackets, and only review code, we don't\nwrite it", but if you are an investor looking for that opportunity, hit\nme up, I've got ideas.
\nMoonlighting has less risk of burnout when it feels like distinctly\ndifferent vibes from day job work. My current day job does pay for GitHub\nCopilot on my projects, but isn't currently encouraging me to work with\na good scotch or bourbon in hand. Also most of the things I'm working on\nat my day job aren't necessarily easy off the shelf algorithms and "basic\nCRUD" in the same way that this hobby project has been.
\nA lot of us get interesting hyperfixations at various times that stick\nwith us. One of my college ones was getting deep in trivia of Robert's\nRules of Order, where I generated half an idea that I wanted to build a\nmeeting presentation tool more tuned for parliamentary procedure than\nPowerPoint. (That is maybe a fun idea to revisit with LLMs, though the\nultimate crash of that project was not wanting to get into the licensing\ndrama of modern Robert's Rules and not expecting the tool to be that\nexciting for running contemporary meetings if sticking only to the\ncontent of Public Domain versions). Related to that one, and both a\ndeeper rabbit hole and maybe more important to following years, was a\ndeep dive into the more arcane mathematics, game theory/economics, and\nsoftware algorithms related to many of the ways it is possible to\ncalculate the votes of a group to find the most interesting winner.
\nThe most common voting systems in our lives are all, in one way or\nanother, "first-past-the-post" systems where a simple majority winner\ntakes all. The very well known failure cases of those systems that are\n"first-past-the-post" are what leads to common modern problems like "two\nparty systems" and ugly compromises like slate voting and "never vote\nfor a third party even if that's really what you want because that 'takes\naway' votes from the next best candidate in one of the only two 'allowed'\nparties".
\nThere are lots of ways to solve this, but there's lots more ways that\nfeel like they solve this but are really just\n"first-past-the-post-with-more-steps". Ranked choice (rank some or all\nthe candidates from favorite to least favorite) often give the feeling\nof solving this easily, with relatively "easy" ways to assign "points"\nand build point systems that do easy math in a spreadsheet. No offense\nto anyone that likes to run a voting system like that or how much\ninteresting work has gone into running such votes and tweaking point\nsystems, but the ease of doing that is deceptive that in how rare it can\nbe for your "points" system to help solve things like let the winner be\nthe candidate that would win the most head-to-head battles against all\nof the other candidates.
\nThe nerdy mathematical name for this goal that head-to-head battles\nmatter is the Condorcet winner criterion and you might be surprised\nhow many voting systems fail this criterion. It sounds like an easy\nthing to do, but it's a lot harder in practice, mathematically, than it\nsounds. (Also, I would be technically remiss if I didn't point out that\nthe Condorcet winner criterion is not the only possible criterion to\nseparate a "good" voting system from a "first-pass-the-post" one, there\nare several "competing" criteria that have different trade-offs. I like\nthe Condorcet criterion best, because it allows for "surprising" winners\nbut winners that most voters can still agree should have won, which is\nto say it is very good at avoiding "two party systems" where there's\nonly two choices and the rest is "throwing your vote away" and "spoiling"\na loser's chance.)
\nI became one of those nerds with a favorite voting system. That system\nis generally referred to as the Schulze method, or the "beatpath"\nmethod. (It does pass the Condorcet winner criterion.) The Schulze\nmethod is a ranked pairs system (rank all candidates versus each other\nin head-to-head battles) that mathematically accepts and flourishes with\nties so it can be presented as if it were a simpler ranked choice\nsystem which allows ties. I think this is a surprisingly big deal: no\none really wants to vote for every pair of choices (think "Round Robin\ntournament"), but present them a list of candidates to rank every one of\nthem 1-5 stars like they are writing Yelp Reviews and they can "secretly"\ndo all the work of doing a full pairwise ranking, with interesting ties,\nand have fun doing it.
\nUnfortunately the Schulze method is easier demonstrated than described,\nespecially the math behind it. For a while there was a cool website called\nModern Ballots, may it rest in peace, that I could point to do sample\nvotes. It was rather close to a "Survey Monkey to make quick Schulze\nballots". With that website gone (but obviously not forgotten) it has\ngotten a lot harder again to convince people to try Schulze method\nvoting. The math is just hard enough that no one wants to particularly\ndo it by hand (I don't), and it isn't easily illustrated how to do it in\nan Excel sheet or Google Sheet, either. But the math is also so juicily\neasy for a simple program to automate. The meat of the Schulze method\nuses a slight variation on a simple textbook algorithm called the\nFloyd-Warshall algorithm. It is one of those algorithms you learn about\nearly in an undergraduate study of computing, because it also has deep\nearly computing roots from the time when "Dynamic Programming" meant\n"solving a problem in place in its own existing data structure" rather\nthan something more exciting than that.
\nIt's one of those algorithms that you may code one or two times for class\nassignments and wonder if you'd ever actually need it in the real world.\nIt's one of those algorithms that code competitions love to include as\nnon-obvious solution to a word problem that then turns into a quickly\nsolved "known algorithm" project after you think long and hard about it.\nThe Floyd-Warshall algorithm is for finding the "widest path" in a\ndirected graph (digraph). Very simply: you've got paths from places like\nA to B and A to C and C to B. These paths have numbers on them for some\nreason that often is a variation of "how wide is this path" (how many\npeople can walk it side by side, how much money does it cost to pay the\ntolls, how slow is it on a busy traffic day, all sorts of other\nword problem variations like that). Is it a wider path to go directly\nfrom A to B, or should you take the scenic route from A to C to B? These\nsorts of questions are surprisingly common, so that undergraduate\nimplication of "you should learn this because it is handy" turns out to\nbe a real world thing sometimes.
\nThe nickname for the Schulze method as the "beatpath" method comes\ndirectly from this core reliance on the Floyd-Warshall algorithm: you\nare looking for the widest path of candidates, no matter how convoluted,\nwho beats the most other candidates, in whatever surprising order the\ngraph returns. If you've encouraged a lot ties along the way, as in using\na simple, strict 1-5 "stars" choice, sometimes the widest paths are very\nsurprising, but in a fun way (and a Condorcet criterion way) that few can\nargue with the results.
\nOne of the reasons that this hobby project turned into "bougie vibes\ncoding" for me was entirely because the hardest mathematical piece of\nthe puzzle was very much writing a comment that I was about to use the\nFloyd-Warshall algorithm adapted for the Schulze method and allowing\nGitHub Copilot to spit out almost exactly the Wikipedia definition of\nthe Floyd-Warshall adjusted from Wikipedian pseudo-code to the language\nI was actually working in with some of my coding style. I took the time\nto review that it actually matched the definition and my code style, but\nI was in a place to be very pleased that something I had written a bunch\nof times before (as mentioned) was so easily plugged in for me here by\n"my Junior Developer", Copilot. Not all programming is "use this very\nwell known algorithm in this rather well known use case" (I'd argue most\nisn't), but it was certainly exciting to see an example play out directly\nhere, and code review it in a bathrobe with a good Scotch in hand.
\nYears ago after too many near misses on database leaks and other concerns,\nI made a decision that I never wanted to be in charge of storing passwords\nin a database ever again. I hate passwords, personally. I especially hate\nthe feeling of the risk of someone's one-and-only password becoming\ncompromised due to my "silly fun hobby project". I've been advocating to\nget rid of them in one way or another for many years. I was a fan of the\noriginal Blogger's friend version of OpenID and was sad to see it devolve\ninto related-in-name-only standards like OpenID Connect. I was a\nproponent for [Mozilla Persona] and still remain disappointed it didn't\nsucceed. (One of my few other moonlighting projects back in the day\nthat's fun to compare/contrast with this book club site was one that\nused Schulze voting and Mozilla Persona. It died when Rotten Tomatoes\nshut down their public API almost exactly a year into running that site,\nbut if not for that it would have died soon after that when Mozilla\nPersona was shutdown.)
\nPasskeys are the current hope for the present of "no passwords in my\ndatabase". It feels like they are ready for prime time and the mainstream,\nwe just need a bit more education, a bit more pomp and circumstance, a\ntiny bit more polish in edge cases. It feels like we finally have a big\nenough multi-vendor coalition it isn't destined to die like Mozilla\nPersona did. Technically, it even feels like a slightly more polished\nversion of what Mozilla Persona wanted to be when it grew up (a way for\nwebsites to get an ID directly from the user's browser with no middle\nmen), though it is missing some of the things that made Mozilla Persona\nso nice to work with. A big one for me is that Mozilla Persona was\ndesigned with the intent that there be an easy to verify claim of a\nuser's email address directly associated with the key/ID. As someone that\ndoesn't want to pay for a transactional email provider for my hobby\nproject, I would love for an email attestation on Passkeys to be something\neasy to request and also to verify with a trustworthy third party. I also\nunderstand why that's not currently in anyone's Passkey plans (and may\nhave played a part of why cross-vendor interest in Mozilla Persona was\nso low).
\nThis site was my first attempt to implement Passkeys as a so-called, in\nsecurity jargon, Relying Party (RP). I used an off-the-shelf library for\nthis called simplewebauthn and hit some issues where despite the name,\nit did not feel as simple as I would have liked. This is partly because\nsimplewebauthn, to stay simple, acts mostly as a lego kit with a gnarly\npack of step-by-step instructions, including many "DIY Here" steps, and\na wave for good luck. To my benefit, I haven't been doing anything\nparticularly exciting or different or weird with it, and I appreciated\nit as a lego kit for not constraining my choice of front-end "Frameworks"\nfor my front end (as I'd already made my choice, which I will get to\nlater in this post), even as I kept hoping for an even simpler solution.
\nAs much as I could complain about how many headaches it gave me in the\nthick of choosing it and writing the code to glue it all together and\nimplement it, a lot of it really was just following the lego instructions,\nand a lot of that did benefit from "let Copilot write the first pass" and\nthen clean up its assumptions and fix things specific to my backend and\nfrontend choices. Not exactly the same "lean back" experience of writing\nthe core voting algorithm but something similar feeling to that. This was\nthe first big project of the application (if you can't login, how can you\nvote) before even building the voting code, and a lot of the\nprocrastination leading into the project was not wanting to build this\ncode in the first place. I'm glad I got through it, and I think I did a\nstrong job with the strange intricacies of logging in with Passkeys and\nonly Passkeys, as well as the bootstrap phase to register an account's\nfirst Passkey. I can't say it is the most secure implementation (and\ngiven a lack of transactional email provider to actually verify emails,\nit certainly isn't), but it is also possibly overkill for a "silly fun\nhobby project". Yet I succeeded in not storing anything even resembling\na user password in the site's database.
\nPasskeys were one of my biggest anxieties in technical choices leading\ninto the "MVP" demo with the Product Owner. I was pleasantly surprised\nat how well it demoed and the overall acceptance of it. Though I also\nwas lucky here that the Product Owner's background in information\nsecurity also easily agreed "oh yeah, no passwords".
\nI also expected a lot more user support/training issues and/or complaints\nwith Passkeys and have been mostly pleasantly surprised with general user\nacceptance. Again here some of that is probably the luck of the bias of\nthis book club in question to have a somewhat tech friendly background\noverall.
\nThe biggest issue seemed to be an old (already out of security support)\nversion of macOS claiming to support Passkeys but failing to register a\nnew one in any browser using the system keychain. The workaround seemed\nto be to register on a recent enough iOS device and well enough I'm told\nthe Mac eventually synced that key and worked with it.
\nThe next biggest issue has been Windows 10 which is in a similar place of\n"supports Passkey" but has quirks with it and only syncs with Windows\ndevices. I had planned for this issue, as my own main development machine\non this project is stuck with Windows 10, and so I made sure that my\nimplementation supported registering multiple keys for the same email\naddress (which I've always taken for as table stakes in Passkey\nimplementation, but it's interesting how some still don't).
\nWe also found out that the "the Facebook (embedded) browser" is generally\nblocked from using Passkeys and/or doesn't implement Passkey support on\nevery phone OS. This has been particularly frustrating because sharing\nlinks on Facebook has been common for the book club, which has used an\nFB Group as a central communications channel since it started. It's easy\nto forget that not everyone distrusts the embedded browsers in platforms\nlike Facebook or even understands the difference between opening a link\nin an embedded browser and opening the link in the system browser/their\nregular and default browser. Facebook doesn't help this by moving the\n"open in default browser" option strangely hard to find. (Today it's\nbehind an ellipsis menu. Who knows where it will move tomorrow.)
\nI also tried to mitigate some feedback ahead of time by suggesting\nlogging in with an iOS or Android device first, because those have the\nsubtly strongest implementations, are slightly more likely to be somewhat\nup to date (given mobile OS update policies and cell carrier enforcement\nof some of them), and generally the best sync behavior to their\nrespective ecosystems. Windows 11 can do the QR code dance to login with\nan iOS or Android Passkey then help you register a Windows Passkey. Some\nLinux setups can do that now, too. I got some feedback on the earliest\nwording of that suggestion that I was making it sound like the website\nonly worked on iOS or Android, and I was happy to reword that and also\nstill feel like I'm trying to find the best way to word that advice\n(without also over-explaining it, as I do here).
\nA lesser pet peeve I have with Passkey UX is that I’ve implemented all\nthe markup for the best “autofill” experiences but it doesn’t light up\nand I believe the reason for that is that in most browsers it still\nassumes a password field. I’ve wondered if adding a dummy password field\nmight help browsers show the best UX, but that seems silly for a\nPasskey-only website to do and I certainly don’t want to confuse my users\nwith a vestigial password field that doesn’t do anything just to autofill\ntheir email address with a cute key icon next to it. I hope the browsers\nimprove the UX for “no password” sites, as much as I understand why the\nUX is maybe overly focused on the chicken-and-egg bootstrap dance of\nupgrading sites that still use “traditional” passwords first.
\nOf course, some of this user acceptance feedback still feels like "early\nadopter" feedback and maybe I should still brace for more pain in future\nregistration waves as our least technical users find time to want to vote\nor we find new club members with more diversity in their technical\nbackgrounds. But overall I think big takeaways are beware old Passkey\nimplementations that only sort of work, know your workarounds for that\n(allow registering the same email twice; always support multiple Passkeys\nin an account), and I wish there more examples of Passkey-only sites in\nthe open source zeitgeist to double check implementations on. Hopefully\nthis implementation will be another one of use to someone else next (even\nif indirectly through better GitHub Copilot vibe coding, maybe).
\nI wanted another public, open source portfolio project for Butterfloat.\nI'm still quite proud of Butterfloat and I know it isn't a "Framework" on\nhardly anyone else's radar (and maybe can't be because it isn't churning\nthrough backwards compatibility breaks fast enough 😼), but one of those\nthings that if I build cool things with it maybe I slowly convince more\npeople to try it. In particular, both of the other public sites that are\nopen source in my portfolio were migrated from Knockout and were single\npages (though one because it was built to be single-page-application-like\nand the other only because it was a small demo with no need for a second\npage). This site I knew I wanted an old school multi-page app, because I\nwanted to use a static site generator to build as much as possible ahead\nof time. I also knew going into this project that I wanted to start from\nthe perspective of a ("traditional" for a static site generator [SSG])\n"flat file database" of Markdown files in folders (with some modest YAML).
\nI've had some ideas for building an SSG with Butterfloat, but this project\ndidn't feel right for experimenting with those ideas. Particularly with\nthe desire to use the Markdown files with frontmatter paradigm. I did\nhave fun discovering Lume as a minimalist SSG with all the basics\ncovered that I expected and needed.
\nThis seemed like the right project where I needed to finally test building\nout Web Components with Butterfloat in a classic multi-page architecture.
\nOverall, I've been very excited from the results of building web\ncomponents with Butterfloat. I've mentioned many times that a guide star\nfor Butterfloat has been "modern Knockout" and it has been in building\nthese web components that I've felt some of the most like I've been\nhonoring the Knockout legacy. Knockout was critical in the early\n"Progressive Enhancement" web, and web components, when they work well,\nhave a beautiful way of feeling like the endgame of Progressive\nEnhancement. Simple DOM elements get replaced with more interesting things\nif JS is available and as soon as it loads. That feels a lot like the best\nof Knockout's experiences in the old days. Having the ability to do it\nwith much less of a "flash of unstyled content" is a strong improvement.\nWeb component elements themselves have no default content or styles and\nif you place things like "noscript" warnings inside them it is a quick\nmatter to replace them on web component startup. Additionally, template\ntags are better than what Knockout was doing with programming inside\ncomments and hiding things with display CSS at runtime. Stamps\n("server-side rendering" of Butterfloat static DOM to template tags) have\nbeen in Butterfloat for some time now, but Stamps definitely shine in the\ncontext of web components, building template tags at “compile time” ready\nfor web components to pick up as soon as they are ready.
\nGoing into building web components with Butterfloat I was worried that it\nwas going to be more complex and/or harder than it turned out to be. Given\nsome of the other web component libraries I've seen for other\n“frameworks”, I expected to need a bunch of custom adapter code or things\nof that nature, but I think the Butterfloat component model and lifecycle\nsort of accidentally turned out to be perfect for running inside web\ncomponents and the amount of code to build a Web Component from a\nButterfloat Component seems almost too simple enough to me. I've\ndocumented the bones of the pattern already and hope it helps other\nprojects looking for a lightweight alternative for a Web Component\n"framework".
\nOf course, to be fair, part of why this book club site has had such a\nsimple time with Web Components is that I intentionally eschewed the\nShadow DOM and there's nary a Shadow Root in sight anywhere in the\nproject. Turns out that is something that you can just do. I know a lot\nof Web Components tutorials and discussions get very deep into the weeds\nof the Shadow DOM, and I understand why so many libraries that build Web\nComponents may see needs for Shadow DOM tools, but also I think a lot of\nthe over-focus on the Shadow DOM does injustice to how simple they are\nwithout it, and how much you can do with Web Components that don't have\nShadow DOM. But also, I'm a fan of letting CSS do what it does best at,\nat a global level across the page, because that is a lot of power and the\nShadow DOM is partly about distrusting page styles rather than taking\nadvantage of them. I do like to choose to take advantage of them.
\nBuilding Butterfloat components with GitHub Copilot has been fascinating.\nObviously Copilot is trained on a ton of JSX from React projects. For the\nmost part a lot of that just works, though stylistically it’s nice to also\nupdate it for shortcuts Butterfloat supports that React doesn’t (like\nclass over className). In a couple places Copilot has been useful in\nhelping me find React idioms that didn’t work in Butterfloat but could\n(and was quickly upgraded to support) and ones that I still intentionally\ndid not wish to support preferring more Butterfloat-specific idioms. This\nwas also a fun case of watching Copilot pick up more and more of those\nButterfloat specifics from this project as it grew and presumably also\nfrom rich code search of my other public and open source Butterfloat\nprojects.
My biggest pet peeve with building these web components is that the ESM\nnative, properly tree-shakeable version of RxJS is apparently currently\ntrapped behind waiting for various standards organization working groups,\nbecause the current maintainers want to wait for “Signals” and possibly\nbrowser-native Observables proposals to shake out first. I understand the\nreasoning behind that (align to standards for the next SemVer major\nrelease), but I don’t agree with it, because we’ve been on this\nmerry-go-round before with standards bodies almost doing native\nObservables and then giving up after lots of hemming and hawing and giant\ndebates. The fact that this round also includes trying to standardize\nObservables-but-dumber "Signals" drama doesn’t give me a lot of confidence\nthat things will turn out better this time than the last time, and in the\nmean time as great as esbuild is, I still would love to get real\ntreeshaking from RxJS (Butterfloat’s one and only dependency).
\nFor this project the backend database I chose was Deno KV on\nDeno Deploy. I evaluated a lot of "serverless" deployment tools and\ntheir various database backends. There's a lot of great options today.\nThere are a lot of options with interesting marketing budgets and "fan\nbases". I started exploring Deno earlier when I made sure that Butterfloat\ngot a good score on JSR and found I liked a lot of the philosophy and\ndeveloper experience feel of it. (So much so I’m debating making\nButterfloat Deno and JSR-first and suggesting that over traditional npm\ninstalls, but I’m not in a rush to do that.)
\nI'd pretty happily recommend Deno Deploy at this point. So far the\ndeveloper experience has been great.
\nDeno's Deploy product on paper seems to have fewer features that most of\nthe more popular/hyped options. It's primary database is "just" a "simple"\nkey-value store without a lot of bells or whistles like some of the hosted\nSQL databases and/or "NoSQL" document databases that are "standards" in\nthis area.
\nBut Deno Deploy's own focus on its documentation spoke to me. The\nexperiences with JSR and other parts of the Deno ecosystem have all been\npleasant and I think the Deno team seems to show a lot of maturity in how\nthey think about developer experiences. That focus on documentation means\ntheir website leads relatively straight to the developer documentation,\nrather than some of other hosting providers trying to steamroll you\nthrough marketing hype after marketing hype page or blind trial sign-up\nactions without first being able to read the developer document. (It also\nhelps that Deno Deploy seems to have a very generous free tier compared\nto some of its peers.) A lot Deno's documentation alone makes up for how\nrelatively "young" Deno Deploy is and how many parts of it are still\nappropriately and visibly labeled "experimental" or "unstable", which\nshows maturity, to me at least, in how everything is documented. It's\ncounter-intuitive but being able to clearly see the "experimental" and\n"unstable" labels helps my impression a lot. To some extent a lot of\nthese "serverless" hosts still feel like most of their products should\nbe labeled "experimental" or "unstable" and Deno admitting to it feels\nmore mature to me.
\nAs for Deno KV, I also knew from past experience that the border between\n"just" a key-value store and "a document database" is really blurry,\nespecially if you don't mind doing a little bit of work up front on your\n"primary indexes" (your key building patterns) and rolling your own\n"secondary indexes" as needed. I especially loved that Deno KV brings its\nown invisible "path separator" for its key namespaces. This makes it\neasier to build smart "primary indexes" while also providing tools to\navoid some of the obvious problems like key injection attacks.
\nThere is a lot you can do with "just" a KV, especially if you are willing\nto over-engineer things a bit. I’ve certainly picked up familiarity over\nthe years from complex usages of things like redis caches and Local\nStorage.
\nI'm quite proud of the voting engine in this book club site. It's designed\nfor a massive scale that this particular club doesn't really need, but it\nwas exciting to write it that way, and it is also leads to more than a\nbit of "penny pinching" in interesting ways to help keep the site within\nDeno's current generous free tier.
\nIn this case the Schulze method is very amenable to a classic "map/reduce"\npattern, with each ballot being mapped to an adjacency matrix describing\nthe "beats" graph for that user, reducing those adjacency graphs through\na simple matrix sum aggregate, then taking the last summation matrix and\nmapping that through the Floyd-Warshall algorithm to arrive at the final\nmatrix of the widest paths of all the votes.
\nThe voting site backend is using Deno Queues to orchestrate all of that\nwork. Additionally, the users' ballots are partitioned into (currently)\n32 random buckets (but flexibly more as needed) reducing the number of\nadjacency matrixes that need to be resummed when a single user votes, as\na simple complexity reduction to what we call O(log n). I'm proud of\nthis bucketing, which is accomplished through a bit of maybe silly but\nhandy "primary index" magic of using for the ballot keys the reversed\nstring of the user's ID for the ballot. User IDs are ULIDs which are\ntimestamp up front and random entropy at the back, so reversing the ID\ngives random buckets (as opposed to time insertion buckets, which is\nuseful in other cases for things like clustered indexes and log-oriented\nappends/merges). (String reversals of these basic 32-letter alphabet ASCII\nstrings are also easily reversable and/or repeatable, making it still easy\nto do ballot lookups by User ID.) As far as hash bucketing schemes go,\nit's not a very complex one, but it works well in this case.
One of the things I’ve picked up from past SPAs that I’ve worked on is the\nimportance for designing for "offline first". Some of the applications I\nworked on for past jobs demanded "offline first" architectures, because\nif you are in the field examining some remote reach of a river, you\naren’t likely to have good cell service no matter how close we feel to\nhaving ubiquitous cell service coverage in the US.
\nBut the thing I found from "offline first" is that it generally "feels\nbetter" and that it often feels like how modern apps seem that they are\nsupposed to feel.
\nAll of the CRUD (create, read, update, delete) work in the voting site is\ndesigned to be "offline first", using Local Storage generously and some\nvery simple "three-way merge" techniques. (CRDTs are fun, but not what I\nthought was needed because ballots are intentionally single user.) This\n"offline first" approach may seem especially like overkill for a\nmulti-page application because "the next page" isn’t likely to load when\noffline, but I think people are surprised how well MPA applications get\ncached and even when you are not intentionally expecting users to come to\nthe site while offline, the experience of becoming accidentally offline\nor even just needing to "save a draft until I come back" is fantastic if\nyou've designed for "offline first", I think. Because offline happens\nunexpectedly all the time and people often want time to draft things and\ncome back. In a multi-page application it especially helps to give that\n"feel" of a single page application, being able to make changes in one\npage and reflect them in a second, without actually being a single page\napplication.
\n(Between Butterfloat components caching well, the speedy loading of\nStamp-based components, and the fast loading from local storage of\n"offline first" data I’ve even heard surprised remarks that some users\nthought it was a very well optimized single-page application. I’m sure\nif I add CSS view transitions that illusion will feel complete. I may add\nCSS view transitions. As others are also saying, it’s a good time to start\nwriting MPAs again. I do recommend considering "offline first" as a useful\ntool even for an MPA.)
\nI’m still skeptical about the long term viability of LLMs in software\nengineering. It’s not going to replace most of what I do and I’m not the\nsort to “vibe code” entire hobby projects (much less professional\nprojects) because I’m still me and saddled with a goal to over-engineer\nfor scale and reliability beyond the bare minimum, but hobby projects\nstart to be something I want to do again when I can lean back on a cold\nwinter’s day with a Scotch and code review some moron Junior Developer\nthat’s great at copypasta and Stack Overflow and Wikipedia cribbing\nsolutions. It makes the real engineering easier when the grunt work is\ndone so quickly. It’s nice to have "a team" for solo projects now. That\nalso helps hobby work feel more like "senior-level" work: explaining to\njunior developers what to do is a good chunk of my day jobs and Copilot\ntakes instructions in similar (though not the same) ways.
\nI've got a couple wishlist items out of this project:
\nI think there’s some useful Action Items for other projects coming out\nof this one:
\n[Mozilla Persona]:
\n","date_published":"2025-04-27T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2024/11/17/butterfloat-stamps/","url":"https://blog.worldmaker.net/2024/11/17/butterfloat-stamps/","title":"Butterfloat 1.5.0: Stamps for Static Rendering","content_html":"Butterfloat released a big 1.5.0 with a big new building block\n(nicknamed Stamps) for server-side rendering and static ahead-of-time\nrendering for the static HTML parts of components. This meets a bunch of\nunder-spoken needs for JS-based view engines, fulfills a big early\npromise of Butterfloat, and does it with hopefully style and convenience.
\nMy guiding star for Butterfloat from the beginning was "Modern Knockout".\nThere's influences from React, and lessons learned from Angular's mess,\nbut I felt like there was also some things missing that Knockout was\ngreat at which have been missing for a while.
\nOne of the biggest of those, for me, was how Knockout was built during\nand somewhat epitomized (for me, at least) the somewhat now broken\npromises of the now passed "Progressive Enhancement" era.
\nI had made a promise to myself to include some "Progressive Enhancement"\ntools in Butterfloat and enshrined it in the issue tracker as the first\nand most important issue. It was something I prepared for in the base\n"DNA" of the design. It just didn't make the "MVP" cut of the original\nrelease.
\nI'm excited that Butterfloat 1.5.0 fulfills that promise for the first\ntime with Stamps. (It's an early "anniversary" gift, almost exactly a\nyear after the first release.)
\nOne of the prods that pushed me to think now was a great time to deliver\non a promise of "Progressive Enhancement" were multiple calls to do it\nin recent news and reports. Several great articles have been written in\nrecent months on the accessibility problems created by the "modern\nframeworks" of today's React and Angular for users on cheap devices and\nbad connections. Because these sorts of frameworks have become the\n"default" or the "best practice" or the "easiest road" in so many places,\nthey've become the tools in use even in places that should be\nprioritizing accessibility.
\nI don't think Butterfloat will single-handedly fix the anti-trend, but\nhaving tools for "progressive enhancement" was still important to me and\nthe time is always "now" and I appreciated the reminder that there were\ngood reasons to do it to help people that need it. Even if Butterfloat\nmight not be the most common choice to help solve that, I hope it helps\nat least one other developer to have another option to point to that can\ndo it and that looks good.
\nThe Butterfloat component model was already focused on making static\nHTML obviously distinct from change bindings (via Observables). Due to\nthis you can build a Stamp from any easily testable Component (and most\nComponents can be easily testable). There's no difference between a\nComponent that supports Stamps and one that doesn't. Stamps are always\nbindable at runtime, there's no need to choose between interactivity and\nstatic building a Stamp, there's no architecture/strategy/pattern like\n"Islands" to need to rewrite to. It's truly "progressive enhancement".
\nStamps continue the theme of taking more modern approaches than the\nstate of the art from the Knockout days. Where Knockout used a DSL\nwritten in comments and sometimes showed a flash of incomplete content\nwhile the library was loading. Stamps by default build into modern\n<template> and <slot> tags. They won't be rendered at all in modern\nbrowsers until instantiated or unless "prestamped" into the container.
I keep referring to Stamps as just the "low level" building block for\nprogressive enhancement/SSR/SSG. There are still more ideas to explore\nfrom them as a starting point:
\n<template> and <slot>, there may be good\nscenarios to enable rendering them via the "Shadow DOM" rather than\nbinding them with Butterfloat.I don't know when I'll prioritize any of that work, given at the moment\nthis is mostly a "free time" project (though a Production-ready one, if\nI may say so). I'd love contributors if any of the above ideas or others\nspark interest.
\n","date_published":"2024-11-17T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2024/03/13/node-packaging/","url":"https://blog.worldmaker.net/2024/03/13/node-packaging/","title":"Modern Node Packaging and Bundler-Free Living","content_html":"I've found myself giving multiple light tutorials on how simple modern\nES Module-only packaging can be in Node/npm packages. I've similarly\ngiven several tutorials on deploying web apps "bundler-free" (it's\nmore possible than many think). There's a lot of outdated advice on\nthese subjects, and some interesting superstitions, so I thought it\nwould be useful to blog about the state of things in 2024 as I know\nthem and hopefully update some out of date advice with helpful advice\nthat you can be lazier and things may be simpler than you think and a\nlot of the confusion is because of outdated advice.
\nI'll get into details at length, and some digressions along the way,\nbut I think the top-level summary is simple and worth bullet pointing\nup front. If you are looking to build, bundle, and/or package projects\nfor any or all of Node, npm, bundlers, and/or the browser, things are\nmuch simpler if you only build/bundle/package ES Modules:
\n"type": "module" and "exports" in package.json"main", only "exports", but "exports" can be as simple as\n"main" was"exports" understands "type": "module".js file extension.js file extensions for relative importsnode --test for unit testing"type": "module"The simplest thing to do when going ES Module only is to add a\n"type": "module" to your package.json. That does most of the work.\nIt says all .js files are ES Modules. You mostly only need the .js\nfile extension for everything at that point, so long as everything is\nmodules and you want everything to be modules. You can forget entirely\nyou ever heard the file extension .mjs and you can mostly avoid ever\nneeding a .cjs file and that only for increasingly rare developer\ndependencies.
"type": "module" works in all currently security supported Node\nversions. It works for a few versions back out of security support,\ntoo, now.
In your package itself: You don't need to build any CommonJS files. You\ndon't need to build any AMD or UMD files. Let everything be ES Modules.\nIn your development processes CommonJS should be rare to non-existent\nand can use the .cjs file extension.
Yes, you need to have the .js file extension on all your relative\nfile imports. The browser expects filenames to be specific and include\nthe file extension. Deno and Bun both require it. Most recent versions\nof Node in "type": "module" packages also require it, though there's\nstill a few ways that slips through the cracks. It's only some bundlers\nthat don't require it today.
I love Typescript. Typescript is great. Just set Typescript to target\nES Modules, and you only need to target ES Modules. Just drop the JS\nfiles in place (the default build configuration) and include the .js\nfile extension in all your relative imports. (Yes, .js not .ts.\nTypescript decided it was better not to transform this and to emit it\nas-is, so it wants you to use .js just like Node or the Browser\nexpects at runtime.) Typescript tries to auto-detect if you are using\nfile extensions and will start adding the .js for you in its\nrefactoring/auto-complete added auto-imports once you do it enough.
My advice lately is that a reasonably good combo (per caniuse\nstatistics) for "module" and "target" in your tsconfig.json is\nes${new Date().Year - 2}. I've been using "es2022" lately for both.
The only CommonJS file I find I need today is the .eslintrc.cjs file.\nIt's the only place in my projects recently that you will see a CommonJS\nfile at all, and certainly the only need I have for the .cjs\nextension. Because it is the only exception I currently have, it feels\nworth naming and shaming the one tool that doesn't yet support ESM\nthat I like to use. That looks to finally be fixed in upcoming eslint 9.
Jest still calls ES Module loading "experimental" and has weird bugs\nabout it. Karma is terrible. (Node is already a v8 instance, you don't\nneed to boot another v8 instance from your v8 instance just to run\nunit tests. That's not unit testing, that's some weird relative of\nintegration testing.) I recommend mocha or node --test. Mocha is\nancient (older than jest), and minimalist, but was also one of the\nfirst harnesses to hand ES Modules well. (Sometimes the old dogs learn\nnew tricks better, I suppose.) node --test is the new kid on the\nblock, new enough many developers haven't yet discovered it. It's\ngreat to have a test harness built-in to Node. That's one fewer\ndependency you don't need. It's similarly minimalist to mocha, but\nslowly gaining features, too. You can import all the asserts you need\nfrom 'node:assert/strict' and the describe/it test suite setup\nfunctions from 'node:test'.
"exports": "./main.js""type": "module" does most of the work at runtime, but if you are\npackaging you need "exports" in your package.json. Don't include\n"main". (There are no bundlers that understand "exports" but not\n"type": "module". There are bundlers that see "main" and\naccidentally or intentionally ignore "type": "module".)
"exports" has a bad reputation for being complicated and confusing. It\ncan be as simple as "main" if you let it: "exports": "./index.js".
The requirements to use simple "exports" are basically everything this\nguide is about: ES Modules only, with "type": "module", and one "front\ndoor" for "bare" Node package imports.
The useful difference between "main" and "exports" is that\n"front-door" only approach. With "main" Node would still let you\nimport from any .js file in the package and with "exports" you only\nget the declared exports and nothing else, no more "sneaking in the\nback-door". This is useful as a package author for properly\nestablishing your public API. This is useful as a library consumer for\nmaking importmaps easier to build (less accidentally importing\nsub-files after the well known "bare" imports).
Even if you do need more than one "front-door", you can still use a\nsimpler form of "exports" and ignore all the suggestions regarding\n"import", "require", and "typings" subkeys:
{\n "exports": {\n ".": "./index.js",\n "./optional-cool-thing": "./cool.js"\n }\n}\nTypescript since 4.7 has no problems picking up typings from packages\nthat include the TS sources or obviously named .d.ts files for any\n"exports" configuration, including these simple ones, so long as files\nare simply predictably side-by-side.
You might not need a bundler anymore, at least in development, but\nsometimes even in Production you need less bundling than you think in\n2024.
\nYou can use an importmap to import "bare" Node package names in the\nbrowser.
\nES Modules work great in today's browsers with <script type="module">.
In a growing number of the simplest cases you can just prune and ship\nnode_modules to a web server, with an appropriate importmap.\nnpm prune --omit=dev will remove all of your development\ndependencies. You may need to spot check for large files like test data\nto also prune.
You may need to bundle some of your dependencies, especially ones that\ndon't yet ship ES Modules or haven't yet adjusted to including .js file\nextensions for browser compatibility. You can bundle one dependency at\na time. "Vendorizing" your dependencies like this can be a one-line\ncommand with a bundler that itself outputs ES Modules. I use esbuild\nfor this with the --format esm flag, it's generally a simple one-line\nCLI command that I can include in package.json "scripts" and/or\ndocumentation.
ES Modules loaded as ES Modules is a great development experience in\nthe browsers. You may not even miss "hot reloading" (and you can try\nto implement it without the big frameworks and bundlers if you still\nwant it).
\nIn HTTP/2+ and some well configured/behaved HTTP/1.1 servers there's a\nlot less of a "per-file" performance hit than developers historically\nworried about. Many ES Modules libraries are collections of lots of\nsmall files, but the always asynchronous loading of\n<script type="module"> combines with some optimizations in dependency\ngraph loading for smoother performance than many old pre-bundler\nmemories.
You can use Browser performance tools to make bundling decisions based\non real production data. Rather than always bundle everything, see\nwhat your actual browsers and servers are doing with real world\ndependency graphs. You may find they download less overall than your\nprevious bundles. You may find that you only need to bundle specific\nsub-graphs of your dependencies as they become specific problems.
\nYou don't have to take my word on it, or any framework's big default\nbundling configuration: try it yourself and use real data. You may be\nsurprised at how many fewer reasons to bundle there are with ESM. (I\nhaven't been that surprised: I shipped AMD applications a long time\nago with very little bundling, and that was just HTTP/1.1. ESM flies\nhigher and further, especially on HTTP/2+.)
\n"sideEffects": falseIf you package a library and expect someone (including yourself) to\nuse certain bundlers, especially Webpack, it may make sense to still\ninclude the non-standard "sideEffects": false flag in your\npackage.json. This suggests to Webpack (and the few others) that it\nmay tree-shake your library at its most aggressive. Many other bundlers\ndo either deeper closure parsing or trust "type": "module" says you\nknow what you are doing with ES Modules and don't have CommonJS\ntransition code and synchronous requires.
You don't need Babel in 2024. It was a great tool for its time. The\nnumber of polyfills and actual amount of transpiling you need for\ncompatibility in 2024 is minuscule (check caniuse statistics if you\ndon't trust me on this). If you need JSX consider using something\nlighter like Typescript and/or esbuild. Everything else you think you\nmight need is already in Node or your Browser now.
\nIf you want to see an example library packaged this way, with an\nencouragement to try bundler-free living (at least in development),\nand with direct documentation on these same subjects, I can offer\nButterfloat as one such\nuseful open source library.
\nThe Butterfloat Getting Started Guide includes some\nsimilar recaps to this blog post, including an example of bundler-light\nliving, showing how to spot bundle just the RxJS dependency and then\nuse an importmap for the vendorized RxJS and the node_modules "bare"\npackage import of Butterfloat to setup a very light-weight development\nenvironment.
In the ES Modules-only world of Node/npm/browsers/bundlers, everything\nshould start to be easy again. Use "type": "module" and you can\nignore a lot of old advice and/or outdated confusion.
I've been working on a modern web view engine named\nButterfloat (now in pre-release) that is\ninterestingly Knockout-inspired, but with a focus on Typescript and\nas pure as possible RxJS Observables. I think it has been a great\nproject, and I'm proud of the results I've gotten as a solo\ndeveloper doing it in the middle of other tasks in just a few months.
\nI've been on an interesting journey for some time now. It started\nwith me criticizing some deep architecture decisions of Angular and\nhow their wishy-washy approach to RxJS made mistakes too common and\ntoo easy. From the things that I experienced getting strong\nperformance out of an RxJS-heavy Angular application was an effort\nof futility and required fighting uphill against a lot of "Angular\nBest Practices" as seen in an ecosystem full of blog posts and Stack\nOverflow answers available for copy and paste.
\nWhat happened next was that I hit a Production issue in Angular that\nwas precisely the sort of ghost story that developers least want to\nexperience: it was a massive, reliably repeatable performance stall\nout that debug builds could not reproduce at all, even when pointed\nto Production data and following every one of the same steps,\nmeticulously. This led me to deep diving into ways to remove Zone.js\nand many aspects of Angular's change detection that most application\ndevelopers using Angular don't seem to encounter. That led me to the\nneed to pursue a "Component Framework" to help build RxJS-focused\ncomponents in a way that tried to lead to a "pit of success" in\nterms of RxJS best practices, removing the need for Zone.js, and\ntaking a different approach to Angular change detection. I called\nthat framework Pharkas after fictional videogame pharmacologist,\nFreddy Pharkas. (Because I felt like I too was a frontier pharmacist\nslinging Rx in a lawless frontier.)
\nI had a few people ask if I would consider taking the lessons learned\nfrom Pharkas and some of the ideas posited on how to build an\nRxJS-focused templating language and build something from scratch\nfrom that. I considered it more than once, but wasn't sure that\nwould be an itch I felt a need to scratch. Surely someone else might\nbuild that at some point, and generally I've been happy with React\nas "good enough" for most projects.
\nIn August of this year, after more than 8 years in that position, I\nwas unceremoniously tagged in a "headcount reduction" due to a new\nincoming CTO and an expectation of a shift in software strategies.
\nAmong the many, many tasks involved in a full time job search, I\nstarted working on one of the more unique to a software developer:\npolishing my GitHub profile and revisiting some of my public\nrepositories on GitHub. Several of mine were written in Knockout,\nwhich was the style at the time, or which was a preference of mine\nfor "quick and dirty proof of concept". In dusting the cobwebs,\ndealing with the bitrot, paying down some of the tech debt of the\nCompRadProg demo, in particular, I was thinking that\nit might be great to upgrade it to something modern. The more I was\nlooking at it though, the more I was torn by how "elegant" some of\nmy View Models have been in Knockout, including in this "quick and\ndirty proof of concept" demo that I love to talk about but don't\nreally have much left to do with it.
\nIn thinking on this, it started to seem that the tools were in my\npower, that I should just build my own view engine with real, pure\nobservables and Typescript and otherwise mostly vanilla ES2022+. I've\ntried to stick to one major runtime dependency: RxJS. I've tried to\nstick to one major build-time dependency: Typescript. (You could\nuse Babel instead, but you probably don't need Babel. I use esbuild,\nmyself. But as just a view engine, Butterfloat in unopinionated on\nyour build tooling choices.)
\nI think a lot of the modern web frameworks have learned from Knockout\nin some way or another. The impression I have of Angular, Vue,\nSvelte, and Qwik is that all of them were too enamored with the\n"magic" of Knockout's "computed" observables, and never quite\nlearned some of the lessons that Knockout's observables are more\naccurately Subjects in modern observable nomenclature and the leak\nof imperative concerns across API boundaries was never quite seen as\nthe problem it should have been. To me, that was often the weakness\nof large Knockout codebases and seems the continued weakness of many\nof today's Knockout successors, too.
\nThis is where things start to get interesting. A simple Hello World\nexample at first glance looks a lot like an ordinary React function\ncomponent. I wanted the only compiler involved to be Typescript as\nmuch as possible, so Butterfloat makes heavy use of TSX\ninfrastructure which is already an HTML-like template engine with a\nlot of features it would take me quite a bit of effort to reinvent\nfrom true scratch. A Butterfloat Component is a function. (It's\nalways a function at this time, there's no equivalent to a React\nclass component at all.) Just as with React, it can take as a first\nargument some number of properties that reflect the "attributes" in\nTSX that were passed to the component.
\nThat's where things start to diverge. A Butterfloat Component takes\nan optional second argument called the Component Context. This\ncontext provides some useful helpers, which we'll get to.
\nOn top of that, a Butterfloat Component is static by default.\nButterfloat is not a Virtual DOM. In a Knockout-inspired feeling that\nmore of an application's DOM is static than not, it has no diff and\npatch mechanisms of the intermediate description language its TSX\ncompiles to. The only parts that can and will change once\ninstantiated to the DOM are things bound to Observables and other\nComponents (which of course "secretly" themselves become\nObservables, too, at run time).
\nThere are testing benefits to having this rich "intermediate\ndescription language" similar to the virtual nodes of most Virtual\nDOM engines. Some types of Butterfloat Components may be tested\nentirely in Node without a need for useful DOM faking/testing\nlibrary such as JSDOM. The descriptions can even be richer than is\ntypical in a Virtual DOM environment because Butterfloat doesn't\nexpect most of them to be long-lived or commonly created so it\ndoesn't need to try to save space by using shorter names or other\nsuch clever shortcuts. On top of that the descriptions are natively\nwritten in Typescript so benefit from some type-level distinctions\nthat you don't commonly see in Virtual DOM virtual nodes.
\nCycle.js is a great Virtual DOM with Observables, if that\nis what someone is looking for. Butterfloat tries to be a "static\nDOM" with Observables in a way that I feel like I haven't really\nseen since Knockout.
\nOne further divergence that I'm particularly proud of is that\n@types/react is a multi-thousand line file of seemingly\nhand-maintained types, other JSX/TSX implementations either copy\nand paste this work and hand merge it, or don't bother entirely. I\nbuilt a much fewer line bit of meta-typing on top of Typescript's\n(auto-generated) lib.dom types. I think I've got a better\ndeveloper experience than React at a fraction of the cost of\nlabor (no matter how much of that labor is volunteer work by\nDefinitelyTyped organization contributors). (One of the ways it is\nbetter: the auto-generated lib.dom types include MDN direct links\nin the documentation comments. I get those "for free" by\ninheritance.) I expect other JSX/TSX implementations to learn from\nthis example now that one of us has done it, and I keep debating if\nI want to try the political game of PRing something like it to\ngood old @types/react itself.
My design documents for this project for a few days were in a folder\ncalled Dr. Mario after the only other, better known, fictional\npharmacist in videogames, in direct relationship to my Pharkas\nproject. I spend those days searching for a better name. I was at a\nfootball game where I was especially thinking about how much I'd like\nto somehow honor Knockout in the name without sounding too directly\nrelated to Knockout (or its once and future intended successor Total\nKnockout). By that point I realized that the thing most center in\nthe distance that I was staring out at, mostly unfocused, while\nthinking about this project was the logo for the Louisville Muhammad\nAli International Airport. One of Muhammad Ali's well known\ncatchphrases was the classic "Float like a Butterfly, Sting Like a\nBee". That seemed like a good idea for what I was going for with any\nsort of Knockout-inspired project and satisfies the boxing metaphor,\nalbeit obliquely.
\nIn the spirit of the Greatest Champion of All Time, I feel in a good\nplace to proclaim that with Pharkas I built a tool better than\n(baseline) Angular and here with Butterfloat I have built a tool\ngreater than React in the spirit of Classic React (just a web view\nengine). It is the greatest view engine for the modern web.
\n","date_published":"2023-11-28T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2023/11/16/prismatic-decimal-system/","url":"https://blog.worldmaker.net/2023/11/16/prismatic-decimal-system/","title":"The Prismatic Decimal System","content_html":"I'd had a passive interest in finding this novel for years. It had\nbeen first mentioned to me in the footnote of an autobiography of a\nmodest local 1950s television star as a favorite novel of her\nchildhood. Though she referenced it only directly in passing in the\nflow of a larger discussion of her much beloved children's show, there\nwas a sense that perhaps this book played a larger role in some of the\ncreative spark of the show as a whole. I had a sense that there were a\nlot indirect references and in jokes to that novel in that section and\nI was curious to find out more. It seemed implied that the book was a\nwell beloved book at least regionally and the author presumed some\nfamiliarity with the contents of that book. I didn't think I could\ntell for sure without reading that novel on my own so I added it to a\nwishlist at the local free public library.
\nThe library's online records told me the history of only the last\nthree copies of the book in the system, though I was glad for whatever\nlibrarian had inputted even that much information into the digital\nsystems about a 1910s small press book from a publisher that lasted\nonly a dozen years and never really sold much outside this city.\nUnfortunately for my search the last three copies were listed as\n"damaged beyond repair", "sold at fundraising auction", and "on\ninter-library loan; overdue for return as of 03/1972". I figured that\nwas the end of my search, but I knew enough to leave it on my wishlist\nas sometimes inter-library loans would turn back up (even ones somehow\ndecades overdue) or a librarian would spot an archived copy. What I\nthought most likely this century and given the book was on the edge of\nbeing public domain even in 1972 (given the publisher bankruptcy, and\nno known author's estate, probably extremely likely it was already\npublic domain then) sometimes a scanning group would find a copy and\nbuild an ebook. The wishlist had automatically sent me e-copies of\nother strange finds over the years.
\nWhat I least expected was the handwritten letter that arrived on the\nlibrary's letterhead years after I'd even forgot placing it on my\nwishlist. It was a pleasant surprise and I was almost surprised how\nmuch I appreciated it more then than had it shown up as email.
\n"Dear Ms. Lynne,
\n"It came to my recent attention in discussing books with one Mr.\nForsberg that he has a copy of J. Y. Milburn's Flight Into Night— A\nSlumbering Fantasia in his private collection. I mentioned knowing at\nleast one library patron with it wishlisted as to read for several\nyears ongoing and that apparently piqued Mr. Forsberg's curiosity. Mr.\nForsberg made it clear that he does not loan books of such vintage to\nthe library or its patrons as a general policy, but that this was a\nparticularly interesting book worth loaning to a new reader, if he\nwere given the opportunity to meet with the patron, face to face,\nfirst. It's rarely good library policy to recommend engaging a private\ncollector in a direct manner such as this, but Mr. Forsberg is a close\nfriend both to me personally and to the library system as a whole and\nI promised to at least pass the offer to visit his private collection\nand maybe loan this book you've been looking for. Mr. Forsberg assured\nme that it would be worth your time to read this book and he'd love to\nmake that connection. Please find attached Mr. Forsberg's card should\nyou be interested.
\n"Regards and thank you for patronage and the time out of your day to\nread this letter,
\n"Verity Hayward"
\nI had no trouble finding the card Mx. Hayward had attached to the\nletter. "X. Forsberg, Raconteur (Retired)" was the dominant text on\nit, with only a phone number, what appeared to be a bare street name\nwith no other address part but the county's name beside it. I was\nweary about anyone that might call themselves a "raconteur", of\ncourse, but something about that "(Retired)" seemed humanizing to me,\nand I wasn't sure why I felt that way.
\nIt took me a few days to decide if I would reach out to Mr. Forsberg.\nIt seemed like a lot of effort to go through just for a chance to read\na book that had been suggested to me merely by recommendation of a\nfootnote of an autobiography. But I was also never one to turn down\nany kind recommendation from a librarian, and especially not one sent\nas a handwritten note (though admittedly this was my first). I have\nalways trusted librarians as a general rule, but if you cannot trust a\nlibrarian named after "Truth" I'm not sure who in the world you could\ntrust, even if I don't think I've met Mx. Hayward in my tiny branch I\nmost often frequent.
\nPushing my courage and pressed by my curiosity on one rainy afternoon\nI finally convinced myself to call the number on Mr. Forsberg's card.\nIt took me a moment to find where I had last hidden the Phone app on\nmy home screen, having so much less need of it this century. This\nritual search added its own little needles of anxiety into the\nprocess. I was surprised when the ring was answered almost immediately\nby what sounded like a aged and yet sweetly voice, "Mr. Forsberg's\nprivate residence, who may I say is calling?"
\n"June Lynne, I received Mr. Forsberg's card from a librarian to\ndiscuss Milburn's 'Flight Into Night'?" I didn't mean for it to be a\nquestion, but it certainly came out as one in that moment between\nnerves and hesitancy.
\nThe voice on the other end sounded excited and happy for me, "Oh\nexcellent! Mr. Forsberg adores that book. Yes, Mr. Forsberg would be\ndelighted to extend you an invitation to meet with him here at his\nresidence to discuss it. Unfortunately, Mr. Forsberg keeps a very busy\nschedule so it can't entirely be at your convenience. Mr. Forsberg's\ncalendar suggests that this Saturday Afternoon say at 3 PM would work\nbest for him, would you be available?"
\n"I, uh, yeah I can make that work." I did not expect things to move so\nfast to a scheduled appointment, but had to admit I was free Saturday\nnight.
\n"Excellent. I will let Mr. Forsberg know to you expect you here around\nthen. Anything else I can help you with?"
\n"I'm not sure I know what the address is?"
\nThere was a pause, then a hesitant, "I believe it should have been on\nthe card?"
\n"Oh, well there's a street name but there doesn't seem to be a street\nnumber."
\n"Yes, that's the address."
\nThat was not at all the answer I was expecting, but I was not going to\nlet my confusion trap me in a longer phone call, "Alright, thank you,"\nand we exchanged the usual phone conversation ending pleasantries and\nhung up.
\nThat Saturday was warm, but not too warm, and overall a lovely bright\nday. I was surprised that the maps app on my phone had no trouble\nfinding the address as I started to type it. As secretive as Mr.\nForsberg seemed to, only passing his address around on physical cards\nit seemed, he couldn't stop it from being indexed into all the usual\ndatabases. Though I appreciated that a lot in this case because I had\nno idea how I would have found the address if it hadn't been\nsearchable on the phone app, I know I've become too reliant. I guessed\nI'd try to call a librarian at that point, but I had a route and that\nwas a theory I didn't need to test.
\nThe route took me down a city highway I've driven a million times and\nyet somehow just two turns off it I entered what felt like a forest.\nThere was no room in my mental map of the city for this forest, and I\nwould imagine even a small park in this area would be something that\nI'd recall noticing on maps before. The phone's satellite imagery\nreassured me that this forest had probably been here the whole time\nand it was maybe my mental map that needed updating, but these trees\nfelt too old and wild to be contained somewhere in a city's limits.\nThe street that was the entirety of the address was a small country\ngravel road leading deeper into the forest. A country gravel road was\nalso something that didn't quite fit on my mental map of this part of\nthe city. It wasn't very far along the gravel road before it opened up\ninto a giant clearing. Here the satellite map showed a blur where the\nclearing must be, in the center of the forest and I presumed that at\nleast some privacy could be bought even in the satellite age. Between\nthat and the number of buildings that were scattered across the\nclearing I was starting to get an impression of an eccentric amount of\nwealth involved (if I'd not already been making assumptions from the\ncard and the phone call).
\nThe residence campus, and it seemed like a small college campus of\nsome strange sort, had a clear house looking building centrally beside\nthe gravel road, which seemed the most obvious place to stop and park.\nMy eyes wandered across the other buildings. They had a variety of\narchitecture styles and materials that seemed to imply an organic\ngrowth over many decades. Only a few of them seemed to offer any\ndirect hints of their use. There was one full of windows and a lot of\nfog on its windows yet greenery visible where you could see through it\nimplying a green house or conservatory of some sort. There was (if I\nwas counting the number of sides correctly) an hexagonal building with\nan intriguing glass dome atop that I clocked as the library only once\nI realized that seated on plinths flanking the entrance were\nengravings of probably Athena or perhaps Minerva, marking it a hall\nfor wisdom.
\nI had barely mounted the steps towards the porch of main house when a\nmatronly stout woman bearing an iPad like a weapon arrived to\nintercept me from further around the porch (which appeared to wrap the\nentire house). With a deft, practiced maneuver she moved the iPad up\nand under the crook of her left shoulder, and extended her right hand\nin greetings, "Ms. Lynne, I presume?" I nodded as I took her hand into\nhandshake and she continued, "I'm Mrs. Montgomery, Mr. Forsberg's\nChief Executive Officer, we spoke on the phone the other day. Mr.\nForsberg has decided to take tea in the garden on this delightful\nafternoon," her handshake was firm and commanding, "If you will follow\nme, I will lead you to the garden." She broke the handshake,\nunholstered the iPad and glanced at it, then proceeded to lead me\naround the house.
\nFrom the first moment of meeting Mr. Forsberg I had a very tough time\ndeciding if he were some sort of monster or some sort of muppet. As he\nunfolded himself from the garden chair, he kept seemingly growing\nuntil he stood above me at what should have been an inhuman height. He\nwas tall and angular, yet seemingly far too skinny for his frame, in a\nway that looked like someone had accidentally stretched a small boy\nout longwise like pulling taffy. He was possibly the ugliest man I had\never met in person, yet somehow one of the most charming as well.\nThere were hidden delights in the way his eyes glittered in the\nsunlight, and every part of him animated with more life than the\naverage person seemed to. Somehow a part of me kept being surprised by\nthat over-exaggerated animation and it's surprising grace and fluidity\ndespite a seemingly very awkward and gawky frame making the movements\nthat much more implied to me that just out of range of my eyes were\nmarionette strings or a puppeteer's arm. They say that when you meet a\nmuppet like Kermit it's very easy to get taken into the illusion and\nyou don't want to see the strings or puppeteers after only a few\nmoments working with him, and not even moments into a handshake with\nMr. Forsberg I had decided that I did not want to dispel the illusion\nand check to see if he was a muppet, even if I would constantly be\nconfused for the rest of my relationship with him that I would never\ndecide if he was more monster or muppet.
\nMr. Forsberg invited me to take tea with him and within moments of my\nacceptance and a light few presses by Mrs. Montgomery on that tablet\nof hers, a cook had brought me a cup of Orange Pekoe and an assortment\nof light cheeses and olives to accompany it. Somewhere in the middle\nof pleasantries such as the lovely Saturday afternoon weather and the\nbeautiful garden around us, Mr. Forsberg offered, "Please, call me\nXavier if you would like," and I was charmed by it in part because of\nthe somewhat incongruous feeling knowing his first name gave me. It\ndid not strike me as the sort of first name of either a monster or a\nmuppet, and maybe not even a first name I would expect from someone so\nseemingly always formal by contagious force such as Mr. Forsberg.\nSomehow settling into calling him Xavier did not dissuade him from\nsticking to "Ms. Lynne" in all cases of address. It started to give me\nthe impression that "Raconteur (Retired)" was much less a\nself-described affectation and somehow an accidental label given him\nby some rival. I shouldn't have found it charming, but it came across\nto me as very charming and somehow natural and native to Mr. Forsberg.
\nEventually the general pleasantries gave way to the specifics and\nXavier asked how I’d become aware of Milburn’s “Flight Into\nNight” and I mentioned that autobiographical footnote that had lead\nme down the curious path to meeting Mr. Forsberg. Xavier nodded, and\nadmitted to having also read that autobiography. I mentioned my\nthoughts from the time I read it that perhaps Milburn’s “Flight\nInto Night” played a larger role in the context of the children’s\nshow and its origins than just a single footnote might imply. Xavier\nnodded along and then congratulated me on my “astute\nobservations”.
\nWe sat in comfortable garden white noise (some eager crickets, some\nbirds chattering sweetly among themselves). I realized I had finished\nthe available cheese and olives and my tea was finished.
\n“Well,” Mr. Forsberg cleared the silence somewhat hesitantly, “I\ncan tell you are fellow book reader after my own heart and I would\nlove to hear your book report on Milburns’s work once you finish it.\nI’d love to give you access to my family’s library.”
\nXavier suddenly had a key in the palm of his hand. I did not catch it\nif he had palmed it from a jacket pocket from one of his big sweeping\ngesticulations or even perhaps if some puppeteer’s stage hand had\nplaced it there. (Though I was only somewhat disappointed the key was\nsimply a standard modern Yale lock, not some monstrous ancient cast\niron thing or something even more fantastically fairy tale.)
\nXavier moved to hand me the key but then paused, “I’m afraid I\nmust add one more stipulation to the terms: none of the books are to\nleave the grounds. Though you will be treated as a very welcome guest.\nYou will be free to come and go as you please. I’m sure that Mrs.\nMontgomery had already logged your vehicle into the security systems\nand will only need a head’s up in the case you plan to arrive in a\ndifferent one. She can show you how to request tea service if you wish\nfor it, and I’m sure the chefs would be happy to account for you in\nmeal planning if provided enough lead time. I’m biased of course,\nbut I believe there are many fantastic spots, hidden and not so\nhidden, to fall into a book throughout my homestead. On days such as\nthis, you might make use of this garden, of course, or there are\nhiking paths out to some lovely little grottoes and scenic points. One\nof my favorites has a surprising view of the downtown skyline. Indoors\nthere are of course study nooks throughout the library and I would be\nhappy to introduce you to some of the lesser used studies and sitting\nrooms in some of the guest buildings if you want some variety.”
\nIt was my turn to hesitate as that was a lot to take in. It certainly\nwas inconvenient, but there seemed to be far worse places to read\ninteresting books than gardens and library nooks where someone else's\njob is to serve you tea. I also found that I was appreciating thanks\nto such a rapid infodump how much Mr. Forsberg's hesitancy was perhaps\nmore an over-eager hope of and concern for being a good host than a\nworry what sort of person he was giving access to his family's\nlibrary. I realized I had something of a term of my own as I thought\nabout Xavier's offer, "I really appreciate the offer, Xavier. If I may\nadd a term of my own? If the book is what I've heard it to be, it\nbelongs in the public domain. I'd love to scan your copy to make it\naccessible as an ebook for others that may not receive such a generous\noffer from a wealthy patron."
\nThere was a very complex wash of emotions across Mr. Forsberg's face,\ntoo fast for me to catch any particular individual ones, but he\nsettled into a response I did not expect from someone of his presumed\nwealth, "Ms. Lynne, it would pain me greatly to let you volunteer such\nlabor when I can easily pay for it. I've brought in Ms. Hayward as a\nconsultant on several of my past library science needs and she's been\nnothing but professional in projects such as that. But first, I would\ncertainly appreciate your opinion on that large if that you brought\nup. It is a remarkable book in my opinion, but I shall await your own\nbook report to compare notes, Ms. Lynne. We can discuss things like\nscanning that book after you've read it and given it time to digest,\nyes?"
\nHere again I found such an interesting and effectively charming\neagerness in Xavier's eyes especially. I nodded in agreement, it made\nenough sense, and reached out my hand. He gently dropped the key into\nmy own hand and clasped my hand in something that wasn't quite a\nhandshake and wasn't quite a gentle pet, before just as gently\nreleasing my hand.
\n"Wonderful, Ms. Lynne. I am eager to hear your book report. I've found\nthat first impressions of the family library are most interesting\nwithout a formal tour. Perhaps when you are ready to deliver your book\nreport I'll explain a bit more and show you some of the library's more\nhidden features. I can have Mrs. Montgomery show you to the library\nbuilding so you can get started."
\nI smiled, "I believe it's the hexagonal building I spotted from the\nstreet with the engravings of Athena watching its door?"
\n"Yes, of course! Very astute," and with that great smile of an\nacknowledgement from Xavier, which I found strangely warming, I stood\nand thanked Mr. Forsberg again for the opportunity to make use of his\npersonal library.
\nStanding just outside the library door I had a sense that the Forsberg\nFamily Library was probably bigger than my entire regular branch of\nthe free public library. (Though I liked that it was one of the\nsmaller branches.) The exterior door of the library lead into a very\nsimple vestibule. A couple of antique looking brass lamps lit up as I\nopened the door and I presumed they were on a modern motion sensor.\nDespite being a couple of relatively small lamps with modern LED bulbs\n(I presumed) they did a great job lighting the entire vestibule. On\none side was a tiny cloak closet and the other an old fashioned card\ncatalog. Relatedly, a QR code had been printed and posted above the\ncard catalog. A note beside it that I recognized in Ms. Hayward's\nhandwriting stated simply "Use QR code for other catalog services, but\nplease continue to use the card catalog as the main index. -V". I of\ncourse knew the author I was looking for so I only needed the main\nindex, presuming it was sorted by author name. I was glad for having\nhad an eccentric elementary school teacher of mine force us all to\nlearn the basics of a card catalog, despite it being an incredibly\nuseless skill these days when all library catalogs were digital.
\nI opened the drawer that promised to contain Milburn, J. Y. and was\nimmediately drawn into how much of a colorful explosion the cards\nwere, and I wound up taking my time flipping through its contents in\nsearch of the card I needed. Every card had the expected author name\nand book title on the left hand side, and various other details such\nas descriptions or author blurbs printed below those. Every card also\nhad at least a square of color in the upper right, like a test swatch\nfrom a painting company. In a few cases the entire cards were painted\nor printed the color of the upper right swatch. In some fun cases I\nstumbled across the swatch expanded out into mini-paintings and\nembellishments, such as on the card for Melville's Moby Dick where the\nblue swatch color was part of a blue whale trying to swallow the book\ndescription. Below the color swatches were decimal numbers, but they\ncertainly didn't seem to align with Dewey Decimal numbers in the\nslightest. For one thing, even fiction works such as that Moby Dick\ncard I passed across had these decimal numbers, which Dewey himself\nnever bothered with, and for another the few Dewey Decimal categories\nI could recall off hand when I saw similar numbers flip past did not\nmatch the expected contents at all. The card for Milburn, J. Y "Flight\nInto Night— A Slumbering Fantasia" was in the catalog right where I\nexpected it to be. It had a very interesting crimson/purple shade as\nits color swatch, perhaps resembling the tones of the later parts of\ndusk. A part of me wanted to keep shuffling through the cards to see\nwhat other details might pop out at me, but I was also very curious\nnow to see the library itself.
\nWith the book's card in hand I swung the door open to the library\nproper. The vestibule door opened up into a massive flood of natural\nlight from the dome overhead. The vestibule felt claustrophobic in\ncomparison to the wall of light that spilled out from the building's\ninterior. That moment of transition took my breath away even before I\nstarted to take in the contents of the library itself. The vestibule\nhadn’t seemed that dark while exploring the card catalog, but it\nfelt like it took a while for my eyes to adjust to the much brighter\nbuilding interior. Even before the shift to lending mostly ebooks,\nI’m not sure if my regular library branch ever had nearly as many\nshelves as I could see in this private library. The hexagonal shape of\nthe exterior patterned the interior as well. All six interior walls\nwere lined with shelves of course, including the wall behind me with\nthe library’s entrance door buried in the center of shelves. Looking\ntowards the interior were concentric hexagonal rings of even more\nshelves, slowly growing in height as they progressed toward the center\nand an impressively looming central hexagonal spire of shelves. From\nthe entrance angle it felt like the shelves almost made stairs for a\ngiant to ascend to a throne just below the dome.
\nThe shelves weren’t all entirely filled, presumably giving things\nroom to grow, but it was still impressive just how many books I could\nsee even before I started to explore the rings in more detail. The\nmost prominent feature of the shelves, though, was that the covers of\nthe books that shared each shelf all shared similar colors to each\nother, with subtle gradient shifts across the shelves. Each triangular\nsextant of the library was dominated by a single primary color, and\nthere seemed to be a pattern to the flow of the colors between and\namong the rings. It was a beautiful color wheel that seemed to be the\ncentral pattern to the library, though it didn’t seem to exactly\nmatch any color wheel I was familiar with.
\nI could easily see why the swatch colors dominated the library’s\ncards so much. Assuming you weren’t color blind I could tell that\nyou could track down individual books just by color sample alone as\nyou got used to how the colors shift across the color hexagons. It was\nalso quickly clear to me based on how the shelves were marked that the\ndecimal numbers were still very handy for finding books. The hundreds\nplace seemed to exactly match the sextants numbered 1 through 6. The\ntens and ones places gave a sense of which ring, though it wasn’t an\nexact or clear cut match. I had no idea what the decimals might\nrepresent, but there were sometimes six or seven digits. Between the\ndecimal number and the color swatch it didn't take me hardly any time\nto find the book I was looking for. It was between a treatise on art\ndeco architecture and a biography of a Russian playwright, and I\ncertainly had no more idea what the decimal numbers actually\nrepresented in this library as there was clearly no categorical\norganization here.
\nOther than the title and author on the spine of the cover I didn't see\nany other marks such as a publisher's mark. As I pulled the book off\nthe shelf it became clearer that the dust jacket wrapped around the\nbook was a unique and custom laminated work of art. It had a\nstartlingly lovely dusk painted across it from back cover to front\ncover. The setting sun was featured prominently on the back cover and\na kid whooping and hollering while riding a flying carpet took center\nstage on the front cover. No other words or adornments on either back\nor front covers except an artist's signature, "R. Forsberg, Jr".\nInside the dust jacket, it was a classic dull brown leather bound book\nof the expected sort for its age. I found I really appreciated the\nbeauty of the custom family cover, helping it to feel at home on such\ncolorful shelves. A manilla card holder was the only other addition to\nthe book, and one you would expect of a library. I slid the books card\ninto its holder, just as expected and wandered over to a nearby study\narea to start into the book.
\nIt took me several weeks of trips to the Forsberg Family Library to\nfinish Milburn's "Flight Into Night". The prose was magical but\nincredibly dense and slow to read. Over those weeks I became very\nfamiliar with some of the reading spots in the library itself and in\nthe garden. I did manage to find the hiking path to the city skyline\noverlook Xavier had mentioned. I had Mrs. Montgomery show me a lovely\nsitting room in one of the guest buildings when I was craving an\nindoor reading spot that was a bit more variety (and a little bit more\ncozy and comfortable, like reading on the couch of a beloved great\naunt in her country cottage). I rather took for advantage the staff's\noffer of tea service and was amazed at the selection and the variety\nof charcuterie and tapas bites that would accompany the pots of tea at\nchef's whim. I tried not to take advantage of the meal planning for\nsomewhat unreasonable fear of never leaving Mr. Forsberg's estate\nagain if I ate too much of its food. I was afraid of being\naccidentally trapped as its prisoner (of exceedingly fine dining, as I\ndid find out the one weekend I requested it). Across those weeks I saw\nXavier himself only quite rarely and mostly in passing as he was off\nto whatever kept him busy on weekends and I was sometimes directly\nrushing off to finish the next chapter.
\nMilburn's "Flight Into Night" itself was equal parts amazing and\ninfuriating.
\nThe book contained some amazingly imaginative descriptions of a dreamy\nwonderland "just beyond the clouds, up the stairs, through the crystal\ntunnel, then across the dusk ocean, but only when you are asleep"\nnamed "The Far Kingdom". The protagonist was a tween boy with a love\nof adventure and maybe just a bit of narcolepsy, and of course the\nadults in his life didn't believe such a wonderland existed, much less\nwere they interested in helping the poor protagonist in sorting out\nthe various and sundry political conspiracies threatening to blow up\nThe Far Kingdom and maybe even the "bland lands" "below" such as the\nprotagonist's home and all those adults that didn't trust him and\nconsidered him a sad little boy with a mental illness. At the end\nabout as you would expect the kid solves the political conundrum in a\nstrange but fun way, wins the interest of the Princess of The Far\nKingdom, and maybe manages to wink-nod earn some respect from the\nadults in his real life with a trinket he brings back as the Hero of\nthe Far Kingdom. Like some of its other near contemporaries such as\nPeter Pan or Wizard of Oz or Little Nemo in Slumberland it was\npretty tightly focused on the protagonist's view point and treated the\nadventures as very real and quite serious. Like Oz the world seems\nsetup to be a possible reusable franchise, way back before that was\nanywhere near a common thing, though the card catalogs in both the\npublic library and in the Forsberg Library seem to imply that any\nproposed sequel was never written. The obvious reason to assume no\nsequel exists is purely economic: the book sold only reasonably well\nregionally and the publisher went bankrupt soon after, but I was also\nstarting to see how some of the more problematic elements of the book\nmay have also prevented J. Y. Milburn from attempting any longer term\nplans with the material.
\nIt was in its problems that the book was incredibly frustrating. For\nall of its wonder and twee imaginative descriptions it also contained\ndeep wells of intentional and accidental racism. The politest\nsentiment you might often hear here is that the book was "extremely of\nits time", but the view of the book from this particular modern\nvantage point seemed to say that maybe it was even worse than its\ntime. The use of a flying carpet as the primary transport to, from,\nand around The Far Kingdom easily implied that Milburn had studied\nArabian Nights and possibly a wealth of other multi-cultural artifacts\nand just about every time you started to feel like perhaps the\nappropriation was unintentional Milburn introduces yet another racist\ncaricature or veers rather closely to outright islamophobia or\nsomething worse. Most uncharitably the book is a white savior myth of\na boy colonizing his dream space and winning the "exotic" princess as\na prize for his efforts. Both things are true at once: it's an\nimaginatively charming boy's adventure and it's a mess of bad\nstereotypes and outdated views and things that are very clearly awful\ntropes from a modern lens. Can you forgive the awful parts for the\ncharm of the good parts? Can you blame a book for perpetuating bad\nstereotypes and tropes when historically it may have predated or even\nbeen the cultural source of some of them? I didn't have good answers.\nI enjoyed reading the book for the most part, and I enjoyed reading it\nin relatively disconnected from the real world context of the Forsberg\nFamily Library (and its garden and hiking paths and guest sitting\nrooms).
\nWhen I finished the book I asked Mrs. Montgomery to please schedule\nsome time to chat about it with Mr. Forsberg. Xavier insisted on lunch\ntogether and I found myself unable to turn down an invitation for\nanother amazing meal from his chefs.
\nOver lunch we mostly discussed pleasantries. It was charming and\nlovely and the food was as spectacular as I figured it would be. Over\na slice of cake and coffee the conversation finally turned to Milburn\nand "Flight Into Night". Mr. Forsberg asked for my report and I found\nto my surprise I had a lot to say about it. Enough that the\nconversation flowed back out into the garden and into some afternoon\ntea. I enjoyed discussing all of the good parts of the book that\ncaptured my imagination. I got somewhat heated discussing the book's\nproblems and how upsetting some of it had been to read in this decade.\nI mentioned my gut instinct that Mr. Milburn was probably even worse\nthan average of his own time period and it wasn't entirely "it was a\nproduct of its time", the theory that some of its mean spiritedness\nand racism was so well read as to be intentional in its appropriation.
\nAs conversation had subsided and with it again the tea and the various\nfruits that had accompanied it today (despite how much we ate for\nlunch, the bits of fruit felt cleansing and powerful when accompanied\nwith a delightfully floral green tea), Xavier finally asked the\nquestion I had been dreading, "I'm glad that you enjoyed the book, and\nI've appreciated your perspective on its many problems. Given what you\nknow now of this book, would you still wish to recommend that I pay\nsomeone like Ms. Hayward to scan and OCR the book for consumption by\nthe internet as an ebook?"
\nI had been asking myself the same thing for days. I had been at war\nbetween the parts of me that were a big proponent of the public domain\nand keeping access to interesting cultural artifacts (especially in an\nage when so much of what should be the public domain was gated by\nleaseholders demanding rent and we could use all the public domain we\ncould get), and yet the parts of me that admired it as an interesting\ncultural artifact that is so terribly flawed it probably should never\nbe available in the context of the internet. "No, probably not. I mean\nit–" was about all I got out before my brain's own infighting\nstopped me short. After hours of talking about the book, talking about\nwhat to do with its future choked me up a bit.
\nI wasn't sure how much of that Xavier caught nor how much he felt\nhimself, but he stood, unfolding to forbidding height in the process\nas usual, and offered a change of topic, "I offered you a personal\ntour of some of the secrets my family's library in exchange for your\nbook report, would you like to join me?" He offered his hand to me,\nand I accepted it.
\n"My father considered himself a failed painter," Xavier started as he\nlead the way in a direction I felt pretty familiar with, "He went to\nart school against his father's wishes, was never commercially\nsuccessful, and eventually returned home. I'd submit that my father's\nview of success was myopic, but I'm biased, in part because our\nlibrary was my father's greatest painting. Like many of the greatest\nworks of art it was never completed in my father's lifetime, but like\nonly a few truly great works of art this was because it was designed\nto be a never ending, living installation."
\nWe started with a lap around the exterior of the building. Mr.\nForsberg was full of facts about little details and secrets his father\nhad hidden in the architecture, of which his father had first draft,\nbut it sounded like he'd contributed his own share of details. I have\nno real knowledge of architecture with which to appreciate most of\nsuch secrets, but Xavier kindly pointed out that some of the books in\nthe library could provide additional context if I wanted it. (Though\nI'd probably need to look them up via Ms. Hayword's digital secondary\nindexes.)
\nStepping into the vestibule, after a few fun facts about the brass\nlanterns and seeking out a custom LED manufacture for their unique\nsockets, Xavier pointed out what I had come to assume about the card\ncatalog, "My father of course knew about Mr. Dewey's system and he\nhated it. He thought that it removed the creativity of unusual\njuxtapositions, as you can maybe now guess. He grew up with my\ngrandfather's random shuffled library, with books in shelves spread\nhaphazardly throughout the house, and as much as he loved the\nunorganized mess he wanted to organize it somehow. He considered Mr.\nDewey's system boring and problematic for the ideas in books to only\nbe in conversations with each others in the same 'intellectual\ncategory'. Most importantly he thought it robbed books of their\ncontext: pigeon holing books into strict categories implies that\neverything about those categories can be exclusively found in those\nand only those books, that every book in a category is equally\nvaluable to current thought on that category, and that perhaps worst\nof all the impression of full shelves in a category can give the\nimpression that everything has already been learned and written down\nin that category. My father wasn't trained in the library sciences, he\nwas a failed painter, so he used the tools that he knew: colors. Then\nhe arranged them into numbers that made sense to himself and thought\nto arrange books by the most interesting color on their spines."
\nI nodded along at that, and even knew what to fill in of the next\ndetail thinking of the delightful dusk colors of the cover on\nMilburn's "Flight into Night" and the "R. Forsberg, Jr." signature on\nit, so I added, "And where books didn't have interesting colored\ncovers, he painted some beautiful ones himself."
\nXavier clapped in delight at my observation, "Indeed. Books were\nalways my father's greatest muse and organizing the family library\ngave him decades of reasons to paint beautiful covers for old books\nthat needed new or different contexts."
\nHe opened the door into the main hall of the library and ushered me in\nbefore continuing, "Of course, a lot of them needed new contexts,\nincluding Mr. Milburn's Flight Into Night. My grandfather and my\ngreat grandfather were quite the collectors in their respective times,\nand as you may suspect of nearly any family of multi-generational\nwealth in America such as mine we had more than our fair share of that\nmade on the backs of other people and some of that was intentionally\nmore than a little racist. My father didn't believe in hiding the\nskeletons in the closet, but bringing new contexts and bright shining\nlight to the horrors, as a reminder and a caution for future\ngenerations."
\nXavier ran a hand over a seeming random shelf and just about\nimmediately spotted an example, sliding it off the shelf. It had\nfascinating bright cover, but intentionally no words on the spine. The\ndust jacket cover was another "R. Forsberg, Jr." original, only this\ntime a gathering of ghosts with shocked and angry faces in horror. Mr.\nForsberg slipped the laminated dust jacket off just enough to reveal\nan old leather bound volume with a long disgustingly clinical title\ninvolving "trepanning" and that was more than enough than I needed to\nknow for why those ghosts were horrified, angry, and shocked. Xavier\nshivered in a shared horror of his own, replaced the dust jacket, and\nthen reshelved the book. He pointed to its neighbors, "Today such a\nhorror has as its primary chatting companions a field guide on birding\nand a novel about teenage self-esteem. Perhaps it will learn from such\nbetter neighbors. I've had Ms. Hayward project my father's\nidiosyncratic system to Mr. Dewey's and even modern color numbers such\nas HSL and CIELab, but the idiosyncratic system is what makes this\nlibrary the strange incomplete work of art that it is."
\nI felt like I was still reeling at the given "random" example, "Why\nwouldn't you burn a book that awful rather than shelve it?"
\nMr. Forsberg's eyebrow quirked up, "Weren't you the one trying to\nconvince me of the value of old books to the public domain as a term\nof accessing this library?"
\nI sharply inhaled as if hit. He was obviously right, and I suppose\nthat now I had a lot more context to work on, including the racism I\nhad directly combated in my reading of Milburn's "Flight Into Night".
\nXavier smiled and there was a kindness I didn't expect or know what to\ndo with in his muppet of a monster's face after such a surprising\ninsult, "Come, please. Allow me to show you my favorite secret in the\nlibrary." It dawned on me that this wasn't the first time that he had\nhad a conversation such as this, and that as embarrassed and pained as\nI felt from his response, I had a lot more reason to understand that\ncomplex wash of emotions when I had so casually discussed scanning\nbooks for posterity. This family's library was for a different sort of\nposterity, as it collected as much of the bad as the good.
\nHe lead me to the opposite wall in the hexagon from the vestibule\ndoor. He ran a hand along the shelves looking for a particular volume\nand it shouldn't have surprised me when pulling it off the shelf\nrevealed a hidden button behind it. Pressing the button made the sound\nof a great mechanical "kerchunk" of presumably a locking mechanism and\nthen just as smoothly as Xavier replaced the book on its shelf an\nentire section of shelf next to that book slid out on rollers as a\nhidden door. Behind the door was a simple flight of stairs running up\nfrom the main hall of the library. I spent so much time in the library\nand I would not have suspected a hidden door or that the hidden door\nmight have stairs leading up of all places. I eagerly followed Mr.\nForsberg up the steps to see where they lead.
\n"Oh wow," I stated overwhelmed and feeling like such words were not\nnear enough as I stepped out from the stairway into a gallery tucked\nunder the dome. Below the gallery you could see the entire color wheel\n(color hex) of the library laid out before you as a beautiful rainbow\nroom. I wasn't sure what sort of magic angles had been applied to the\nshelves below to deliver the "trump l'oiel" special effect below that\nmade it feel to me like I could see all the colors of the covers of\nthe books from no matter what angle I was looking down from as I\ngently wandered the circular gallery.
\nXavier chuckled at the way I was straining my head around trying to\nsee if I could catch the trick of it, and he gave me some time before\nfinally filling the space with the rest of the conversation as if it\nhadn't been interrupted by beauty below our feet, "This is the big\nreason I felt I must insist the books don't leave the family's\ngrounds, this final overhead context. Just as culture itself tries\npiece by piece to make the best things it can out of the best parts of\nthings that came from before it by recontextualizing them, this\nlibrary is one grand work of recontextualization. Mr. Milburn's book\ninspired a jazz quartet to create a lovely dream suite that in turn\nwas sampled by some of the hip hop classics. Mr. Milburn's book inspired a\nprogressive children's television show that tried to equally celebrate\nchildren's imaginations while also encouraging diversity as the way to\ndo it, rather than an obstacle in the way as Mr. Milburn seemed to\nbelieve. Mr. Milburn's work is better for how culture already moved on\nand readapted the good parts, leaving bad ones behind. So too, Mr.\nMilburn's work is better as one part of a prism's rainbow in a library\nwhere new contexts matter more than old ones.
\n"My father insisted on the big natural light dome and that the best\nprisms came from sunlight. The best way to fight darkness in our\nhearts, in our culture's past, in our family's wealth, was to shine\nnot just any light on it, but sunlight. My father knew full well that\nthe sun would over time paint its own brushstrokes of fade patterns\nacross the colors in the canvas below and that sort of collaboration\nwas something my father always trusted, and that too felt symbolic to\nmy father." I noticed the streaks of tears on Xavier's face, and felt\nmore than a little moved myself. There didn't feel like much to say in\nresponse while I digested that. I continued to take in the sight of\nthe library below me and we took our time before we left the gallery\nfor supper.
\n","date_published":"2023-11-16T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2023/09/05/pharkas-complete/","url":"https://blog.worldmaker.net/2023/09/05/pharkas-complete/","title":"One Last Feature for Pharkas Component Framework (for Angular)","content_html":"With version 6.0.0 I released one\nlast feature for the\nPharkas Component Framework and with version 7.0.0 I\nupdated it to the Angular's current LTS (15). Pharkas is a mature,\nbattle-tested library for writing user-responsive UI components\nusing RxJS best practices in Angular. These two updates are likely\nmy bow around my involvement in the project.
\nPharkas came from my frustrations with Angular, especially\nwith how many core components of Angular may unintentionally lead to\nbreaking RxJS best practices. At that point I had a nascent idea of\na framework for better RxJS practices in Angular, which I briefly\nnicknamed "Project Gawky".
\nA few months later while debugging and fighting a Halloween sort of\nghost story in Angular caused by Angular's default change\ndetection system and its (over-)reliance on Zone.js, I felt pushed to\nreevaluate the "Project Gawky" ideas in a concrete base library that\ncould be used in brownfield applications as a way to make it much\neasier to adopt Angular's more civilized OnPush change detection.\n(At least from a "bottom up" direction, as default components can\nuse OnPush ones easily but vice versa isn't as possible or useful\nin Angular.)
Pharkas defines something of a DSL for component building in Angular\nthat is entirely dependent on RxJS Observables, entirely focused on\nworking solely with them to drive a component's behaviors (including\nlife cycle), and built to make it easy to follow RxJS best practices.\nThese include helping developers to avoid over-relying on Subjects,\nand minimizing calls to Observable subscribe, and especially\nattempting to eliminate calls to subscribe without a corresponding\nunsubscribe cleanup at the right component life cycle point. The\nbenefits to following these best practices (as opposed to many\n"best practices" Angular developers often are exposed to in the wild)\nshould always be a reduction of memory leaks.
Pharkas takes this further by automating the somewhat manual OnPush\nchange detection in Angular. Change detection is handled entirely\nbased on Observable wiring. Pharkas is designed to lead the component\ndeveloper into user-responsive components by default.
Pharkas' "DSL-like" patterns have been occused of being a bit\nverbose (an unfortunate side effect of Angular's use of non-standard\ndecorators), but in practice I've often found component code to be\nsmaller and easier to read when written with Pharkas. Once you\nfactor in the easy wins from Pharkas' smarter out of the box change\ndetection behaviors, full mostly automatic component life cycle\nmanagement, and other subtle performance benefits, I think the\n"verbosity" easily seems to disappear and Pharkas for became the\nonly good way to write Angular components.
\nI think Pharkas makes the best way to write components when\nperformance matters. I think Pharkas also excels at writing thinner\nwrappers around Vanilla JS components avoiding unnecessary Zone.js\noverhead taxes across the component boundaries. (Vanilla JS\ncomponents that handle all their own DOM don't need Zone wrappers\nand with Pharkas wrappers will never signal extra busy work to\nAngular's change detector.)
\nIn reviewing the "Project Gawky" I think the final Pharkas\nproduct managed to in general meet most of the expectation (outside\nof being directly a template language dialect rather than a DSL\ninside component constructors). These ideas came largely from having\nwatched a lot of what React had been doing, very slowly, across\nmultiple major releases. I felt like a lot of those same benefits\ncould come from an RxJS-first approach, as much of it looked like\nbuilt-in schedulers and common operator patterns.
\nFrom the beginning Pharkas has made easy in Angular to do a lot of\nthe complex timing management that React calls "Concurrency":\nany Observables bound to a template with Pharkas\nthis.bind(name, observable, default) will notify Angular's\nchange detector no faster than requestAnimationFrame time. This\nkeeps components highly user-responsive, as the browser will\nthrottle requestAnimationFrame time as necessary to focus on\nuser interactions and keep the UI responsive. (A browser may also\nreduce requestAnimationFrame time when a tab is hidden or\nbackgrounded, further improving battery efficiency.)
(Of course, user-responsive also means that sometimes you need\nchanges propagated as soon as possible, and Pharkas also has\nfrom nearly the beginning provided\nthis.bindImmediate(name, observable, default) to force immediate\nchange detection on observations. In React this sort of thing is\nneeded especially for form elements when the "source of truth" is\nthe virtual DOM; form updates need real time to avoid upsetting\nusers. In Angular, Reactive Forms treat the real DOM as source of\ntruth and I've found the need for immediate bindings in Pharkas\nextremely rare.)
As I had surmised, this is easily accomplished by a relatively\nsimple RxJS operator and scheduler combo (it is about entirely\njust debounce(0, requestAnimationFrameScheduler)) when you, like\nPharkas, are assuming entirely Observables (and nothing but\nObservables), and are using Angular's OnPush change detection\nstrategy.
The other side of the React example over multiple major versions\nwas what React calls "Suspense". I had mentioned that among the\n"Project Gawky" ideas, but hadn't implemented until now. In Version\n6.0.0 Pharkas learned a very basic version of "Suspense": a component\nmay this.bindSuspense(suspenseObservable) to determine when to\nraise a flag that the component is suspended. While suspended,\nPharkas will suspend all further change notifications to the Angular\nchange detector until the flag is lowered.
One motivation for a suspense observable is loading situations where\nyou want to display a simple loading UI and fewer of the intermediate\ntemplate states while it is loading. Another possible motivation\nwould be situations where you may expect a lot of expensive\ncalculations and want to avoid browser DOM work while it happens.
\nIt's another (final) tool in the user-responsive toolbox. Immediate\nbindings still trigger change detection, and Angular will do\n(opaquely) choose to do change detection on its own every so often.\nIt won't entirely eliminate "intermediate" states in your UI, but it\nwill certainly provide a knob to tune refresh rates in periods of\napplication time where there are other priorities than DOM updates\nof your component.
\nIt's not quite apples-to-apples with the full power and complexity\nof React's Suspense, but it's an interesting, basic relative that\ncan deliver similar experiences in similar use cases.
\nIt's also nearly as "simple" from an RxJS standpoint under the\nAngular OnPush regimen in Pharkas: effectively just an extra\ncombineLatest and filter added into the change notification\npipeline. (It's also "pay to play" and if no suspense observable is\nbound, these additional pipeline steps aren't added.)
It's not very discoverable, but you can see it in action in the\nPharkas demo. If you click the test component with a counter\nthe demo will now toggle suspense for that component. You may use the\nembedded RxJS-spy in your Dev Tools console to verify that the\ntimer observable updating the counter continues to fire on its usual\nschedule and that the demo isn't cheating in this "loading" suspended\nstate.
\nPharkas is mature, stable, and now feature complete with respect to\nmy original vision for it. It is up to date with respect to current\nAngular LTS (15).\nPharkas is MIT licensed open source on GitHub.
\nI suspect this Suspense feature will be the last feature for Pharkas,\nfor several reasons: Because it feels feature complete and because\nI have no current expectations to continue working with Angular.
\nFeature-wise, I think the one thing left that bugs me a small bit\nstill is that I would love to make the DSL prettier with even more\nmeta-programming should Angular ever finally stop using non-standard\ndecorators so much. Maintenance expectations for any Angular library\nare of course constant updates to keep up with LTS. That will never\nlikely be "complete" given the way Angular compatibility tends to\nwork and the complicated nature of Angular's peer dependencies in\nnpm. I expect maintenance to be needed, but I don't expect to do it\nat this point.
\nIn large part this is mostly because I was recently let go from my\njob of the past 8 years and am looking for new opportunities and\nchallenges. I don't have any Angular apps to maintain now and I\ndon't know if I can entirely avoid Angular in whatever my next\nopportunity is, but I know I'm not going to be especially looking\nto continue working with it. (It almost drove me crazy.) Without\nsomeone paying me to maintain Angular apps, my interest in keeping\nup with the Angular maintenance treadmill falls off a cliff.
\nI think Pharkas is mature and stable. I believe in open source, and\nwill entertain suggestions for new maintainers of the project. In the\nmeantime, I will try my best to welcome pull requests and run\nmaintenance tasks if politely asked.
\n","date_published":"2023-09-05T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2023/04/29/picard/","url":"https://blog.worldmaker.net/2023/04/29/picard/","title":"Playing with the Bones of Star Trek: Picard","content_html":"The other day on Mastodon I got to thinking and talking again about how some of the\nideas of Star Trek: Picard's first season really with resonated me, but that it was\nmostly a problem of execution of them to me, and that was part of why I watched the\nfull of its second season despite disliking so much of it. (I haven't finished watching\nthe third season, and am not sure if I will, but I did read all the spoilers for it.)
\nI'm going to lead with this: The key motivation for me was how important I think the\nBorg Coöperative are to Star Trek and why I loved the idea of late in life (ex-)\nAdmiral Picard being the only diplomat who could "properly" welcome them to the\nFederation. A bunch of the seeds were laid in Season 1 for the Coöperative, and then\nSeason 2 entirely ignored them to do its own weird thing, in the process messing up some\nkey parts of the Coöperative (not just in a "that's not my canon" nitpicky way but\nmissing some of the underlying raison d'etre and character motivations, including\nunthethering it from the "Prime" timeline altogether in a "we don't even trust it to be\ncanon" sort of way).
\nIt feels important to lead with motivation like that, because that's going to be a\nrunning theme in what follows.
\n(Also, I'm using the rare-to-English diaresis for the word "coöperative" in this\narticle mostly because it is fun and I can pretend to be high society like The New Yorker,\nbut also partly because it is fun how it can be confused to be Swedish enough to be a\n"Borg umlaut".)
\nA quick informational aside: Star Trek canon is primarily broken down into three main\nwiki databases. Memory Alpha tracks TV and movies, Memory Beta tracks video games and\nnovels, and Memory Gamma tracks everything else from comics to toys to all sorts of\nweird tie-ins with a vague notion of continuity. So terms like "Alpha canon" are a useful\nshorthand for "Star Trek stuff that happened on the TV screen or a movie screen".
\nIn Alpha canon prior to Star Trek: Picard there is one single, mostly standalone\nStar Trek: Voyager episode teasing the idea of the Borg Coöperative. The basic concept\nis that which is implied by the name: a group of Borg, disconnected from the Collective\n(we all know and "love"), decide to try to build their own culture with something more\nin lines with Federation ideals and as a "worker-led coöperative" where they could elect\ntheir own leaders and strive for a better Borg society.
\nIn the classic fashion of Voyager, the idea is never revisited, there's no ongoing plot\nthreads from that episode, there's no idea what happened to those people and that\n"movement", it was just one mostly self-contained episode among many.
\nSo, of course, being a good idea with interesting repercussions, Beta canon had a blast\nwith it for a couple of decades. I mostly am aware of how Star Trek Online portrays\nthe Coöperative, but I read several of the key novels as well, for various reasons. The\nbasic throughline I think is pretty obvious: in the Delta Quadrant power vacuum left by\nthe death of the Borg Queen and infectious destruction of a lot of key Borg communication\nchannels, the nascent Coöperative of that lone Voyager is given a massive petri dish of\nformer Borg Collective toys with which to grow and peacefully expand their culture. Over\ntime, depending on source/take, even notable figures such as Hugh and Seven of Nine serve in\nvarious elected positions in the Coöperative (Presidents and Councilors and such),\nfurther enriching the knowledge transfer of Federation ideals, until eventually the\nFederation recognizes the Coöperative as proper allies (including in the fight against\nstill deadly remnants of the Collective) and then eventually members.
\nThe Coöperative is such a fun idea to Beta canon because the irony is never lost on most\nof the Beta writers that the Collective is frightening for how quickly they assimilate\nother species, but the Collective is not the greatest assimilation force known to the\nStar Trek galaxy: the Federation is much slower at assimilation, but the history of\nStar Trek suggests it is more deeply the winner. The Borg Collective gets a couple of\ninteresting battles deep into the heart of the Alpha Quadrant but mostly fails to get\na lasting beachhead, stymied time and again (and back in time) by the Federation.
\nThe Federation frees what seems like only a few dozen Borg total, infects them with\nFederation ideals and virtues, sends most of them along on their merry way with\nseemingly zero after-care or oversight, and most of that was done by a single\nship lost in the Delta Quadrant, the Borg Collective's home turf, that was barely\na threat (though did get time paradox lucky to eventually kill the Queen, but it\nwas either that or more years in hell, so Captain Janeway felt free to violate\nseveral sections of the Temporal Prime Directive for that outcome in the Prime\ntimeline). It wasn't an attack force. It wasn't a planned strike. It was one silly\nship talking to people.
\nIf you've been following along in Alpha canon, that irony of the Borg Coöperative\nbeing an accident of infection of Federation ideals shouldn't be a surprise. The\nAlpha canon is full of Federation "exceptionalism" like that. Time and again, the\nmany shows suggested that the Federation was more enlightened than everyone else and\nconcepts like democracy and Infinite Diversity in Infinite Combinations would always\nwin in the face of just about anything. There's something delicious about that\nwinning even against the Borg Collective's culture, even if some of it was an\naccident and all of it was a very slow form of assimilation.
\nBeta canon followed that to some of its logical extremes: that picture of Borg\nCoöperative members serving in Starfleet as another "species" adding diversity of\nthought and culture to the Federation.
\nI personally love that. That's my Star Trek.
\nI'm going to get back to the fun shortly enough, but I feel in the interest of\ncontext I briefly need to mention some of the biggest shortcomings I saw in\nStar Trek: Picard.
\nI think it is clear at this point that Star Trek: Picard put the Borg Coöperative\nonto the tee, went to swing at it, and entirely whiffed it.
\nIt's implied but never actually text in any season of Star Trek: Picard that\nthe Borg faction that bookends Season 2 is even the Borg Coöperative. It seemed\nobvious to me, with my exposure of Beta canon, but it has been the source of a lot\nof Season 3 confusion.
\nThe other thing that bugs me the most about how Season 2 presented their origin of\nan Almost-Coöperative is that it misses some of those key bits of Federation ideals\nthat make not just the Beta canon Coöperative but also the brief, nascent\nCoöperative that Voyager briefly interacted with in a single episode. The\nAlmost-Coöperative is presented as having a traditionally symbolized Queen and\nwhile they request to join the Federation don't seem to have internalized\nquite so much of Federation ideals.
\nThough admittedly a lot of that is still implication and supposition because\nthere is not enough text there in Season 2. Maybe Agnes there is just an\nelected Ambassador chosen based on a bunch of information, and not actually a\nQueen. We have basically no idea because they showed us the "twist" that it\nwas Agnes then didn't really have time to tell us anything about that. Twist\ndone, the show decided the only thing it really had left to do that season was\nroll the credits credits.
\nThat leads into what I think were the largest problems of Star Trek: Picard:\n"No tell, only show" and "twists/late infodumps over exposition and character\nmotivation". Neither of these problems originate with nor are unique to\nStar Trek: Picard. One is just kind of an accidental product of post-Lost\nmedia. Everyone knows "People love twists!" Everyone forgets that we used\nto generally know character motivations as an audience and have some semblance\nof reasons to watch a given scene rather than assume it might be relevant\nlater, maybe, if the "twist" is right and it wasn't a red herring.
\nThe "No tell, only show" seems like the obvious pendulum extreme affecting\nalmost all of current "prestige television" and precisely what you'd get\nfrom a generation and a half of writers drilled on "Show, don't tell".\n"Show, don't tell" comes from a good intention. It's meant to spark\ncreativity. But it's a pendulum and both extremes are painful. Too much "tell"\nand not enough show and the audience is bored because they are getting\ndidactically lectured at with nothing interesting to see. Less appreciated is the\nother extreme: too much "show" and not enough "tell" is a recipe for boredom\nin its own way. Things that might have taken a two minute conversation take\n20 minutes of scenes across two or three episodes. Without knowing their\ngreater context in the scheme of things those scenes can feel like complete\nwastes of time for maybe a brief "oh that's what that was about". (Which\nis easily confused for "twists" and exacerbates and feeds the other problem.)
\nTo me Star Trek: Picard is one of the most emblematic shows in all of\ntelevision for "No tell, only show" especially because we have the context\nof Star Trek: The Next Generation (and TOS, Voyager, Enterprise): so many\nTNG episodes are an amazing balance of tell and show. So much of Star Trek\nstorytelling is dropping the right "Captain's Log" at a good moment to quickly\npush the audience on to the next thing they need to know.
\nThe combination of these problems leads me to this feeling like most of the\nstory of Star Trek: Picard was told "backwards and upside down".
\nI have this impression that you could especially take the first season, "simply"\nreorder it, and tell the same story better. That if you focused on getting\nmore motivations up front, rather than saving things for "twists" that don't\nquite impact because you had no idea of character motivations. Especially, if\nwe assume that one of the end goals, because of the second season bookends,\nwas to set up seeds for the Borg Coöperative.
\nI have this gut feeling that most of what follows could possibly be done in an\nedit bay with a talented Editor using just the existing show as it was and\nmaybe a choice "Former Admiral's Log" voice over here or there.
\nHere's what I imagined this could play out (the other day, mostly\nextemporaneously on Mastodon; I'm sticking to mostly light edits, plus\nnew asides):
\nDropping in a quick aside here, to break the bullet point rhythm, it's still\nan incredible shame that given the events of Star Trek: Nemesis that not\na single named Reman existed in Star Trek: Picard. Since I'm busy armchair\nquarterbacking my way through a rewrite of the show anyway, I'd have shown\nthe Qowat Milat to be primarily Reman and a Reman Unificationist group.\n"The Way of Absolute Candor" versus the culture of secrecy and lies of Romulus\nprior to the Hobus explosion seems almost obviously an outside force and\ncertainly in my headcanon easily sounds like a Reman concept. (Sure, it is\nimplied to mean more like a Romulan counter-movement/"Buddhist reformation"\nof Surak's teachings on Vulcan, and "absolute candor" in emotions primarily,\nbut you don't just drop that title in the middle of the Tal Shiar-obsessed\nRomulans and expect it to not also imply fewer secrets and lies.) Probably\nElnor should have been a Reman. That's about all I plan to say about Elnor.
\nBack to the story reorder in progress:
\nIn that order, even as just bullet points, I feel like that’s a pretty good plot.\nCertainly better than what Season 1 of Star Trek: Picard seemed to show us,\nright?
\nI think that leaves clear villains the whole way through with clear motivations.\nI think that it leaves lots of building blocks for wilder things to come "next\nseason". Again, I don't think I actually deviated from the story actually in\nthe show (near as we can figure in some places where things are far too much\nsubtext rather than text because the show generally abhors "text").
\nI think that there's only a couple things that I would have loved to see or at\nleast have told in that season, rather than leave things to supposition.
\nI like to highlight the Federation ideals here. Don't murder the villains, let\nthem face justice and account for their actions.
\nWe don't know anything about this species other than a brief glimpse through what\nmight have been a portal. There's no text here, just wild special effects.
\nBeta canon suggests it could be any number of things with a common fan favorite\nbeing the TNG-introduced Iconians of the Iconian Empire using a classic Iconian\nGateway, which yes all do predate Mass Effect by some time.
\nDespite mocking this element of the show as just ripped from Mass Effect, I\nappreciated. I like my Mass Effect most when it is a lot like Star Trek, and\nI did like a lot of things about when Season 1 felt the most like "Picard Effect".
\nI love the idea that at all times in Starfleet history there are barely known\nexistential threats that are just out there, encountered once, if at all, and\n"never followed up on". Part of the fun of something like the Beta canon is\nall the fan hype about "This time it is the Iconians for sure!" but Alpha canon\nhas never mentioned them again outside of a throwaway gag in Voyager and a\nthrowaway mention in Discovery (centuries after TNG).
\nIt's great to have these bits of unexplained whatever. "Give us more tell" also\ndoesn't mean "tell us everything", it's still a pendulum. Briefly show and\nleave unexplained works well when intentional.
\nStar Trek: Picard seems to get so close to doing this. I like the idea of\na completed redemption arc for the Soong family over way too many generations.\nThe Soongs are exiled from the Federation for getting too deep into\nFederation-outlawed genetics experiments, while in exile realize that genetics\nexperiments are tough without a big enough population to experiment upon, and\npivoted to never technically outlawed by the Federation research into robotics\nand sentient machines. (Obviously the Federation invested quite a bit into\nthese things still. The Exocomps as the easiest next thing to point to. It\nwas certainly not outlawed in the Federation to science these things.) It is\nplausible that being in exile gave them a somewhat leg up and some of their\nexperiments even in that time might not have met Federation ethics standards.\nBut TNG and then Star Trek: Picard make it clear that once the research was\ncomplete, the Federation had much fewer qualms about taking advantage of the\nfinal products. (After all, what is the measure of a man?) (At least until\nthat Romulan spy sabotage thing, whoops.)
\nThe right thing to do would be to welcome the Soongs back into the Federation\nafter their androids (and "synthetics" derived from same) had done so much for\nthe Federation for so many years. It's cool and all to see "yet another" sad\ngoodbye to Data himself, but welcoming the Soongs back into the Federation I\nthink would be a much more interesting, weird, but satisfying ending that the\nshow could have uniquely given us. It's a finale to a TNG arc (that ENT\nexpanded) a lot of people wouldn't see coming but I think would grant a strange\namount more of closure to Data as a character than any "chess ending" or "poker\nhand".
\nI think the bones are there for something really interesting in S1 setting up\na teed shot for the Borg Coöperative. S2 mostly seemed not to know how to use them.
\nI think some of these were good bones in S2:
\nThe Borg Coöperative should not have a Queen. It should be more of a democracy.\nThat idea that the Collective's culture is so strong that it really wants a\nQueen, and that in that position Seven of Nine realizes she's incredibly\ntempted and has such a hard time resisting. (It is futile, as they say.) Using\nan alternate timeline or the mirror universe to push that message on paper is\na good way to build up that kind of resistance, to help build the sort of\nperson that could take Collective technology and democratize it. The sort of\nperson that could be the first, term-limited "President" of a Coöperative.\nThe kind of person that could stand up and say "No more Queens!" and mean it.
\n(Agnes doesn't really make sense at all in S2.)
\nThere is a fun symmetry to be had in using Star Trek: First Contact style\nshenanigans to help strengthen the Coöperative (versus reduce the Collective).\n(But do it on purpose, with motivation! You don't spend nine-tenths of First\nContact's runtime wondering if the Borg are friend or foe and accidentally\nhelping them instead of fighting them.)
\nOn paper, the idea of Jean-Luc Picard being invited to be the ambassador to\nthe Borg Coöperative for the Federation also has some delightful symmetry.\nPTSD included. So far as I recall that's not even an idea that I think\nmuch of Beta canon considered, but it's an interesting one (that S2\nsquandered).
\nThere too, motivation would add good drama. PTSD gives Picard a lot of\nreasons not to trust the Coöperative, and have a tough time imagining\npeople that might volunteer for the sort of thing thrust upon him as\nLocutus. But if the audience has a good idea that the Coöperative is\nwho they say they are, up front, that's good dramatic tension, not just\n"he's probably right, no one should trust the Borg" which S2 suggests\nright until the last minute "twist". It places Picard in the role not\nas the Ambassador friendly to both sides from the start, but the\nAmbassador doing due diligence to grow a proper trust (and maybe never\nquite getting there but still trying to at least do the right thing\nfor the Federation).
\nBut beyond the good bones above, I still wish that the reclamation Cube\nhad been more involved somehow in the S2 Coöperative. It was setup so\ninterestingly for that. I wish Seven of Nine was more properly involved\nin electing leadership. That also seemed interestingly setup but then\nnot paid out. I wish the Coöperative was less reliant on alternate\ntimeline resources and some sort of continuity drawn back to the Voyager\nepisode. Not because I'm a stickler to any of the Beta canon origin\nstories, but because a "worker's coöperative" should come from the same\nplace it is in rebellion against and there is such juicy fun in the\nidea that Voyager, of all ships, with no other help, accidentally seeded\nan entire faction of "good Borg" in the home turf of the Borg while just\ntrying to get home.
\nIt's been a long road, getting from there to here. I've continuously\nexplaining to people why I think S1 had some good ideas despite poor\nexecution and that S2 was worse because the Borg Coöperative is a\ngreat idea and it was so poorly executed most people have no idea\nat all, whatsoever, what "Agnes' Borg" were even supposed to be.\n(And they still might not even be the Coöperative. That's still\nmore subtext and showrunner tweets after the fact than anything\nsubstantive, especially since they were too busy to lend a hand\nat all in Season 3.)
\n","date_published":"2023-04-29T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2023/01/08/bluey/","url":"https://blog.worldmaker.net/2023/01/08/bluey/","title":"On Bluey, new PvP in Sea of Thieves, and Why It is Sometimes Fine to Suck at Warcraft","content_html":"In November and December I had a maelstrom of different things smash together that all sort of reminded me\nof strange parts of my education, all the while I was fighting some illness that was mildly Flu-like. First\nchronologically, while I was in the middle of trying to win NaNoWriMo, Sea of Thieves released their newest\nPvP mode for which I have a lot of criticism to discuss. Then I was hit by that Flu-like thing just after\nThanksgiving and used that as excuse to binge watch all of Bluey that Disney+ had available. Whatever that\nwas had responded to anti-histamines so I'm mostly sure it was a perfect storm of different seasonal\nallergies hitting me all at once and a couple of them in ways I haven't felt in years, so I don't think it\nwas contagious but I was also trying for caution. Between the fevers, the migraines, and the binge watch I\ncame out of watching Bluey feeling somewhat like I was going to write a PhD dissertation on it or, deep\nenough in the fever, like I already had written a PhD dissertation on it. (Unfortunately, I don't know any\ncollege that awards Doctorates for virtual PhDs written about children's TV shows while running a fever, but\nI still kind of feel like I earned one and someone should award that to me.) Then deep in the middle of Bluey\nPhD brain I was nerdsniped by a Folding Ideas video that seemed almost pointedly wrong given the PhD\ndissertation I "had written".
\nIt was a wild few weeks, and a lot of this I got into in somewhat real time on Mastodon and a few Discord\nchannels, but seemed something interesting to coalesce into something of a better narrative form to blog about.\nBeyond the through line of all of it happening in short succession chronologically, I think there's a lot\ninteresting cross-threads and maybe a useful overall narrative to all these various sorts of games criticism.
\nTo give some context to everything, allow me to briefly recap my academic background a tiny bit. In undergrad\nduring my cooperative education internship with Microsoft I attended my first Penny Arcade Expo ("down the street"\nthat year from where I was living in Redmond/Bellevue). While attending PAX I was reminded that in High School\nI'd thought I would like to make videogames, that coalesced with some of the games criticism I'd been blogging\nat the time, and I caught something of an entrepreneurial bug there. That lead me to discovering a card game\nthat I loved, with great artwork, and from there working to license it to build a Xbox-playable version. I\ndecided that was going to be a big grad school project for me. My program was a targeted Master's Program and\nI had gone in with the assumption of finishing grad school (despite it being a degree that doesn't quite matter\nso much in the software industry as whole, it mattered to me at the time).
\nI treated the entrepreneurship as its own grad school challenge, including academically. I used the small\nbusiness as an excuse to pick up a lot of game design textbooks, especially those covering MMO design for several\nreasons. The card game I was working on wasn't an MMO, of course, but was multiplayer. I had some ghost of an\nidea that given Adventure games were still mostly dormant outside of a few small developers that MMOs were an\nevergreen genre that if I could bootstrap into them could be very interesting. Here I had games like\nPuzzle Pirates as a particular influence at that time on ideas you could accomplish in a "low fi, bootstrapped"\nMMO. I've still never actually tried to bootstrap a low fi MMO, but I've still got lots of notes on various ideas\nfrom different years.
\nSo in all that I think I had a rather deep education of the state of MMO research and the "classic" textbooks of\nvideogame and game design in some brief moment in roughly 2007-2009. I capstoned that grad school work with a\nbrief chance to be a panel member on what I felt at the time to be a great PAX session in 2009. I failed to\npredict the sort of economy that would greet me after I completed grad school in 2008, and the card game I was\nworking on at the time was literally stomped on by Godzilla (which is funny now with distance, but of course was\nnot at the time when my expected livelihood sort of depended on it).
\nThat weird academic background I'm very proud of, but I've never made professional use of it. Perhaps it says\nsomething that my fever dreams thought I should apply it back to academics and go for an Imaginary Doctorate\nI wouldn't know how to use professionally either. I still don't know exactly where that came from.
\nGames are incredibly important to the (Australian originated) children's television show Bluey, almost every\nepisode is about games and even the intro to every episode is itself its own mini-game. I don't believe this is\na coincidence and I think this is underscored by the fact that the production company for the show decided to\ncall themselves Ludo Studio, with ludo being one of the Latin names for games/play, and the preferred one for\nthings like discussions of games theory (ludology) [1], and underpinning concepts such as ludonarrative\ndissonance (the difference, especially when troubling, between what the narrative, the story/theme, of a game\nis trying to say and what it's game mechanics are built to impart).
\nAlmost everything in Bluey is a game, including the intro, as I mentioned, follows rules, explores rules, and\ndeals with concepts like fairness in play, and fairness in rule design, and even complex things like\nludonarrative dissonance. It explores all those things, plus family and friendship and growing up and so much more,\nall in very tight 9 minute episodes. It's equal parts delightful (for instance, every time someone wins a game,\n"Hooray!"), and emotional (some things get sad for the talking dog families of Bluey's world). I don't expect\nanyone needs a recommendation from a childless adult who binge watched the show in massive single sittings as\ncomfort food during fever-like illnesses, but I loved it and strongly recommend it, and I would like to think\nthat it it is the kind of show that can both hold young kids' attention, and maybe teach them something.
\nIt deals with some of the problems of game design, and offers hints of ways to solve them. It tries to instill\nideas of fairness, of course, as many good children's shows do, but it also gets into some of the deeper things\nbeyond simple ideas of fairness in game play to why you need rules in the first place and what their goals are,\nhow to have fun playing with people that have different ideas of fun or games than you, and how to troubleshoot\ncases where people stop having fun. Overall these are great life lessons that apply equally to games and things\nthat aren't games. It is said that some of the games children play are deeply to "rehearse" real life. The\ndifference between real life and game play aren't binary, they are things that bleed over and between each other.\nThat's a strong theme of Bluey throughout and some of the most fun episodes leave you wondering how much\n"magic" was real life. You get the sense over three seasons that Bandit, especially, Bluey's dad, will do\nanything for a game and is possibly the best, most spirited games player so long as his kids are having fun,\nbut sometimes Bandit leaves you with questions of how much he's playing and how much is real (and that's part\nof the fun of the show). That's the power of a good game player sometimes. On the other side, many of the games\nthroughout the seasons have deep real world repercussions and many things are "for real life" (including, among\nother things, the friends you make along the way and the family you keep).
\nWhile watching, I continuously had that weird feeling that so many episodes of Bluey showcased complex things\nfrom my weird grad school education but in relatable, easy to understand ways. That was at least part of where\nthe idea came from that I could spend hours lecturing on individual 9 minute episodes and how they relate to a\ntextbook's worth of ideas on how you design games, on how you run them, on how you should act as a good player\nof games. Somewhere along the way "lecturing on it" turned into "writing a blog post" (such as this on it) and\nthen became it's own little Imaginary PhD dissertation that I dreamed I maybe actually wrote. There would be a\nlot worse things in life than to hold a Doctorate in Ludology As Explored by the Children's Television Show\nBluey. I think fever dream me earned it, and I probably don't have enough moonlighting time to try to do it\nin real life, but if there's a college interested in handing out that diploma, I suppose they could email me.\n(And as Bluey reminds us continually sometimes the things you earn in a game still count for real life. I'll\ntreasure the one I scrawled in metaphorical crayon for myself.)
\nIn November's Season 8, Sea of Thieves brought On-Demand PvP back as a game playing option. On paper, I think\nit is a great replacement for the lost Arena mode (and many people just call it "New Arena", which I will have\ndifficulty myself not just referring to it as that), I like that it uses Adventure servers in interesting ways,\nand that there is room for it to better exist side-by-side in the same spaces as "the rest of the game" in a\nbetter way than the "separate but not quite equal" menu mode that Arena was. Yet in practice, I'm highly critical\nof it, how it is balanced, and especially how it is rewarded. It's very easy for this criticism to sound deeply\ncritical in the negative connotation sense that I don't like it and/or maybe even just hate it, so I suppose\nthat's why my brain spent a lot of time metaphorically blowing the cobwebs out of some old parts of my grad\nschool education and looking to find ways to constructively criticize it (in the proper denotation of criticism\nas not specifically negative).
\nMy harshest take has been that the new system is "Emissary 2: Emissary for Masochists". The new system introduced\ntwo new Emissary factions that were clones of previous trading company/emissary factions but "PvP Only now". It\ntook some existing concepts such as the Emissary flags and their relationships with factions and built new\nslightly different versions but "PvP Mostly now". There's some good reasons to do that, of course, in that it in\ntheory started everyone off on an equal playing field and they felt that PvP was undervalued so having "PvP Only"\ncontent was a boost that they felt the game needed after lots of PvE fine tuning over the last few years (and the\nshutdown of the Old Arena).
\nA useful lens for this to me remains the Bartle types. These were types of players as self-described on early MMOs\nand then compiled and studied by Richard Bartle among others. The Bartle types are sometimes considered an outdated\nor flawed methodology for several reasons: they were self-described, which can add some bias to the results, and\nthey are sociological profiles that are quite (intentionally) broad. At its worst usage, the Bartle types are "MBTI\nor horoscopes for MMO players". At its best, however, there's still some usefulness in the way that Bartle types\ncan describe a "four quadrant" game that hits many key interests of multiplayer game players. Despite being\nself-described, early studies of MMO players showed an equal split among players of which of the four types they\npersonally felt most dominant, and that's still a useful rule of thumb property for first order approximations.
\nI think my greatest criticism (as compared to my harshest take) about the new PvP system is not just that it is a\n"one quadrant only" solution, but that it feels a lot like a "less than one quadrant" system as it is currently\nbalanced and based on that self-described demographics "rule of thumb" it's the kind of thing that applies to\nlikely less than twenty five percent of possible players. We already know that was a problem with the Old Arena\nand why it shut down, in that it was used by fewer than 25% of the player base. The new system doesn't seem to\nrepeat some of the same mistakes that made maintaining the Old Arena expensive by sharing entire instances with\nAdventure and not needing different or dedicated servers just to run it, plus it isn't supposed to diverge from\nthe rule set in play in Adventure in any significant way and is designed to interact with existing Adventure\nrules rather than replace them. It maybe isn't the harshest possible take on the new system that in the long\nrun it may again be less than 25% of players using the system because it maybe is better designed to survive\nthat. I still find it is a useful to lens to discuss and criticize the system in this manner though, as\nparticularly my own interest in the system comes from a perspective primarily based in the other "three quadrants".
\nFor brief recap: the Bartle types are generally referred to as Achievers, Explorers, Socializers, and Killers. A\nrelevant subset of Killers that isn't often considered a Bartle type of its own but has made its way into a lot of\nMMO discussions in general, the vernacular at large, and should rarely be ignored is Griefer. Bartle described the\ntwo axes connecting these four quadrants as Players versus World and Acting versus Interacting. In brief rough\noverview: Achievers primarily seek to act on the world (scoring points, winning things), Explorers primarily seek\nto interact with the world (finding hidden spots, solving puzzles), Socializers look primarily to interact with\nother players (hanging out, winning together), and Killers seek to act upon other players (killing them, of course,\nbut more generally just in getting some emotion back out of them). Griefers are a subset of Killers whose primary fun\nis getting specifically the maximum amount of negative emotions out of other players. (Bluey has great episodes\non nearly every Bartle type except Killers and/or Griefers. If the show needs suggestions on smart topics to bring up\nwith complex needs and real world repercussions, I offer the suggestion that there is rich ground there to cover,\nthough I also expect writing much on the subject for a children's show seems to me to be rather tough.)
\nIt's very clear that any PvP system is first and foremost primarily focused on the Killers quadrant. That should be\nobvious from the Bartle type name. I think an issue with the new system, because it is entirely opt in (for good\nreasons, of course, I'm not complaining that it is opt in) it winds up being able to capture the attention of only\na subset of Killers, for some of the same reasons that the Old Arena did. There was a lot of hope that I saw in the\nforums and Discords that the new PvP system would also pull a lot of the Griefers out of "raw" Adventure and push\nthem into PvP cycles instead. That personal goal of maximizing other player's misery for the Griefers generally\nmeans that they won't opt in for long (or much at all), because random ships doing normal random stuff in Adventure\nwithout marking themselves as "interested in PvP" is always going to be the more "lucrative" target for them and\ntheir needs for their idea of fun than other Killers that opted-in for sport and are prepared to lose and are\nprepared to minimize their losses.
\nA somewhat related disinterest in the new system I've seen from some Killers I've talked to with the new PvP system\nis that the ranking system for matchmaking doesn't have a visible "numbers go big" metric for them to watch and\nbrag about like many other common Killer-focused games such as the Call of Duty franchises, Rocket League,\nFortnite, etc. Many of those make matchmaking stats much more obvious, notable and sometimes directly and\nobnoxiously in their face. These are Killers mostly on the Killer-Achiever border that want that exciting\nachievement to brag about that directly reflects their Killer side. It somewhat makes sense that Sea of Thieves\nisn't making ranking numbers a part of the UI: they want to keep it somewhat secret sauce, because it needs to be a\ncrew ranking (team ranking) it by necessity has to be an aggregate across multiple players (which makes it harder\nto brag about personal scores), and in general Sea of Thieves tries to feel like an even playground/sandbox so\nsuch numbers are also somewhat counter to that spirit of play.
\nI know the developers of Sea of Thieves tried to mitigate this somewhat with the "Defensive" option to play the\nnew systems, where it is most and worst like "Emissary 2: Glowing Figurehead Boogaloo". This mode suggests that if\nyou put a target on your own back and go out doing normal PvE stuff to build up a hoard of loot to defend that you\nwill in theory gain other rewards faster (when you successfully defend your ship and hoard of loot). This was the\noriginal promise of the Emissary system itself: put a target on your back, gain faction rewards faster. To be fair,\nthe game even lets you stack both Emissary 1.0 and Emissary 2.0 for higher risk/reward.
\nThe original Emissary was balanced so that the target on your back is visible mostly only up to the edge of the\ncurrent horizon, unless you were representing the "sometimes PvP" Reapers faction in which case your target is\nalways on your back but you get potentially greater visibility of other Emissaries, eventually, if you do well.
\nIn contrast, the new "only PvP" factions and the new "Emissary 2.0: Hurt Me, Please" defensive mode leaves the\ntarget up on your back for all to see no matter what and remains always visible on the map. It adds the additional\nrisk of "invaders" that can spring out of the water at any time. ("Invading" is of course the other option from\n"defending".) Additionally, the new Emissary cuts out most of the PvE-based reward gains unless you have specifically\nengaged in PvP at some point and won. This greatly increases the risk/reward, and so much so, that I have yet to\nfind anyone that thinks Defensive mode is worth the time investment. I knew enough players that were afraid enough\nto raise the old Emissary flags at all, even with the tighter horizon constraints, and the new one has far less\nappeal than even that. Killers, in my experience, want the easy/fast/on demand instant action of the "Invading"\nmode, and while the Achievers are given plenty of commendations to try to achieve in the new mode and Explorers\nand Socializers are teased with role playing-friendly social zones to eventually access/explore if they force\nthemselves to do enough of the new PvP mode, there doesn't seem to be quite enough PvE reward for all of the\nextremely high risk. If you are going to put the time to put in all the PvE work to build up a good loot haul,\nyou have very few reasons to do it with a target painted on your back at all times given the time investment.\nThe current short term rewards don't seem to align well versus the time investment, in my experience and\nanecdotally from other players' experience that I've heard.
\nAnecdotally, from doing a lot of grinding of "Invading" very few seem like players actively defending a loot\nhaul and the vast majority seem like "fellow invaders". Some of the more hopeful on the forums think this is\na temporary case, but I think from the Bartle lens above and examining the current risks versus rewards, I\nthink it is unlikely to ever shift, especially with the December mechanics rebalance. (The December mechanics\nrebalance added more ways to speed up the "Invading" cycle, further making it the key focus of the new system\nand further leaving me questioning who the "Defending" mode is for given its risk/reward balance.)
\nMy "home" perspective is from somewhere shallow into the Explorers quadrant in that on a given night I might\nlean into the Achievers side and feel the completionist bug, or I might lean into the Socializers side and\njust want to hang out with people. I can't say I've ever felt much of a Killer itch natively. (There is\nsometimes a Socializer peer pressure for a bit of blood lust and I'm not immune to that, but my primary fun\nin those cases still feels a lot more for me like "socializing" than "killing".) I feel frustrated that cool\nnew social areas were opened to explore with seemingly impossibly high grind requirements for non-Killers.\nOn the one hand this certainly gives me a reason to play these new systems with a Socializer or Explorer hat\non, sure. On the other hand this makes me somewhat miserable and upset with the experience and while there are\nKiller-Socializers that might appreciate the new spaces, a lot of the Killer quadrant won't appreciate that\nsort of new content as much as other quadrants. The Bartle types as a lens also generally suggest that\nKiller-Explorers may be among the least likely minorities in multiplayer games because that pairing crosses\nnot just one but two axes at once. (Again, Bartle types are just a first order approximation of a player base\nand it's possible game metrics may even suggest it is a larger minority than that concept of abstract axes of\ninterest imply. Approximations remain useful for outside analysis though because I mostly don't have access\nto any Sea of Thieves statistics but my own.)
\nAgain, it is hard not to let my personal experiences sound too much like I hate the new systems on principle.\nI appreciate that true Killers have needed systems like this since the shutdown of the Old Arena and not\nevery update is about me or how I want to play. I've done lots of "not fun" grinds in Sea of Thieves and I\nlikely will again, that's the nature of my relationship with the game at this point. I just also am the sort\nof meta-gamer that I will do a semi-academic breakdown of the process and over-evaluate it, and then blog\nabout it, because that is fun in its own ways to me.
\nAs an Explorer, I've explored how repeatably badly I can intentionally suck at the new PvP to grind my way\ntowards its social rewards with the least emotional investment on my part (because that just gives me anxiety\nand isn't fun for me) and preferably the least amount of time investment. This is the meta-game I've been\nplaying with the new system. I think I have a system at this point, an algorithm of sorts that is just\ndo x, y; wait until z; do a, b; wait until c; repeat. The completionist in me is haunted that this system\ndoesn't quite earn me a bunch of statistics for some additional commendations and I'll have to do a lot of\nthis grind again with crews of enough Killer hats anyway if I eventually care for completionism, but I\nnever completed the Old Arena either (and its achievements still haunt my Xbox, "Legacy" mark or not; I was\n90%+ in one but couldn't care enough before the Arena shut down and now that's just going to be forever stuck\nat the top of my "nearly completed" list in Xbox dashboards and a constant reminder in that Xbox sidebar that\nshows up when you pause a movie and the Xbox is close to sleeping, sigh).
It's kind of fun for me at this point, boring rote repetition aside, seeing how fast and how often I can lose\nmatches. Though I've still got a large number of losses left before I get pity access to the new social areas.\nI've explored many of the ways to lose matches and narrowed down the ones that give any reward and then\nnarrowed down a few that give the most possible loss reward for the amount of time investment. (Again, I have\nbuilt a system for losing. I am maximizing my losses.) I am deeply amused at my growing count of accidental\nwins. (My current system does not involve firing a single cannon shot at an opposing vessel. Wins truly are\naccidents entirely out of my control at that point.)
\nI've discussed my system with fellow completionists and some of them have been appalled. They don't want to\never grind just for losses. They can't imagine what that would do their rankings. They hate what that might\ndo to standings that they can't even see (because as mentioned above, that is not something the game is\ninterested in visualizing). But we can meta-game that a bit, too: So far the development team have stated\nthat a crew's ranking is a pretty straightforward average of each person's win/loss ratios. Someone with a\nlot of losses brings the crew average down and makes battles on average easier (when easier opponents are\navailable). I don't care about my PvP metrics and I'm more than happy to be the good luck albatross of\neasier battles. I'm not saying losing a lot is a great strategy in the long run, but there are certainly\ntactical advantages to it. It's okay to suck sometimes, especially if that's more fun for you and\nyou aren't a jerk about it. (Bluey has an episode or three about that.)
\nFolding Ideas somewhat recently dropped an hour and a half dive into the Raid-focused and end game\nMetrics-focused culture in the MMO World of Warcraft called\n"Why it is Rude to Suck at Warcraft". This dropped late\nin my Bluey binge and its Imaginary PhD dissertation and with the giant swirl of Sea of Thieves\nmeta-game thoughts above. I paused somewhere around nine minutes and forty seconds into the hour and a\nhalf pseudo-documentary and said to a Discord that was discussing it something to the effect that it was\na) poorly researched, and b) the entire hour and a half could probably be summarized by a single tight\n9 minute Bluey episode.
\nI'm not that wide or deep in my "pure" academic background. Most documentaries I gloss over when\nreferences and citations fly by. I focused on hard, practical engineering work for the most part, including\nthat instead of doing a Master's Thesis I opted for a Master's Project as the more practical option. (I\nbuilt a simple "game engine" for analyzing swarm algorithm mechanics, a neighboring sub-field to machine\nlearning, in a light JS/Self-inspired custom language REPL designed specifically for very easy "follower"\nmechanics by default. Maybe not that practical outside of specifics to my advisors at the time, but more\npractical than the average Thesis.) But it turns out that there's one domain where you can directly call\nout my strange academic background: the one I already mentioned, games criticism and academia circa 2009.
\nThat roughly 9 minute stop in the Folding Ideas video felt like a direct call out to me specifically. I\njumped out of my chair at the very first citation and went back and paused it to reread it and make sure\nthat it was as bad as I had assumed. The video was quoting a 2006 "text book" that was among that deep dive\nI did in grad school (and I believe is in one of the many boxes of my personal library cluttering my den\nfor the last couple of years, because I keep procrastinating dealing with them). But it wasn't quoting it\ndirectly, it was quoting it from inside of a not directly related article. It was citing a quote without\nhaving directly read the book it was quoting, getting the quote itself only second hand. That's a huge\nacademic faux pas in general, but sometimes necessary when dealing with long out of print stuff. 2006\ndoesn't seem to qualify to me as "long out of print" (there are hardcovers for sale for as little as $6\nused on Amazon).
\nThe further you get into the video the further it becomes clear that their reading overall stopped well\nshort of many primary and secondary sources. Though to discuss why I think we need to first discuss the\nconclusion of the video and so this needs a massive spoiler warning for anyone looking to complete\nthe Folding Ideas video. I include a spoiler warning here because I've appreciated many Folding Ideas\nvideos before this one and shade aside to this one I wouldn't have spent 45 minutes watching a half-hour\nvideo at 2X speed, several Discord and Mastodon threads, and this much time writing up a blog post on\nsomething I didn't otherwise respect. I just want Folding Ideas to do better, I'm not interested in\nsending pitchforks in their direction. There is some good content meat in the sandwich of bad academics\nthat could have been better researched. Go watch that video if you are so inclined and come back to\nthis post unspoiled.
\nThe conclusion of the video is basically (and baldly) that videogames are soylent: they are made of\npeople. This should not be a shocking conclusion to anyone in the history of games. This wasn't a\nshocking conclusion in 2009 or 2006. This is three-fourths of what Bluey is about in almost any\ngiven episode. It takes people to play games. People bring their baggage along with them into the\ngames that they play.
\nThe weakest part of the Folding Ideas conclusion to me though is that it ends without any suggestions\non what to do about anything discussed in the video. It ends with roughly a noncommittal shrug. This\nis disappointing on a number of levels. The first one is because it took my immediate gut reaction\nthat I could substitute a random Bluey episode for the Folding Ideas (though it may take me longer\nthan an hour and half to explain why, as you can see here in this very blog post) and one ups it:\na random Bluey episode (or a half hour of them) would likely be a better use of time because they\noffer better starting grounds of solutions to the problem statement. Bluey gets into lots of\nsuggestions about how you engage with players with different ideas of fun and how do deal with\ninter-personal conflicts that arise in such situations. Certainly it delivers these suggestions in\nschool child terms, and a lot of World of Warcraft players would look immediately look down on any\nsuggestion that they should watch more of a children's show, but that's still a good foundation for\ndeeper discussions to start from than just shrugging at the question of "What do we do about it?"\nIt speaks directly to that conclusion the video thinks it makes: if games are people, the rules we\nbuild to "play nice" and try to get children to learn from an early age, apply at every age. To\nsome extent it really doesn't matter if you are playing "Keepy Uppy" or World of Warcraft if you\ncan't play nice maybe you shouldn't play at all. Those are eternal lessons to learn about human society,\nwhich why we work so hard to teach them to children.
\nAs nearly a tangent here from "Imaginary PhD dissertation" brain: one of things I found so powerful\nabout Bluey and why it resonated so much was exactly this. The show starts from a lens of games,\nand nearly everything in the show is about games, including the intro is a game, but the life lessons\nare all so very for real life. It is said that games are a key component to how kids develop life\nskills by starting in relatively safer spaces, but something that not enough people remember into\nadulthood is that while games are built to be "safer spaces", they are "safe spaces" only somewhat\nfree from real life complications, and school of hard knocks real world life lessons. Games are one\nincredible part of how we train each other to better live in a society together, and the lessons we\nlearn both come from and extend back out to real life. (Bluey has many of its share of those same\nsorts of games that children play to learn society itself: "Doctor", "Shopkeeper", "Parents", and so\nmany more. Again, with Bluey's studio calling itself Ludo Studio I cannot imagine much of this is\nan accident, and I don't know it is my place to tell them "well done", but I can suggest that at\nleast one fever-addled, childless adult was so impressed they imagined they wrote a PhD dissertation\non it.)
\nIt's not entirely a tangent, though, because it gets back into the narrative of why it seems like\nsuch a shame that Folding Ideas stopped so short in their own research. I know a lot of this about\nwhy Bluey seems like such an incredibly well done TV show to me precisely because of that weird\neducation I gave myself. The Folding Ideas video gave two reasons why they thought it best to stop\nshort. The first I think comes directly from that confusion between "safer spaces" and "safe spaces"\nand a second-hand criticism that the early literature focused possibly too much on "safer spaces".\nA lot of the literature did explore the concept of "ludic spaces" as "safer spaces" and what that\nmeant about games, but most of it was specifically coming from that "we think of games as\nchildish or child-like" and directly defining how "ludic spaces" may seem "safer" at first glance\nfrom a raw risk/reward standpoint than "real life", but absolutely exploring all the ways that\n"ludic spaces" are always still a part of real life and "safer" is never safe from real\nworld consequences nor real world harm.
\nThe very cover shown as Folding Ideas dismisses almost all of older research in this way is a book\nof first and second hand accounts of people's lives in Second Life and deeply proving that any\nattempt at "second life" is just "real life". It gets into real life marriages that happened inside\nof and because of that game. It gets into people who tried to establish very real businesses in the\ngame and in some cases for some brief moment made it work. It gets into real life crimes that\noccurred in the game, some involving Second Life's powerful scripting tools, and others involving\nold fashioned terribly human societal problems like trafficking. A book mentioned elsewhere in the\nvideo third hand but clearly not directly read got deep into EverQuest life and the societies it\nformed and again very real things like marriages and divorces. All of these and more were in\nconversation at the time with the situation that occurred in Sims Online. Sims Online was a real\nvideogame that EA spent millions of dollars to develop but never saw a single copy on store shelves\nbecause in the relatively few hours of its Beta existence it spawned an entire organized crime ring\nand allegedly had accusations that even got the US FBI's attention. That was the game that spooked\nEA so bad that they got out of MMOs for nearly half a decade (despite being an early and profligate\npublisher of them prior to that), and their lone running (though long-running) MMO today is\nStar Wars: The Old Republic. (A lot of history rewriters today claim that EA got out of MMOs\nbecause they couldn't compete with early World of Warcraft, but that narrative forgets key parts\nof history that we shouldn't forget. This isn't even a "distant past" problem, even just recently\na parent sued the videogame Roblox among other defendants for its part in facilitating dangerous\nreal world trafficking.)
\nThe other reason that the Folding Ideas video gives for why they stopped their research too short\nis "World of Warcraft was the first game to…" This is patently untrue for many reasons, including\nstarting from their own conclusions. World of Warcraft was never the first game to be played by\npeople. Compared to marriage, divorce, running a business, real world crimes like extortion and\ntrafficking, their concern of "some people in WoW were mean to me because I wasn't using\nendgame-class/raid-level analytics tools and tactics" feels utterly banal. It feels almost as\nchildish as those same WoW players would likely dismiss Bluey for being too childish and\ninapplicable to their circumstances, despite being almost the very sort of problem Bluey was built\nto teach about. Even extending that "first game" through the video's various qualifications and\nhedges: WoW wasn't the first MMO with deep scripting. Second Life as mentioned had user scripting\ncrimes even. Nor was it the first RPG game-like MMO with deep scripting. EVE Online has had more\nthan its fair share of mod tools (and Excel spreadsheets!), for longer than WoW. Reaching back\nfurther to text MMOs everything that the video talks about happening with mods and analytics tools\nhappened in the history of text MMOs. Text MMOs used Telnet, an unencrypted, dead simple\ncommunications protocol and there was no way for text MMOs to have any control of mods and analytics\ntools (and many also had server-side scripting tools as well). The history of text MMOs is also\nfascinating here because there was an "other side" of the hill that graphical MMOs still haven't\nquite hit (though ones like Second Life try): when everyone has scripting tools at their disposal\nat some point it stops being interesting endlessly data mining the existing content and there's a\ndeeper push to just build your own content. Many of the text MMOs with the most power in user\nscripting were also the most free in terms of possible content and how people could play/engage that\ncontent. There was little need for "perfect tactics" because there was always more content. Graphical\nMMOs have a while to go before we see that to any degree like text worlds saw (though for another\ninstance Cryptic Studios certainly has spent a lot of time exploring it with their "Foundry" efforts\nand tools in their various MMOs over the years as well).
\nAcademics is certainly a constant process of learning new things and applying what you learned in\nnew ways until eventually you discover a better idea of things. But that also doesn't mean that you\ncan just throw out all of the academics from before you were born or your favorite game was born. The\nFolding Ideas video's own citations imply several places where the team could have "followed the links"\nto earlier works that would have enriched the video and stopped just slightly too short to help even\ntheir own conclusion. Some of those books they skipped might have gone a long way to helping them come\nup with suggestions to make the game's culture friendlier than the shrug they ended with. Different\nplayers exist with different ideas of fun, those early books spent a lot of time trying to describe\nthat and coming up with very rough approximations such as the aforementioned Bartle Types, and trying\nto find ways to make more games appeal to "all four quadrants". That many of the games they described\nare gone and long unplayable doesn't make them any less relevant today. In some ways it shows how much\nmore games need to mature that we so easily forget entire cultures of players, just as anthropologically\nlost as any empire lost to ruin, and often barely covered in a handful of first hand accounts in academic\nliterature, such as the ones this video referenced but skipped. It's all the more reason not to ignore\nthe first hand accounts that we do have, to not just stop at third and fourth hand criticisms, but\nread some of it for yourself.
\nI also have few illusions that I've done much better than Folding Ideas at beating a random Bluey episode\non these topics. This post is nearly seven thousand words and its own far cry from a tight 9 minutes of\ntelevision. (It's also still a hundred or so pages shy of that combined Imaginary PhD dissertation I\ndreamed that I might have written.) I suppose the most useful takeaway is, go watch more Bluey. Also,\ngames are complicated and hard and full of real life and there will always be so much to say about them\nand so much already said about them worth reading.
\nNot to be confused with Game Theory (of Economics), though there is some obvious cross-over. ↩︎
\nI realize that I fell out of the habit of "of the Moment" posts as so\nmuch of that sort of discussion moved to social media. I was reminded that it\nmight be fun to adapt this Mastodon thread that started as a\ndiscussion on Discord into a "proper" blog post.
\nA Discord-posted meme of a tweet of how hard Mark Hamill looks in\nSlipstream, a 1989 rarely seen film, reminded me that the movie had\nbeen sitting in my "To Watch" pile for some time. I did not recall why\nit was on the "To Watch" pile, it might have been because it was a\n"lost classic", it might have been as a "so bad it is good 'classic'",\ngiven the age of how long it had been on my "To Watch" pile it might\nhave been something random like possibly people talking about the\ncredits of Robbie Coltrane around the time of his passing. I may never\nknow, I did not take good notes.
\nThe reminder that it was on my "To Watch" pile sparked the curiosity\nto re-check on it on JustWatch, which told me that Tubi had it free\nfor streaming (with ads) and with encouragement from that Discord\nchannel I decided to watch it.
\nThe was directed by Steven Lisberger best known for Tron, and was\nhis fifth and final film. IMDB says that the movie didn't get much of\nany US release in 1989 because the production had bankrupted the\nproducer, most famously a producer of Star Wars. Interestingly, it\ndoesn't seem to have been budget overruns or the other usual reasons\nfor a production to bust: that producer went through a messy divorce\nthat allegedly included awarding the ex-wife the royalties from Star\nWars which was exactly where the Slipstream budget was coming from.\nOops.
\nI thought Slipstream wild and mostly fun. It was sometimes hilarious\nin its schlocky, trope-filled pulp dialog. My overall impression was\nthat it was a bit of a "lost classic" in that way that if I'd stumbled\nupon it on VHS in a hidden weird shelf at a Blockbuster at the right\nage in the 90s I might have loved the movie growing up.
\nThe closest comparison for several reasons seems to be Waterworld,\ndespite Waterworld having been produced after Slipstream.\nSlipstream plays as something of an "Airpunk" Waterworld (an_\nAirworld_? [1]). It was equally a flop like Waterworld for budgetary\nreasons, but where Waterworld simply spent too much, Slipstream\nseems cheaper and overall probably well budgeted if the personal\nmistakes of the publisher hadn't interfered. Waterworld has a\nseriousness to it that plays corny, whereas Slipstream seemed to me\nto have an intentional playful corniness throughout (that trope-filled\npulp dialog, for instance), in ways that evoked to me a lot of old\npulp novels and radio/TV serials. (Much as Star Wars and Indiana\nJones mine those old tropes.)
\nThe opening narration introduces us to the idea that after a\nconvergence of terrible climate change disasters, most of what remains\nof humanity are only connected via a harsh air current known as the\nslipstream. (No need to wonder what the title of the film refers to.)\nThe other obvious type of film to compare this to is a Mad Max-style\n"post-apocalyptic road trip adventure", with the interesting twist\nthat all the "cars" in Slipstream are gliders and small aircraft.\nThat gifts us a lot of great B-Roll and C-Roll footage of small planes\nthrough valleys in Ireland and Turkey for the film's version\nof a cave-filled, wind swept post-apocalypse. From the opening\noverture the score goes all out to sell these plane trips as\nincredibly important and maybe goes harder than it should, but I\ngreatly enjoyed that. Later in the movie those types of establishing\nshots also introducing the movie's few "drop" tracks, amusingly\ndiegetic in those moments and some equally harder than they needed to\nbe tracks.
\nThe movie is just full of some of the wildest (and most fun)\nperformances. The aforementioned Mark Hamill plays a blond-dyed\nfascist cop and seems to have great fun hamming it up as the primary\nantagonist of the film. (The above mentioned tweet was correct, his\nhair dye and the films costuming choices go a lot harder than they\nneed to, like he was a cut extra from a Matrix sequel, but work well\nin the context of the movie.) The primary protagonist of the film is\npre-Twister Bill Paxton having some of the most wild-eyed fun\npossible, getting some of the worst, most hilarious one-liner dialog,\nand chewing scenery along with it. Pre-Jurassic Park Ben Peck (as in\n"Clever Girl" Muldoon) plays the heart out of a role that is too easy\nfor me to accidentally spoil. There's a blink and you will miss it\ncameo from Ben Kingsley. Robbie Coltrane has the chance to steal a\ncouple of wild scenes. F. Murray Abramsom gets a strong scene. Just\nabout everyone in the movie seems to have the right idea of what sort\nof movie they are in.
\nStrange caveats to mention:
\nOther than that it was a fun "so (intentionally) bad it is good" movie\nwith an interesting "lost classic" history and vibe to it.
\nDoes that imply the eventual existence of an Earthworld\nand a Fireworld? No one will expect it when the Fireworld movie\ndrops. ↩︎
\nPreviously I blogged about many concerns that I have about the sorts\nof examples that Angular sets (deep in its core libraries) and how I\nfeel like it leads to a "pit of failure" when it comes to reliability\nengineering and performance optimization. In my day job I feel backed\ninto a corner where I have to support Angular application development\nand have had to become something of the performance expert and\nperformance "officer" against my early advice that we should have\npicked anything but Angular. In the end of that complaint post, to\noffer something constructive, I offered some bon mots about what you\nmight do if you were to rebuild Angular from nearly scratch (I called\nthat idea "Project Gawky" if you want to skip to it). At the end of\nthe day though, I'm a pragmatic software engineer. It's always my job\nto build my way out of problems, especially solving other people's\nproblems.
\nThe short story is that I've built a growing collection of libraries\naround what I've called the Pharkas Component Framework. It codifies a\nlot my "Observables-only" best practices into what I hope is a "pit of\nsuccess" tool that's easy to slot into existing ("brownfield") Angular applications\nand migrate things a component at a time as you can. I think it is\nincredibly useful out of the box and have been using it to improve\nperformance in production apps for months now. At the very least, I\nhope these libraries serve as a good example to the Angular ecosystem,\nwhether or not it sees strong adoption outside of production apps that\nI'm personally charged to "grease the wheels of".
\nI thought I would narrate some of the longer story as well. I'm very\nproud of Pharkas and what it accomplishes as an example to get around\nwhat I think are problems in Angular deep in the core libraries of\nthe framework, but I also feel like I need to provide at least as much\nmotivation and context as I can on why I built this to help answer why\nanyone should trust Angular libraries written by someone that\nunequivocally admits to hating working in Angular.
\nWhen I last blogged about Angular I was obviously already trying to\nthink of constructive ways to build my way out of the mess. I\nmentioned these "Project Gawky" ideas in case they sparked someone\nelse to maybe put in the work, because at the time they mostly\nrevolved around replacing or somehow augmenting/extending Angular's\ntemplate language compiler. Angular likes to pretend that it doesn't\nhave a template language "it just uses HTML" and as you would imagine\nthis means that Angular's (massive) template compilers (there have\nbeen several massive rewrites) themselves are somewhat "secretive" in\nwhat of its internals are publicly documented. They aren't really\nbuilt for easy replacement or augmentation/enhancement. That lack of tools\nsupport is the core to why "Project Gawky" was much more of a\npie-in-the-sky rewrite idea than a pragmatic solution to offer.
\nSoon after publicly documenting those thoughts on my blog, but while I\nwas still in the middle of thinking about trying to construct my way\nout Angular, I got tossed into a massive performance fight where the\nbiggest production app I was working on would just "stall out" for\nminutes of wall clock time. There was no noticeable network activity, no useful\n"progress" indication, terrible responsiveness to user interactions\n("slow"/"ignored" clicks), and not even a "please wait/processing" beach\nball or spinning hour glass: it was just the absolute possible worst\nuser experience and it was making our production users angry.
\nThere wasn't a clear indication of when the problem started, much less\nif it was a performance regression specific to any recent code. (There\nwasn't even a clear indication of a specific source/cause. The\nreproduction was "navigate the app randomly for long enough".) There\nwas some heavy calculation work in an observable pipeline that\nrecently was refactored just a tiny bit, so in terms of hypotheses,\nand enough evidence that pipeline was shared by enough components on most pages that\nwas my best idea of a place to start. I started in the obvious places\nof making sure that the pipeline wasn't over-subscribed, wasn't\nleaking subscriptions without unsubscribes, and wasn't accidentally\nover-observing to many input events from other pipelines.
\nI started with a lot of taps and console.logging debugging, and in the\nmiddle of that was pointed to RxJS-Spy which is a fantastic debugging\ntool and I can't recommend enough. It provides a simple tag operator\nwhere you give a pipeline a name, which is a no-op in production\nbuilds but in debug builds gives you an entire dev console framework to\nspy on specific pipelines by name or groups of pipelines by regex. It\noffers the ability to choose between console.logging and debugger\nbreakpoints. Again, it's just a great improvement on "tap-style"\ndebugging. Install it today. (I have nothing to do with RxJS-Spy, I just\nkeep recommending it to projects now.)
The more I tagged with RxJS-Spy the more I verified that the app's\nobservable pipelines didn't have obvious leaks and were observing\nthings at a pace that seemed reasonable, including the massive\npossibly expensive calculations I was worried about in my hypothesis.\nAt this point I had easily disproved my hypothesis.
\nThis is the part of debugging that gives everyone nightmares: all of\nmy team's code is working just as expected. Does that mean the\nperformance issue isn't in my team's code?
\nIn just about any other framework I would have already have pulled out\n"flame graphs" from the Browser's performance developer tools and been\ntrying to base my hypotheses on real, hard evidence, not just shooting\nfrom the hip in the dark or trying to litter the entire code base with\nconsole.logs in the hopes that I could guess at performance\nbottlenecks. In Angular it is really hard to get useful data out of\nflame graphs for one specific reason: Zone.js.
Zone.js is a supposed "prollyfill" to implement a JS proposed feature\nthat ECMA Technical Committee 39 (TC-39) shot down years ago for being\ndangerous, confusing, and not generally useful. So far as I'm aware,\nAngular remains the only "customer" of Zone.js, and today is entirely embedded in the Angular repo. Angular uses Zone.js\ndeeply to power its change detection systems. Zone.js works by\nmonkey patching the entire JS world like a virus or other malware: it\ninfects every Event callback, every Promise, and every RxJS Observable. It\nplugs in a bunch of its own guts in the middle of every bit of code\nyou try to run in an Angular app.
\nThis "infection" is completely visible in any Angular production flame\ngraph. It changes and impacts every single execution stack in the\napplication. Look at the flame graph and the flames are all Zone.js.\nYou may insert here in your mind an "Everything is fine" meme with the dog labeled Angular and\nall the flames labeled Zone.js.
\nSomewhere in those Zone.js flames your code is probably running. Somewhere.
\nI captured some of these wall clock stalls in the performance tools. I\nknew to expect most of the flame graphs to be Zone.js nonsense. I\nassumed with the stalls taking minutes of wall clock time that\nsomething not Zone.js should be visible enough in that haystack to\nmake a difference and make it possible to find.
\nI consistently found no needles in that haystack. I had minutes and\nminutes of call stacks and the further I dug in the more it was all\nZone.js haystack and not a single needle of application code. Was the\nperformance problem entirely Zone.js? I had no good ideas from the\nglimpses of internal-only Zone.js APIs and source files in the stack traces to\ntell in any reasonable way whatever it thought it was doing. (I still\nhave no good ideas or answers months later. Zone.js remains a\nterrifying horror mystery to me.)
\nAt this point in the horror movie (Happy Halloween! I guess you can\nnow guess why I was maybe saving this story for this month; it's a\ndebugger's ghost story) several audience members would be shouting at\nme: Zone.js has a debugger mode and turning it on is buried as a comment line in\nthe Dev environment.ts file in every template-scaffolded Angular\napplication, because they presume you will need it at some point. As a developer with a lot of experience in debugging, I find deep behavior changes between\nenvironments spooky. It was at this point where I felt that I was out of debug\noptions and I needed that frightening last option. I cautiously opened\nthat last door.
\nWith Zone.js in that weird debug mode, I could no longer reproduce the\npauses and the application performed better than production. 👻 Boo! It's\nhaunted! You're going to die! Get out of the house! 👻
\nThis absolutely is one of my deepest nightmares as a sometimes\n"performance expert": the bad performance is coming from inside the\nframework itself! The framework acts weirdly different in debug and\nproduction environments and it's the production environment\nexperiencing the worse performance in a way that makes no sense. You\ncan't debug your way out of the production problem because your\ndebugger can't reproduce it.
\nHyperbolically, I went insane here. I lost my damn mind.
\nI had hard evidence that Angular was a horror show under the covers\nand was causing our production users real pain, anguish, and\nsuffering. But unfortunately, I don't have the power to convince an\nentire company that the Sunk Cost Fallacy is real and less of a\nproblem than trying to keep sleeping in the haunted horror house\nbecause we got such a good deal when we bought it from the previous\nowners who died of mysterious circumstances that surely were unrelated to why the house was on sale.\nI'm told to "just do my job" and patch a fix.
\nThat left to me the only "logical" and "pragmatic" realization:\nZone.js Must Die.
\nI suppose in the horror film analogy this is the realization by the\nfinal girl that Zone.js really is some sort of serial killer and it is\ntime for her to roll up her sleeves and go on the offense and fight\nback against that ruthless serial killer.
\nSo I started researching everything I could to murder Zone.js without breaking Angular.
\nAngular is kind enough to give you the option to boot up with a noop\n"Zone" and entirely disable Zone.js. Unfortunately, this breaks\nAngular Change Detection in weird ways and most apps stop functioning\nat this point if you just switch to the noop "Zone".
\nAngular's Change Detection apparatus is a direct consequence of\nAngular's broken compromises between providing RxJS Observables and\nthen also providing tons of imperative escape hatches. Observables are\nentirely "push": they push notifications when changes happen. You\nshouldn't need change detection in a pure Observable world, you\nalready have change notification ("for free"), because that is what\nObservables are. (This is where the "Project Gawky" idea gets most\nof its promise: with "free" change notifications you can wire it to do\nsome very smart things also "for free".) But Observables are "hard"\nand Angular couldn't commit to them and the resulting worst of both\nworlds compromise "needs" Change Detection.
\nThat Change Detection uses Zone.js to tell it any time anything\nhappens in the app, ever. Zone.js figures this out by wrapping all the\nEvents, Promises, and Observables in the world that it can find with extra\ninstrumentation. Just to tell Angular "hey, something changed\nsomewhere, I don't know, maybe" (not even really what changed, certainly not to\nthe specific level of individual Observable pushes). Angular still has\nto do a ton of work after those Zone.js callbacks to figure out what\nexactly changed and then from there what to update in the\ntemplates/DOM.
\nFortunately Angular seems to have actually anticipated this, too, that\nwith Observables you have a "push" based system for notifications\nalready and in theory shouldn't need change detection at all. It took\nme something of a deep dive into some of the less well documented\nparts of Angular, but it turns out the framework indeed has left\ncomponent developers a "manual stick shift" option for writing\ncomponents: you can annotate in the Component decorator that the\ncomponent uses the Change Detection Strategy named "OnPush" and that\nyou will push all change notifications manually.
\nThe "OnPush" Change Detection Strategy does give you an offense\nstrategy to use to fight Zone.js from the bottom-up of an application,\nand it needs to be from the bottom up: OnPush components do not need\nto be wrapped in Zones (and generally aren't, though Zone.js is\n"viral" in nature and there are no guarantees it doesn't accidentally infect), which is great. But\nthat also means that OnPush components can only ever use other OnPush\ncomponents. Components that use the "Default" change detection\nstrategy and need Zone.js to detect their changes can use OnPush\ncomponents just fine, but not the other way around.
But a "bottom up only" hope in a brownfield application is still a ton\nof hope to make a noticeable change. A "manual stick shift" option\nisn't ideal, but that too gives hope that you have something that you\ncan automate and that you can build an automatic transmission on top of a\nmanual stick shift with software. It's not pretty, but it is\n"pragmatic" and it will get the job done.
\nTo recap: I lost my mind in horror. I decided that Zone.js must die. Then I\nfinally discovered some hope for a "bottom-up solution".
\nI realized that I could build it: I could codify my "Observables only"\nway of building components into a library, and use that library to\nbuild a handy "automatic transmission" to replace Zone.js-based Change\nDetection with something smarter and less compromised (if it sticks to\n"Observables only").
\nUnlike "Project Gawky", I had a firm place to start to build a useful,\nreusable library for building (Zone-free) OnPush components in an\nObservables only way that could provide not just automated push-based\nchange detection to Angular, but even bring in some of the "smarts"\nideas of "Project Gawky" and apply them as good defaults. By making\nthem good defaults I hope that my library can build not just a "pit of\nsuccess" but a "pit of smart success" to the developers that choose to\nuse it. For instance, React took several major versions worth of\nrevisions and refactoring and a lot of code to deliver "concurrent\nmode" which deprioritizes most DOM work until after idle callbacks such as\nrequestAnimationFrame helping the browser to focus on interactivity\nover DOM element thrashing. Concurrent mode is still not yet the\ndefault in React for several compatibility reasons and needs to be\nopt-in. I've built something similar in my own library for debouncing\nchange notifications to Angular to nice clean requestAnimationFrame time just using Observable schedulers in\nvery little code (it's probably a lot more documentation than code at\nthis point), and it is default and (simple) opt-out. (While it is at\nit, the library also takes care of boring Angular administrative\ntrivia such as ngOnInit and ngOnDestroy lifecycle callbacks.)
Overall, I feel like this library has turned into some of the best\ndocumented and well-tested open source I've had the pleasure to work\non. I'm not entirely satisfied with the testing just yet, as I'm\nwaiting for Angular to make the leap to the next major version of RxJS\nto get some good "marble diagram" timing tests added. Because of that\nuseful default of debouncing to requestAnimationFrame, I need a marble\ndiagram harness that understands and fakes requestAnimationFrame\ntiming, which the next major of RxJS supports out of the box and I\nwasn't happy with backports I attempted for the current Angular\nsupported RxJS.
I named this library "Angular Pharkas" and the approach the "Pharkas\nComponent Framework". This name is a terrible joke, that is possibly\nonly funny to myself. I had lost my mind, remember, and I needed to\nscrape out whatever sanity I could out of this entire horror\nsituation, and had to get whatever I built into production ASAP to make\nusers happy (and naming is indeed one of the hardest problems in all\nof computer science). So I named it a joke and filled its README with\na few jokes to amuse myself. It's maybe not the most "professional"\napproach, but sometimes we need humor in our darkest hours.
\nTo entirely over explain the joke:\nFreddy Pharkas: Frontier Pharmacist was a 1993 adventure game from Sierra On-Line near the\npeak of their development golden age. It can be described as the\n"Blazing Saddles of videogames" and is a joke filled satire of\ncowboy, Western, and Old West tropes in which the title character just wants to\nbe a respectable, civilized Pharmacist selling prescriptions in a lawless frontier town.\n(I recall it nearly breaks the fourth wall as hard as\nBlazing Saddles as well, but it has been a decade easily since I last played\nit. The comparison is not entirely unearned, for those that have a\nhigh opinion of Blazing Saddles.) As someone trying to peddle RxJS\nbest practices in a sometimes lawless-feeling ecosystem, I sometimes\nfeel like a frontier pharmacist when working in Angular. (The terrible\npun there being that "Rx" in addition to technically meaning "Reactive\nExtensions", which was the original .NET name for its\nObservables-pattern framework, is also one of the more common\nabbreviations for the word "prescription" sometimes stylized ℞ and has been used by\npharmacists for that word for a long time, from latin "recipe" meaning "take".)
\nBeyond the base component and the library that provides the core\n"Pharkas Component Framework", I've been slowly accumulating a lot of\nancillary libraries of other open source components and component base\nclasses that make sense to release next to it.
\nSo far the biggest running theme of these other components is\nproviding Angular wrappers for "Vanilla JS" components. There are a\nnumber of factors behind this including the sorts of components I've\nneeded to work on for my day job's production apps, navigating which\ncomponents are "business critical/secret sauce/non-disclosable" versus\nwhich seem good candidates to open source (or clean room rewrite as\nopen source in my spare time, because I lost my mind and have done some moonlighting here) because they have no domain specific\ncode, and that the "bottom up" approach to converting to OnPush\ncomponents especially highlights your "VanillaJS wrapper components"\nas a key "bottom" that needs conversion early.
I think "Vanilla JS" components (and components from outside\nframeworks embedded inside Angular) are especially ripe to gain the\nbenefits of OnPush style components: they shouldn't have any\nchange detection needs because they handle everything internally.\nWiring all of a "Vanilla JS" component's Event handlers, Promises, and\neven Observables with Zone.js just because it may in very unlikely\ncases result in a change to detect is possibly the purest example of\nobviously unnecessary overhead. Zone.js tries not to be that\n"viral", and most existing Angular wrapper components know the pain of\nwhat that means and all the little things that need to be wrapped in\nan NgZone.run callback. (Default components using OnPush\ncomponents don't need NgZone.run callbacks in my experience, that\nboundary is handled automatically enough, unlike the "Vanilla JS"\nboundary.)
I think these Pharkas "family" of "Vanilla JS" wrappers should serve\nas useful examples of the gains to be made in using OnPush component\nwrappers in all cases. There should be no doubts that the performance\nis better in the boundary spaces between Angular and not-Angular.\nThere's no NgZone injections and no NgZone.run calls. There's no\nchange detection notifications necessary at all when the component\nhandles all of its own update cycles.
I think they also serve as good, interesting examples of the types of\nsetup and teardown you can do when you think entirely in Observables.\nI think that's often one of the things developers complain the most\nthat they need imperative "escape hatches" from Observables for (and\nwhy Angular is the bizarre compromise that it is): dealing with the\nboundaries between components that understand them and those that have\nmore imperative APIs. You can do a lot with Observables if you put\nyour mind to it.
\nThese libraries are also more documentation than\ncode. Some of them are direct drop-in replacements for well known\nAngular wrapper libraries and I think you'll find less, easier to\nunderstand code than the wrappers that they replace, even before you\nadd in the additional benefits that they simply perform better.
\nThe "demo site" for Pharkas right now is a collection of these\n"Vanilla JS" components themselves (more than one!) used in a combined\n"dashboard" with (fake) real time data. I'm incredibly biased here,\nbut I have never seen performance that strong at the "Vanilla JS boundaries" anywhere else in the\nAngular world. The real time is "fake" but modeled at speeds and\namount of data I've seen in actual real time dashboards in Production\n(in Frameworks that are not Angular). There's definitely no strange\nand unexpected Zone.js stalls. (The demo site is built in the Angular\nnoop "Zone" so truly has no Zone.js at all even in accidental\nfallback.)
\nAll of this is MIT licensed open source, and I encourage everyone to\nat least dig in and glance at the source and maybe try to learn from\nit, if nothing else, even if you don't think you need any of these\nlibraries in your own production work.
\nThe "Pharkas Component Framework" is agnostic to how you build\nObservables, it only mandates that you use Observables.
\nThere are a lot of options in Angular, many inspired by the React\necosystem's Redux (in my opinion without understanding the reasoning\nbehind Redux, but that is a complaint for another blog post) such as\nNgRx, NgXs, and more. Pharkas doesn't care if you use any or none of\nthem. It works well with them. It works well without them.
\nIn my company's production we already have a wild hodge podge of all\nof the above. In my own development and prioritization I've taken a\n"without them" approach I currently call "lots of small Observables"\nwhich may be possibly called "Atomic Observables" in analogy to the\nReact "counter-Redux" term "Atomics". Today I don't have a library to\noffer on this pattern. I see it as simply a pattern and an "obvious\none" at that, so I don't think it needs a library at all. (I might\neven describe it today as a "natural" pattern of Observable building,\nimplying it is the NgRx/NgXs/et al of the world that is perhaps a bit\n"unnatural".) It is on my TODO list to eventually try to write some\nbetter documentation on that pattern in the hopes it sparks joy in\nsome developers.
\nAt one point I thought Pharkas "needed" a state\nmanagement answer or to be a little bit less state management\n"agnostic" to be a "real" Angular Observable library (thanks NgRx/NgXs\net al for that bit of impostor syndrome), but I decided YAGNI (you\naren't going to need it) and yeeted it out in early versions and have\nno regrets having done so.
\nI probably wouldn't if I were you. You likely have no good reason to\ntrust my claims at face value and doubt my credentials. I probably\nwouldn't even build this library, much less offer to maintain it if I\nconvinced my day job to avoid Angular like the plague, which I have\ntried to convince them multiple times. I don't blame you to be\nskeptical.
\nHighlighted and self-aware summary of previous sections:
\nI scratched my own itch here. I solved some critical production\nproblems that needed solving ASAP, somehow or another. I did what I\nhad to do. This blog post isn't a plea to use this work. I have made\npromises that I think you would see clear performance gains and\nkinder, gentler developer experience if you to do that,\nbut I don't expect you to take my word for it.
\nWhat I would like? Please learn from it! It's a handy, easy to explore\nMIT-licensed Open Source repository. If there's one particular\ntakeaway here: use OnPush components everywhere you can! This truly is\na bottom up initiative. It needs to be "grass roots" in Angular, because it is not the default. Component\ndevelopers (especially those wrapping "Vanilla JS" components) should\nstart leaning OnPush component by their own default choice. I hope no one else\nexperiences the debugging ghost story 👻 I did to the same extent and it\ntruly is as rare as it seems in Angular that more people don't call\nAngular the "haunted house framework" or worse, but after having experienced\nthat every library I see in Angular I now evaluate on "does it use\nOnPush components?". You don't need Pharkas to build OnPush\ncomponents. I think Pharkas makes it very easy to do that, and adds\nsome nice "automatic transmission" and smarts on top of it, so I would\nrecommend taking a look using it to build your next components, but\nagain my plea here is only for using OnPush components, I don't care\nhow you get there ("manual stick-shift" or not).
I hope I have set a good example here.
\nHappy Halloween, and good luck if you are an Angular developer. 🎃
\n","date_published":"2022-10-30T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2022/08/17/dont-grow-old/","url":"https://blog.worldmaker.net/2022/08/17/dont-grow-old/","title":"Don't Grow Old","content_html":"I wrote what follows this foreword on July 9, 2018. I was sitting with my sister at the bar at the\nrestaurant where my brother worked. It was some of the earliest evening hours the restaurant was\nopen and there was hardly anyone there. We both were drinking as we were waiting to catch my brother.\nOur grandmother had passed away. We were there for each other, to spread around some hugs, and to\ncry into some bourbon, as just one stop in a busy grief tour that always used to be expected to come\nfrom a family's funeral week. (2020 told us not to even take that for granted, of course.)
\nThe title of this essay came easily at the bar that evening (though it still felt like afternoon)\nand I recall the text flowed out quickly behind it. I think I finished it before I finished my\nbourbon that afternoon. That's how I remember it at least.
\nMy father believes a lot in sharing (and preserving) memories and especially loves to fill times of\ngrief with impromptu group circles of memory sharing. Most usually in such situations I feel under-\nprepared like I forget to do the homework and I find it stressful and forget any useful memories and\nrarely have much to add. I appreciate everything about it, and I love my father for it, even if I do\nslack off on the "homework".
\nThis essay felt to me like one of the first times I was ever prepared with the homework, and yet the\nopportunity never quite arose to read it publicly. That's what I had written it for. Some of that is\ncertainly on me for not speaking up louder that I had something prepared and wanted to read it. Some\nof that is just the blur of all of that and way that grief gets processed and everything else going\non. It's funny in its own little way that the one time I felt prepared was a rare time where I didn't\nfeel I needed to be.
\nI'm sure I'm still processing this grief, as it's been a weird four years. I thought something that\nmay help a tiny bit is the small closure that would be from at least publishing it publicly, since\nit was intended as a public address, though presumably in a admittedly in more intimate setting like\na family dinner. There two it's funny in its own way that actually doing that in the moment felt\nscarier than publishing it in the somewhat less intimate setting of a blog post.
\nOther than adding this foreward, I've decided to leave this essay almost entirely as it has been\nsitting in my notes for four years.
\n"Don't Grow Old." It was a constant reminder from my Grandmother. An honest statement, certainly, but there was always a wink to it, a dry understanding and deadpan humor.
\nGrandma was our babysitter for so many important events in life. She watched us during the births of siblings. She watched us those nights a few weeks before Xmas when mom and dad needed a date night, but more importantly a night to buy all the presents to spoil us with. I believe it was Paige that figured out that pattern, used that in her eventual hunt for the presents before the day to open them. Don't grow old.
\nIn college, grandma was a source of reliable, cheap meals, but more than that she was an important sounding board for the stresses and anxieties of engineering school. She'd helped several of my uncles, her sons, through that of course, but the best help she provided here wasn't specific advice. It was the conversation and it's patterns. One of them was always: Don't grow old.
\nGrandma was the best listener I know. She always paid attention and cared deeply about every word you said. She'd ask pointed questions to know everything about it, your thoughts on it, and how you were doing otherwise.
\nOver the years there were many conversations with my grandmother. Lazy Sunday afternoon chats in the den, and late night chats over dessert in the kitchen. We'd talk life or basketball or whatever would come to mind. Sometimes we'd grouse about politics together. She had a dark, wicked deadpan, and in the middle of the conversation would drop some ridiculous bon mot of the day from talk radio with a straight face and it would take a few moments to catch on. She found that hilarious. I found that hilarious, though that hairpin from shock to humor was tough sometimes, she was great about timing that. I've had to apologize for enough similar deadpan jokes over the years that I know I picked up the bad habit, and the sometimes terribly calculated timing from her. I never did understand the appeal of those talk radio shows though.
\nWhen I allowed the stresses of my freshman year of college to spiral to the point where I knew that I was failing at least one course and felt unlikely able to continue, Grandma was the first person I felt I could confide in. I didn't always expect any direct answers, but I knew that the good questions she would ask would get my head around where I was, what my path forward was going to be, how I was going to possibly face my parents at all. Perhaps the closest thing to deep advice I'm sure she gave me then might only have been "don't grow old," which if it is advice, it's always too late when you hear it. Yet at the end of that conversation I did feel so much better, and I did feel that I knew where I was, and what I was going to do. I did tell my parents next. I fought for it, and got two degrees, and made my grandmother proud. I certainly grew up and out of that funk, I'm not sure about old. I hope not.
\nIt's a deadpan joke where the punchline is terrible. "Don't grow old." Grandma said it nearly to everyone, but I sometimes felt like she particularly said and meant it to me a lot. I always wanted to think that maybe that's because I was in on the joke, shared that sense of humor, that realize that all you can do is laugh, even though it hurts. Yet, it was always a reminder, too. Not in the Peter Pan sense of "Never Grow Up", there was never anything wrong with growing up, growing into responsibilities, learning from past mistakes. Don't grow old, don't let it make you a worse person. Don't let the pains of age and time harden you from the experience.
\nI'd like to think that I was in on the joke, but I realize that maybe I just more often needed that reminder. I had a chance to have one last conversation with her, late the other night in the hospital. Despite the circumstances, despite the situation, I could almost imagine it was a continuation of any of those other late night family chats in her kitchen. As I contemplated all the chats I would never have with her, all the stresses and anxieties she wouldn't be there to ask pointed questions about, she made sure to remind me, "don't grow old." Hah.
\n","date_published":"2022-08-17T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2022/07/04/twenty-years/","url":"https://blog.worldmaker.net/2022/07/04/twenty-years/","title":"Start of 20 Years at WorldMaker.net","content_html":"I'm starting into the 20th year of my blog being hosted on this\ndomain, which is an anniversary I chose to celebrate in my usual\nfashion by refreshing the blog's theme. I'll get into some specific\nthoughts on that later. LCARS Moderne "2.0" won't look drastically\ndifferent to irregular visitors to my website, but has a fresh coat of\npaint and takes into account six years of feedback (and web browser\nchange).
\nTechnically, it is only the 19th anniversary at the domain, because of\nhow anniversaries work, but the off-by-one big round number of 20 has\nstill caught me somewhat feeling reflective of the passage of such\ntime anyway. While it is an anniversary I mostly just celebrate with\nnerdy bits of CSS and HTML, it's still so tied into different eras of\nmy life. While some of that history is lost in the current archives,\nfor better and worse, there are still lines I can see in this blog's\nhistory. For examples: there's the point where I stopped publishing\npolitical opinions because I got tired of fighting over them, and\nthere's the point where I stopped posting so many short posts because\nTwitter was built, and those two lines nearly but don't entirely\nintersect.
\nMost of my Twitter posting history is in a zip file at this point as I\nfelt that I had to delete it from Twitter itself. Sometimes I wonder\nabout backfilling short posts and "best of archives" into the blog. I\ndon't know what is in that zip file that remains relevant out of\ncontext. That's part of why I deleted it off Twitter, because time\nrobbed so much of it of context and robbed of context they were\nliabilities I could no longer as easily control. I was a bystander in\nsuch an attack on old out of context posts, and saw enough to leave.\nAdding them to the blog could give them new context, but I'd have to\ncurate them first.
\nSimilarly, I know where the line is where I removed direct commenting\non my blog. Comments were something that I felt important so early in\nthe blog. It was feedback and community. Of course, back in those days\nbefore Twitter and Facebook and "social media" that was what blogs\nwere for. The last comment platform I used was Disqus and I dropped\nthem between privacy concerns with how they were treating data and a\ndesire to reduce JS on my blog to a bare, optional minimum. (Not\nbecause I have anything against JS, it's often a huge part of my day\njob, but because it sometimes gets in the way on a blog in performance\nand flow of reading.) I've got a dump of all the comments in a zip\nfile, too. Some of those I recall were good discussions and I think\nsometimes I should post an archive of at least the better ones, back\nin context of the posts they referred to. Other times I wonder if it\nis better that those comments are gone, the slates clean. It feels a\nbit like the same sort of for better and worse forgetfulness that\nwiped several years of college posts from the blog. Some of them were\ninteresting time capsules and others were worth losing for the pain\nand/or problems they caused alone.
\nI can still see so many lines that marked ambitions damaged and/or\nmajor project failures. I joke these days that "WorldMaker" as much as\nanything today is the name of my impostor syndrome. It comes up as a\n"joke" more often than I'd like because I still use the handle as my\nprimary in gaming and on Discord, out of decades of momentum at this\npoint. I still mostly remember why I picked it, so many years back in\nhigh school on IRC and in forums. In some ways it is weird to still\nbe using it most of a lifetime later.
\nI've never quite been as prolific at short fiction as I tried to be in\nhigh school. (The loss of a few short stories is what I mostly regret\nin the holes in the blog archives.) I've only posted a couple of short\nstories in the past few years. On the other hand I may have been\ngetting better at longer forms of fiction writing. I've won NaNoWriMo\ntwice in the last few years. One novella was a game of pronouns and\nmultiple narrators that test readers didn't like (and I couldn't blame\nthem; it was an intentionally experimental game), and the other is a\nwork of fan fic over on AO3 for now. It's been too long since the last\nattempted game I finished writing, and I've got experiments in the\nforge, but no idea if they'll ever be more than just experiments.
\nThe basics of LCARS Moderne are largely the same: at typical tablet\nwidths and wider it is a Star Trek inspired library interface with a\ncurved C-shape around the main content area, which still scrolls\nhorizontally by default (with JS enabled; more on this in a bit).
\nMost obviously, I refreshed the colors, now with palettes that are\ninspired by the color choices of Star Trek: Lower Decks. On the\ntechnical side I moved the palettes from build time SASS variables to\nrun time CSS variables. Dynamic colors were features I put too much\nwork into previous blog designs, so it's something I appreciate about\nthis upgrade (and how much easier it is today, just swap a CSS class).\nI tried to be subtle with it, and some pages now use different\npalettes based sort of on their function/context. It's not quite the\nevery page load uses a random color scheme of some of my (lost) past\ndesigns (back when that involved so many image files to accomplish).
\nFor a fun example of the more dynamic nature of the color system, a\nred alert toggle button:
\n\nI revised a lot under the hood, in part based on six years of\nfeedback, and in part based on changes in how browsers displayed the\nsite over six years.
\nSo the big thing is that by default I still wanted it to be a\nmulti-column layout like a newspaper that scrolls horizontally on any\nscreen wider than narrow (bigger than a phone screen). I know it is\nweird, and I've seen a bunch of hateful comments over it, but it's a\nretro-future weird that I like and this is a personal site that's\nallowed to be personally weird. I've got an ultrawide monitor on my\ndesktop these days and I like that I have just about the only site on\nthe web that I can full screen on my screen and the site naturally\nmakes good use of all that width. I can read entire articles sometimes\nwithout scrolling, just reading it newspaper style from column to\ncolumn. I still think that is neat.
\nI did try to address some of the "affordance" issues that had been\npointed out over the last few years. (Affordances are things that make\nit more obvious and/or easier to work with.)
\nSix years ago it used to be that multi-column layouts, when in a\ncontainer that scrolls horizontally took the column width you\nspecified as-is and ignored the view container size, so a\nnon-percentage width would cause columns to be cut-off/bleed-through\nthe edge naturally. I thought that was a useful affordance for\n"there's more to scroll" if in most default browser sizes there was\nalways a bit of column peeking out across the edge to encourage\nscrolling. Since then the browsers have all converged on a behavior\nwhere the requested column width is now just a minimum size and even\nwhen the container scrolls horizontally it still tries to balance\ncolumns so that they fill the viewable area of the container\n"perfectly", removing that hint of a column just slightly cut off or\njust slightly peeking in that there's more to scroll. I'm not a fan of\nthis newer behavior the browsers converged to, but I understand why\nthey did that: the new behavior is what more people want, because\nfewer people actually want horizontal scrolling and they'd rather\nthings look more "perfect".
\nI tried to add an affordance back here by adding a "column rule"\nbetween the columns. I still don't want a column rule, as I don't\nthink it matches the aesthetic I'm going for, especially with how\nlittle options there are for how a column rule looks. It is limited to\nan early subset of CSS border styles that feels like a throwback to\nme. I wanted to pick something unobtrusive that kind of blended into\nthe background, but I also wanted to pick something that maximized the\n"affordance" capabilities of the column rule here, as its one of the\nfew remaining obvious hints that "there is more to scroll". The rules\nonly get drawn in between columns, so if you see one at an edge at\nall, it does imply that there is more to scroll. But I was worried\nthat might be too subtle on its own, so I increased the size of the\nrule and chose a pattern that is more obviously "cut in half" on the\nedges. I played with the sizes until I reached a point where I thought\nthat effect was obvious but not distracting. I'm still not entirely\nhappy with the column rule, but I think I've done about the best I can\nwith the current CSS tools.
\nSix years ago there was a non-standard CSS flag I could use to ask the\nbrowser to let the scroll wheel scroll the page horizontally. Because\nit wasn't a standard and only supported by a couple of browsers it\neventually stopped working. So I've added a tiny bit of JS that takes\ncare of it now. When the container is scrolling horizontally the JS\ncode treats scroll wheel scrolling from your mouse as if it was\nhorizontal direction scrolling rather than vertical. This does\ndrastically make it nicer to scroll articles again (if you aren't full\nscreen on an ultrawide or are on one of the longer articles).
\nWhile I was touching it, I also added a CSS class to toggle back and\nforth between the horizontal scroll and vertical scroll. I also added\na not-subtle-at-all button with JS to toggle that and also point out\nthe current scroll direction. It's a lot less subtle than the old\nunaligned columns or the new kind of subtle column rule. It might be\nsubtle that it also acts as a toggle button, if someone really, really\nwants it to scroll vertically "like normal". I don't recommend that as\nthe best experience on most browser sizes. I still have text justified\nat all sizes, which I think looks great in multi-column and phone, but\nwon't look as good at larger window sizes scrolling vertically. I'm\nalso making the choice to not cap the width when it scrolls vertically.\nSo many websites do that today. It's often seen as "necessary" to keep\npeople's increasingly wide screens from making text regions too wide to\nbe easily readable. My preferred solution to that is multi-column\nlayout and horizontal scrolling, as clearly mentioned here, so if\nsomeone chooses to scroll my site vertically, I'm going to leave it to\nthem to manage the width of their browser without me making a strong\nCSS statement on that.
\nBoth of those JS features, the scroll wheel translation and the toggle\nbutton seemed usefully necessary affordances that at this point it is\nthe JS itself that "activates" the default horizontal scrolling, so if\nyou don't have JS enabled you get the vertical scrolling. I still\nthink of this increased amount of JS as "optional" in itself, but\ngiven the horizontal scrolling now "requires" it, it's certainly again\nthe case that the best experience of my website is with JS\nenabled. Few people disable it to notice these days (as opposed to my\nover-indulgences in JS in my youth), but it's a consideration I\nmade all the same.
\nOn that front, I did a bit of "CDN elimination" moving away from third\nparty hosts for code, images, and fonts and moving things back to\nhosted locally only on the site. That should eliminate all third party\ntrackers on this site now. (I don't have any first party trackers as I\nstopped caring years ago, and I would assume GitHub likely has "second\nparty" trackers in its GitHub Pages hosting.) I moved to a bundling\nand install process for LCARS Moderne 2.0 updates, which is kind of\nneat behind the scenes trivia. (esbuild and npm with a bit of robocopy\nif you are curious.)
\nI'm proud of this blog theme and I suppose I expect it to last another\nsix years at least. I expect I'll hear plenty more feedback on it still.
\n","date_published":"2022-07-04T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2022/05/07/visit-sea-thieves/","url":"https://blog.worldmaker.net/2022/05/07/visit-sea-thieves/","title":"About \"A Visit to the Sea of Thieves\"","content_html":"In November for National Novel Writing Month (NaNoWriMo) I wrote\na novella about the Sea of Thieves.\nI posted the whole thing to AO3 which seems the natural home for it\nas a work of fan fiction. I still haven't decided if I want to also\nserialize it to my blog, but I did want to blog about it and where it\ncame from.
\nThis novella, A Visit to the Sea of Thieves, is my second NaNoWriMo\n"win" across many attempts. The first (final working title was The\nSpace Train on the Way to the McMaster Heist) was an interesting game\nof dual unreliable narrators experiencing the same events (planning a\nheist while living as the hospitality crew on a space train) from\ndifferent life perspectives and also a weirder game of pronouns (most\nof the crew used they/them, characters change pronouns midway through,\nsome pronouns were chosen to intentionally be clashing beside\ntraditional familial relationships). Those games kept it interesting\nto write, I felt like they were in service to the story, and helped\ncontribute to making it a "win" in NaNoWriMo, but the beta readers I\ngot (great) feedback from didn't like it very much and I entirely\nunderstand why that would be. So far my best idea for reworking it to\nbe more readable involves adding a third, maybe more reliable,\nnarrator and while that makes sense in my head, I think on paper it\nwould just add more confusion.
\nA Visit to the Sea of Thieves also did not impress some of the beta\nreaders I tested it with, because it a work of fan fiction, and\nbecause there is a stylistic choice I felt necessary to make, but I\nwill get to that. I posted it to AO3 in case maybe someone has nearly\nas much fun reading it as I had writing it, but I'm not sure who that\naudience is beyond just myself.
\nI've been a regular player of Sea of Thieves since its launch. There\nare multiple blog posts in my archives here where I go on at length\nabout Sea of Thieves topics. You can also see the threads of why Sea\nof Thieves would appeal so much to me in even earlier (and still\ndiscoverable) posts about games like Puzzle Pirates. I love the pirate\ntheme. I love the cooperation aspects of crewing a ship together with\nother people.
\nI've developed a lot of weird skills across a lot of regular play. I\nmay not be the best contributor to PvP on a ship, but I can helm and\nsail (solo if need be) any ship in the game. (Sometimes that need is\nstrong: the rest of the crew is busy and you need a ship from one\nplace to another in a hurry.) At one particularly weird point in my\nplay I got absurdly good at dual controller play while soloing a ship.\nThere aren't a lot of good reasons to need to multibox in Sea of\nThieves, it was mostly for the challenge of it at that point. It hurts\nmy head thinking about trying to do it again, but I had some fun with\nit and it would probably come back to me as useless skill that it is\nlike riding a bike and patting your head at the same time.
\nAt helm, I've basically memorized the entire map at this point. Give\nme an island to get to and I will often sail there without needing to\ncheck the map or ask for a heading. I can generally provide headings\nby scanning the horizon and getting a feel of nearby island\nsilhouettes again without needing to reference the map.
\nOn islands, I've become known as a nut for gold hoarding. Give me an X\nmarks the spot map and I'm generally on the Xs first dig attempt. I've\nbasically memorized most common riddle spots and can run riddles at a\nrelatively quick pace. I've had nights where the entire crew were on\ndifferent islands (while I was on helm of the ship) doing different\nriddles and each riddle step I was able to offer useful headings to\nspeed run the riddles to the crew member at each island over Discord\ncomms. There are many puzzles in the game that I know intimately and\ncan solve quickly.
\nI've become known as something of most ship's Lore Master. I've read\nthe books and I follow the in game storytelling. I've gotten real deep\ninto the game's Tall Tales. (I earned the gold curse doing the\nmajority of it solo the hard way in the time before checkpoints were\nadded to them. I fought many players and kraken to get those\ncompletions.)
\nWriting a novella about the Sea of Thieves seemed like an easy "win"\nfor NaNoWriMo given how much of the lore I can explain when prompted,\nand how much of the map of the Sea of Thieves just lives rent free in\nmy head at this point.
\nA lot of my lore hound nature has been built and tested in other games\nover time and Uru was a strong fandom for me. I'm sure there are blog\nposts to be found on that subject.
\nA core conceit to the lore of Uru was always that the events of the\nother Myst games were (somewhat apocryphal) legends of events that\nhappened sometime in the 19th Century (the 1800s) and Uru was "real"\nand player actions happening "now". You, an Explorer among many peers,\nwere personally taking a trek out to the desert in the American\nSouthwest, finding a trail of directions to a peculiar cleft in a\nmountainside, solving puzzles, and from there making a winding journey\ndown below the surface into an extraordinary Cavern full of ruins of a\nlost civilization.
\nUru fandom was full of many different players' journals of their\nexplorations of the Cavern, and though there are many places to reach\nin the game of Uru outside of that cavern in one way or another,\ngenerally the whole fictional landscape was described as "in cavern"\n(as opposed to real life events out of cavern; the overlap with more\nusual uses of the abbreviations IC and OOC amusing and intentional\namong that fandom).
\nSome players' journals got surprisingly detailed. Sometimes because\nthey became guides/walkthroughs. Sometimes just because that's how\nNPCs were generally written, too, and the example was set. Sometimes\njust because players had fun imagining the work they put into their\nexpeditions to the American Southwest, the gear they'd pack and the\nthings they need to do (for safety), as if they were planning a caving\nexpedition to Mammoth Cave in the early years of its exploration or\nsome other similarly famous cave. A lot of the drama in cavern was the\npush/pull between the organization set up to try to keep people safe\nin their explorations and to do respectful restoration (the D'ni\nRestoration Council [DRC]) versus the people that just wanted freedom\nto explore without an oversight organization tell them not to do\nunsafe things. Some of the irony in players' fun journals of their\nexplorations and how careful they planned their expeditions was\ndirectly contrasted with an early puzzle that relied on every player\neither having forgotten to pack something as common to cavern\nexploration as a flashlight or some variation of losing their\nflashlight or not having enough batteries or something (and the DRC\nwas apparently quite stingy with their lovely branded cavern exploring\nhelmets with attached flashlights).
\nOne of the things that you pick up over the years as a Sea of Thieves\ncrews' "Lore Master" is that all of the official lore (such as the\ncomics, the novels, etc) happened years before players arrived in the\nSea of Thieves. Most of it happened some time near the real world\nGolden Age of Piracy in the 18th Century (1700s). (But also some\nancient civilizations older still than even those events.) Meanwhile,\nfor very similar reasons to Uru, events that the players are\nparticipating in are "real" and happening "now".
\nLike Cyan Worlds with Uru, Rare wants to give Sea of Thieves players\nthe feeling like their choices matter and their actions are really\nhappening in the scope of the lore. Unlike Cyan Worlds, however, Rare\nhave tried to take a strong stance against any lore happening "now"\nthat the players aren't directly contributing to and "playing". There\nare no NPC journals of "today's events" for players to discover.\nAlmost all of the "current events" lore today is word of mouth lore\npassed among players in game and on Discord and social media. There\nare NPC quest givers for some events, but in general they leave almost\nall of the interpretation and the choices to the players. There's a\nnobility of purpose there that I respect. There's a weird joy in\nfeeling like your play matters to the overall storyline. (There was\nnearly an entire year of events that contributed into building up the\nresources of a less than respectful faction and as as a completionist\nevent player during those events I remain amused how complicit I have\nbeen in the troubles that faction has since caused, the repercussions\nof which current events have been fighting.)
\nUnlike with Uru, there's a lot less of a journaling culture around the\nevents in Sea of Thieves in quite the same way as Uru. With fewer NPC\nexamples and not as much of the player base even aware that what they\nare doing is happening "now" (which should explain things like Halo\nand Gears of War themed liveries). There are some equivalents: so many\nof Sea of Thieves events and culture are captured daily on Twitch. I\nloved reading the science reports of Merfolks Lullaby. (Their weather\nreports especially on Sea of Thieves have been quite valuable.)
\nBut as far as I'm aware there was a big sort of hole there that I\nthought would be fun to explore: how do you plan a visit to the Sea of\nThieves "now"? What does that expedition look like? How did you, a\nwannabe pirate, fall into making such an expedition?
\nWith my Uru experience the premise of telling that sort of expedition\ntale seemed "obvious" to me, especially because it would be so much\nharder and weirder for Sea of Thieves. It's easy enough to understand\nhow Golden Age Pirates crossed over to the Sea of Thieves, but much\nmore complicated to figure out how you might expect players to cross\nover today. Relatedly, it's easy to imagine preparing a trek to the\nAmerican Southwest for spelunking alone or with friends. People do\nthat relatively all the time. I've certainly enjoyed my random tourist\ntrips to Mammoth Cave. Even though I take somewhat regular vacations\nat this point to the Caribbean it's still a lot more complicated to\nimagine trying to find a hidden sea in the Caribbean, much less doing\nso in relatively piratical garb and with an 18th Century style wooden\nship. I thought there was a lot of fun spaces to world build what that\nwould be like and why it would exist and at least some of the sorts of\npeople that might be crazy enough to do it. So I decided to try\nwriting a "conspiracy thriller" about visiting the Sea of Thieves.
\nThe one stylistic choice that felt like a natural constraint given\nRare's assertion that events that happen "now" should be actions of\nplayers (that left some of my beta readers unhappy) was to write it\nentirely in Second Person. This is the language of a\nChoose-Your-Adventure novel or an Interactive Fiction work where\neverything happens to "you". It's something I've grown up with from a\nyoung age and love. Outside of these play spaces, Second Person is\nextremely rare as an art form. (There's two Charlie Stross books I can\npoint to in the science-fiction mainstream today, at least.) I had\nEnglish teachers in school that loathed Second Person deeply and tried\nto squash my love of writing Second Person tales. I appreciate that\ngiven how rare it is outside of CYA and IF that I got immediate\ndislike reactions from some of my readers. I'm sorry for that, and I\nunderstand exactly where that gut reaction can come from.
\nI never did find counter threads in the narrative I wanted to tell to\ntry add interesting and meaningful choices and make it an actual\nCYA/IF novel, but I considered it while drafting. I think it is why\nthe working title stuck through to completion in the form that it\ntook, it's a (single) visit to the Sea of Thieves, one of possibly\nmany. While I didn't write more than one, I intended too, but then got\ncold feet.
\nBeyond Uru, another influence I might mention is that I'd just\nrecently before November binged For All Mankind. I think that\ninfluence is pretty obvious when you get to it, but I felt I'd mention\nit as a great binge watch since it so far has escaped many people's\nradars.
\nSomething that amuses me was that in trying to write myself a world\nbuilding problem, I accidentally predicted a new real game feature\nthat showed up to players later in November.
\nI wanted to give the impact of a Discord alliance communication\nin-game with the in-book restriction that there's no Discord\nconnection on the other side of the Devil's Shroud (while in the Sea\nof Thieves) so I figured signal flares would easily fit the game's\naesthetic and allow some distant communication. Rare added signal\nflares into the game inventory alongside fireworks in the following\nupdate after I'd already started making that a key part of my alliance\nfleet's action plan in the novella.
\nI like that "great minds" feeling, though some may not believe me I\npredicted it ahead of time. (I do somewhat regularly play Insiders\nbuilds where things are tested ahead of time to collect cosmetics in\nthe main game. I was busy writing the novella that month and missed a\nfew weeks of Insider play. I also tend to avoid spoilers in my Insider\nplay as much as I can reasonably do it. My usual MO in Insiders is "to\ntest if basic Gold Hoarding still works" and friends know I tend to\nrefer to it as "riddle hour". I really do just grab the most basic\nGold Hoarder voyages and grind X mark the spot and riddle maps just\nbecause I find it fun and relaxing and mostly avoids spoilers of new\ncontent/mechanics.)
\nSo yeah, I wrote a fan fic novella mostly to fill a need I saw in the\nlore that would amuse me. I hope there's at least one reader out there\nwith enough of a cross-over to appreciate the novel as much as I\nenjoyed writing it. I also hope it is a fun read whether or not\nsomeone has Sea of Thieves lore knowledge or not. As fan fic I'm\nletting it's primary home be AO3 for now.
\n\n","date_published":"2022-05-07T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2022/01/16/blockchain/","url":"https://blog.worldmaker.net/2022/01/16/blockchain/","title":"The Technical Basics of \"Blockchain\"","content_html":"Trying again to break down that the technical basics of "blockchain"\nare devastatingly simple, because people trying to convince you that\nblockchain is really complex technology are trying to sell you\nsomething, so I've broken it down into a lot of little "chat line"\npieces, and tried to make sure that every technical term is explained\nas it is used (or isn't entirely relevant) with the intended audience\nbeing folks with no technical background. (I think anyone with a\ntechnical background should find this explanation sufficient: "A\nblockchain like Bitcoin is a rebase-only git commit process of a\ntransaction ledger where each new commit hash must start with enough\nzeroes. The committer with the right commit hash is awarded more\ntokens to use in transactions in later commits.")
\nI tried to reduce the number of places where someone can "Well,\nactually" me with a technical quibble and have kept the biggest ones\nto parenthetical asides that should be truly optional to the\ndescription as a whole. I'd like to especially note here that: while\nit is very easy to make such "Well, actually" interjections in just\nabout any technical description of anything, nuance does not imply\ncomplexity. Especially in this case it implies variation. Not every\nuse of "blockchain" is Bitcoin, and there are certainly plenty of\nvariations both like and unlike Bitcoin today, but Bitcoin is and\nlikely will remain "king of blockchains" (and a use of\nelectricity, all by itself, continuing to be larger than the\nelectricity produced by entire "second world countries") so it remains\nthe strongest example to use of the basics of how a blockchain\noperates, technically speaking.
\nI hope it helps. "Proving" that blockchains are devastatingly simple\nisn't going to change hardly any minds on their stance towards\nblockchains and cryptocurrencies. I just hope I've helped do my part\nto break down some of the salesmanship that drives cryptocurrency hype\ncycles ("it is so complex you just cannot understand it, so trust\nme"). But I'm a cynic here and think it is far too late, the majority\nof the damage is done, and that hype cycles or not, for better and for\nworse, "blockchain" is here to stay, and mostly in my opinion for the\nworst.
\nBlock: you've got a bunch of documents to store that rely on/link to\ndata from previous documents
\nOne of the easiest ways to "link" such documents is to record in\n"child" documents a secure ID of the "parent" document
\nA common form of "secure ID" is to use the output of a "cryptographic\nhash function", called a hash
\nA hash is a relatively tiny number that reflects the contents of a\nlarger document
\nWhat makes a hash "secure" is when you can't predict the hash of a\ndocument, but the same document will always produce the same hash, you\ncan't predict the contents of the document from just the hash, and\nsimilar documents produce unpredictably different hashes
\n(That's the difference between any old "hash function" and a\n"cryptographic hash function", what the word "cryptographic" means\nhere: that it meets those security needs of unpredictability)
\nWhen using a cryptographic hash function in this way to link\ndocuments, this data structure has been called a "Merkle tree" since\nthe 1970s
\nIt's natural shape is a tree: more than one document can point to the\nsame parent, there's nothing in the nature of this way of storing data\nthat prevents that from happening
\nIn the case of most cryptocurrencies what is stored in the documents\n(inside of "blocks") is the transaction ledger: Transfer X amount from\nAddress 1 to Address 2, Love Address 1
\nTransactions depend on previous data (need to point to parent\ndocuments; reason it forms a Merkle tree): at some point previously in\nthe transaction ledger enough transactions sent X or more to Address 1\n(and Address 1 has not already transferred that much out) so that it has\nX to send to Address 2 (and is a valid transaction)
\nChain: creating artificial scarcity by "pruning" the (Merkle) tree
\nMerkle trees may have an infinite number of possible branches
\nBlockchains use a "consensus algorithm" to choose which branch is the\npreferred branch, and which other branches to ignore
\n(Forks are still in the same conceptual Merkle tree: the difference\nbetween the Bitcoin, Bitcoin Cash, Bitcoin Gold, etc branches is much\nmore marketing than technical)
\n(Artificial scarcity: there's still an infinite possible number of\nbranches or "forks" allowed by the nature of the underlying data\nstructure, but marketing is great at selling "preferred options")
\n"Consensus algorithms" among other things declare "which document must\ncome next"
\nThe most common "consensus algorithm" (and arguably the only known one\nthat seems to work in the long term so far) is Bitcoin's "Proof of\nWork"
\n"Proof of Work": the next document (block) proves you have done a lot\nof "hard work" in order for it to count in this branch
\n(In computing terms "proof of [hard] work" really is just "prove you\nspent enough electricity")
\nIn Bitcoin's case the "work" to prove is completely stupid: the\n"secure ID" for the block needs to start with enough Zeroes
\nThis is hard: because the secure ID is a secure hash (from a\n"cryptographic hash function") and the output hash is supposed to be\nentirely unpredictable from the input data
\nThe only currently known way to do this is to add a bunch of random\ngarbage next to the document (which is what truly makes it a "block":\ndocument of transactions, plus random assortment of garbage) and see\nif you get enough Zeroes starting the hash (ID)
\nNot enough Zeroes? Add different random garbage and try again (this is\nall the "work" in "proof of work", randomly generating literal\ngarbage)
\nFirst one with enough Zeroes "wins"
\n(Everyone calls this "mining" and not "pruning" because the by-product\nof a "win" is new coins to spend; to incentivize computers to sit and\nspin creating random garbage in search of finding all these "useless\nzeroes" it's a very dumb lottery)
\n(You can't spend coins without "mining": "mining" is what adds [and\nreconciles] your transactions to documents in the Merkle tree\nbranch/blocks in the "blockchain")
\nThere's a name in security speak for this sort of hunt for a specific\nlooking hash (ID): a preimage attack
\n(Technically this is a partial preimage attack because Bitcoin\ndoesn't care what the rest of the ID is after all the zeroes it wants\nat a given time; but from a security perspective any partial attack is\nstill an attack)
\nThat's where Bitcoin's "Proof of Work" especially transcends from not\njust "stupid" but downright "evil" because it is a rapid, heavy attack\non a cryptographic hash function used in a lot of other places as a\nbuilding block of internet security
\nIf someone found a shortcut that wasn't just the brute force "build\nrandom garbage" (why I prefaced with "the only currently known way"),\nthey found ways to predict the outputs of the cryptographic hash\nfunction forever weakening their usefulness as secure IDs
\n(This has happened before. We've lost cryptographic hash functions\nwhen we've found out that they were susceptible to preimage attacks.\nBut in those cases we had decades of warning and known better\nalgorithms waiting in the wings. If Bitcoin miners truly "win" the\npreimage attack we might not have any warning at all and a lot of\ninternet security would be immediately at risk. It's also arguable if\nwe have known better algorithms waiting for such an eventuality\ntoday.)
\n","date_published":"2022-01-16T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2022/01/05/pub-vinaigrette/","url":"https://blog.worldmaker.net/2022/01/05/pub-vinaigrette/","title":"\"Pub\" Vinaigrette","content_html":"I heard once that you can tell someone's commitment to veganism by\ntheir collection of oils and vinegars. I'm not sure how true that is,\nbut I do love a vinaigrette and Good Seasons carafes have taught me\nthat it's very easy to experiment with vinaigrettes to get extra\nflavors, whether you use a Good Seasons "Italian Dressing" packet or\nnot. I appreciate Good Seasons as a simple brand that isn't afraid to\nlet you explore. Just in exploring the vinaigrette possibility space I\nhave been collecting a wide variety of oils and vinegars.
\nOne of my recurring experiments has been with a "Pub" Vinaigrette. The\nbasic idea was that I sometimes love a splash of Malt Vinegar on a\nfish and chips meal like many do, and I was trying to figure out what\nsorts of vinaigrette you could make with it. I was especially trying\nto tap into something with the spirit of "this is a salad dressing you\nmight find to partner with fish and chips as one big pub meal". I\nthink of it the house dressing of a weird pub trying to source a\nvinaigrette mostly from ingredients at hand or at least "close to\nhome". Of course, Malt Vinegar has a very strong flavor profile so\nfinding the other elements to pair with it was tough and took some\nplay/experimentation.
\nI didn't think Olive Oil was right to pair with Malt Vinegar, and you\nwould be wasting good olive oil taste in the way it would disagree\nwith the Malt Vinegar I felt.
\nYou could use a boring Vegetable or Canola oil, and that might be\nappropriate given the boring oils typically used for frying fish and\nchips. I nearly stopped at that almost fine solution.
\nThe discovery that really cracked the experimental project wide open\nfor me was Avocado Oil. Avocado Oil has a rich and nutty flavor, not\nentirely what you would expect thinking about guacamole, but a flavor\nto its own. It's a strong flavor that doesn't get rolled over by Malt\nVinegar like Vegetable Oil would, nor do I think it clashes quite like\nOlive Oil would. I think it adds a "chips" feel, almost the bite of a\nnuttier potato, when paired with the malt vinegar.
\nThe big variable in my experiments so far have been been the amount of\nmustard that I've added. I think this "Pub" Vinaigrette works well\nunseasoned without mustard. I think a hint of mustard makes it more\ninteresting. I've been working up to seeing how much mustard I can\nadd. Because I love strong mustard, I want more mustard salad dressing\noptions that aren't a cream or dijon (honey mustard or not). I\nassociate Colman's Mustard with fish and chips night at a pub\nsometimes too, from some appetizers that come to mind, and keep\nwondering how much I can dial up "Pub" Vinaigrette towards that goal.\nSo far I've not been disappointed with my experiments. In my most\nrecent attempt I used almost a third or more of a entire shaker of\nground mustard, believe this may definitely be a dressing where the\nmore mustard the merrier. With that much ground mustard mixed it\nturned out almost lighter than the color of orange juice (despite how\ndark the vinegar and oil both are), and when the dressing separated\nbetween uses (and reshakes) it made a lovely "sunrise".
\nThe one variable that remains on my idea board is that though I\ndismissed Olive Oil as the base oil in theory I like the concept of\nusing a splash or more of olive brine (possibly in place of some of\nthe water content?), which occurred to me as an interesting nod to a\nDirty Martini. I've not actually tried this yet, though.
\n","date_published":"2022-01-05T00:00:00.000Z"},{"id":"https://blog.worldmaker.net/2021/10/20/future-day-reminder/","url":"https://blog.worldmaker.net/2021/10/20/future-day-reminder/","title":"Tomorrow is Future Day 2021 (Positive Sixth Annual)","content_html":"October 21st each year I like to order a pizza and a Pepsi from\nPizza Hut, watch all three Back to the Future films, and think about\n"The Future". I call it Future Day. It's a relatively simple holiday\nto celebrate every year, and I've celebrated it for decades. October\n21st, 2015 was the date that Doc takes Marty McFly and Jennifer to\nvisit their future. I've always counted the holiday from 2015, so this\nwill be the (Positive) Sixth Annual Future Day, even though I've celebrated it\nfor decades at this point. I even went so far as to post the idea to\nFacebook and invite guests to my place to hang out and marathon\nBack to the Future with me for a few years early in owning my current\nhome. I don't remember the exact years offhand, but that would have\nstarted sometime round the Negative Fourth Annual.
\nOrdering a pizza and a Pepsi from Pizza Hut is easy enough to do. I\ndeeply associate these specific foods/drinks with the holiday for many\nreasons. It was sometimes the food pairing of choice when watching the\nfilms on VHS as a kid. It's also the product placement meal inside of\nBack to the Future Part II, though I still don't have a\nBlack & Decker Food Rehydrator with which to reheat my dehydrated pizzas.\n(Just the regular delivery of hot pizzas in cardboard boxes.)
\nWatching all three Back to the Future films is definitely a marathon\nand not a sprint, so it's not quite as easy as it sounds. The few years I invited\nguests over, very few guests made it all the way through\nBack to the Future Part III. Sometimes that's just because fewer people\nappreciate Part III. (In my opinion you can't watch Part II\nwithout watching Part III. That's only watching half the movie.)\nOften it's because the 21st tends to fall on a weeknight (it was a\nWednesday in 2015, it's a Thursday in 2021) and people couldn't stay\nup that late and it was tough to start earlier.
\nThinking about "The Future" is the part that's supposed to be hard.
\nThe movies spark some obvious conversations, especially now that we\nare in positive annual celebrations. Obviously we didn't get\nhoverboards nor hover car conversions (though as\nBack to the Future Part II is quick to point out such things don't solve traffic, they\njust make it worse). But there's subtle things it got quite right like\nthe cyclical return of '80s nostalgia in 2015 and interesting\npredictions about smartphone tech though it generally got the form\nfactor wrong (glasses and visors rather than hand tablets). Compared\nto the so called "curse" of the film 2001,\nBack to the Future Part II did a much better job picking brands that remained (mostly)\nrelevant/existing into the real 2015. Black & Decker still existed in\n2015 though much less prominent in American life with the\ndismantlement of Sears. It was also rebranded Black+Decker in 2014,\nso the ampersand on the Rehydrator would have been an interesting throwback\nor an older model than 2015. (Because ampersands are too polite/old fashioned\nfor appliances or something? I don't understand rebrands sometimes.)\nJVC was sold by Panasonic and merged with Kenwood in 2008 and the combined company\nJVCKenwood moved to focusing on the Kenwood brand name in America and\nit was relatively unlikely to buy JVC branded stuff in 2015 other than\nfor nostalgia, mostly. (Possibly explained by Marty working for a\nJapanese conglomerate.)
\nBut something that the Back to the Future movies do particularly well,\nI think, in the "got subtle things quite right" department is the\nrespect for what today we often refer to as "Gibson's Law", named\ntoday for sci-fi author and the ur-provocateur of the cyberpunk genre\nWilliam Gibson is the observation/realization that "the future is\nalready here, it is just unevenly distributed". It's not a unique\nobservation, William Gibson helped give it a better name. In\nfurnishing and set designing the Hill Valley of the 1950s the Back to\nthe Future filmmakers realized they needed to mix in 1920s/1930s cars\nand furniture and architecture and in general span several decades of\nbrands and fashions and building designs to make the town feel real. A\nlot of that same eye was applied to the Hill Valley of 2015: most of\nthe bones are the same as 1950s (and the decrepit no one is downtown\nin the town square much any more 1980s Hill Valley) of course, but\nthey also applied changes they were already seeing in the early 1990s\nwhen they were filming and things like '80s nostalgia cafe both made\nit easier for them to dress sets, but also fit exactly the sort of\nthing that really happens within the fabric of cities. The antique\nshop selling a "classic" Dustbuster (another Black+Decker brand that still exists,\nthough generally surpassed by "fun" modern brands like "Shark hand vaccuum"),\nand the alleyway full of trashed Laserdiscs their own similar\nstatements.
\nThings don't just "light switch on/off" into a new state: progress is\ngradual and spread thinly across early adopters, upper classes, and variable adoption\ncurves. The future is already here, it is just unevenly distributed.
\nContemplating Gibson's Law on Future Day I find a useful\nexercise/reminder. I appreciate that it is hard. I want to appreciate\nall the little and big things we take for granted "living in\nthis future" and all the little and big things we will likely take for\ngranted tomorrow in whatever that future may bring. (Gibson's Law\nwould remind us we probably even know what that is/will be: it's\nlikely already out there in some rich person's hands right now. What\ndo you think they are doing with it?)
\nGibson's Law reminds us that "The Future" doesn't really just shock us and\nappear all of a sudden: it's a lot more\nlike the oft-mentioned boiling frog analogy, because it just creeps up\non us all slowly over time as it's mostly already here, it just may\nnot be distributed or only thinly distributed to us just yet. (Whether\nas the boiling frogs in this analogy this is healthy, is a deep and\nlong question, and arguably a key question to a lot of cyberpunk\nwriting.)
\nThe last couple of years because of COVID we've all heard and used and\ngroaned at and then tried to reclaim and then tried to dustbin and\nthen had to pick back up the term "the new normal". Whatever stage of\ngrief, acceptance, and/or disdain you find yourself with that phrase right\nnow, that phrase itself is an embodiment of the hard parts of Future\nDay. What is the new normal that has snuck and whelmed its way into our lives?\nWhat do we want it to be? What do we recognize we have no way to control\nabout it? How do we control whatwe do have access to for the better? How\ndo we look forward to it with optimism rather than fear?
\nI made up this silly holiday because I loved the Back to the Future\nmovies and as an annual excuse to put my rewatch marathon on the\ncalendar, on an interesting date that's mentioned in the movie, and on\nthe sort of mid/late-Fall day (weeknight aside) where curling up with\na pizza and watching three movies back to back feels like it makes a\nlot of sense. Yet it is years especially like this one, the second\nFuture Day after March 2020 and the multiple "new normals"–creating\npandemic that the hard challenge I gave myself to make the personal\nholiday mean something seems ever more crucial, ever subtly harder,\nand I suppose a lot more meaningful.
\nIf you get a chance, maybe grab a pizza and watch Back to the Future\ntomorrow? At least contemplate "The Future" and how it is already here?
\n","date_published":"2021-10-20T00:00:00.000Z"}]}