Ah...you're scratching at some scabs with this totally reasonable question.
We learned some tough lessons with media-chrome[1] and Mux Player, where we tried to just write web components. The React side of things was a bit of a thorn, so we created React shims that provided a more idiomatic React experience and rendered the web components...which was mostly fine, but created a new set of issues. The reason we chose web components was to not have to write framework-specific code, and then we found ourselves doing both anyway.
With VJS 10 I think we've landed on a pretty reasonable middle ground. The core library is "headless," and then the rendering layer sits on top of it. Benefit is true React components and nice web components.
I'm a little shocked that someone like 1Password hasn't released a vault access + approvals model. There are a lot of little menial tasks that I'd love for an agent to take care of ("book me a hair appointment next week when my calendar says I'm free"). Agent has access to a locally synced calendar and can see the existence of a password for the booking portal in my vault, asks to use it, I get a push notification and can approve.
These kinds of things aren't common enough for me to want to set up a programmatic policy, and are also low sensitivity enough that I don't mind giving access to complete the task. If it later asks to log into my bank, I decline.
I know the devil's in the details for how to actually do this well, but I would love if someone figured it out.
Big +1 to Pi[1]. The simplicity makes it really easy to extend yourself too, so at this point I have a pretty nice little setup that's very specific to my personal workflows. The monorepo for the project also has other nice utilities like a solid agent SDK. I also use other tools like Claude Code for "serious" work, but I do find myself reaching for Pi more consistently as I've gotten more confident with my setup.
generate_gazette.sh Calls OpenAI to generate "The Civ Chronicle" — an era-appropriate, unreliable wartime newspaper article for each turn.
For a long-running game like this, that's a pretty clever little twist to keep the group engaged. I have extremely low confidence I could convince enough friends to do it with me for long enough to get through a game, but this seems like such a fun idea.
This was a friends suggestion after I initially proposed something that exposed a bit too much detail. I wanted to show the diplomacy states and unit/city additions per player as a highlight on the home page, but we instead kept the raw files that generated those UI elements and fed them into OpenAI with the prompt and the Gazette was born.
You can read the code, but my suggestion on how to do this is to just ingest the save game files. They're super easy to work with, especially now we have the magic of LLMs.
In my case i'm creating various json files that describe game state, players, diplomacy, attendance, etc. Then i just throw that at the LLM and give it the goal of writing a newspaper article about where the game is at. The json files are incremental, so i'm not reading all the past versions on every turn. At the end of the current turn it just appends the current turn data to the json file, and then does the generation. These files are also what power the frontend UI, so it's all super lightweight and fast.
To make the graphs, you need to know state at the end of the current turn as the save files don't retain any history. So i store the most recent save file from each turn in order to achieve this.
It's been a journey of reverse engineering this game, but that's kind of the joy of it all.
We don't use New Relic or Datadog (and never have, afaik), so I'm not sure what post you could be referring to for those two? We have talked publicly about our Grafana use, though, and going from an in-house stack to their cloud product. Actual OP can probably hop in later with a better answer, but it was hitting rate limits on the logging agent, not the logging system.
I went down this path a bit the other night, curious what OP's answer is. My mental model was that they could be complimentary? Jido for agent lifecycle, supervision, state management, etc, LangChain for the LLM interactions, prompt chains, RAG, etc. Looks like you could do everything in Jido 2.0, but if you like/are familiar with LangChain it seems like they could work well together.
I haven't used Jido for anything yet, but it's one of those projects I check in on once a month or so. BEAM does seem like a perfect fit for an agent framework, but the ecosystem seeming limited has held me back from going too far down that path. Excited to see 2.0!
Just a heads up, some of your code samples seem to be having an issue with entity escaping.
This is an interesting writeup, albeit not quite what I was hoping for. I love Elixir and have been following Gleam for a while now, so I clicked through hoping this was talking about Gleam baking this into their ecosystem a bit better. I was a little disappointed to see it's ultimately talking about how to build a Gleam project and then use the resulting build ecosystem to create a binary (Gleam -> JS -> JS build tool, or Gleam -> escript -> elixir-burrito).
It would have been interesting to see some high level commentary from the author on the results of each one on top of the general workflow. Build time, binary size, startup time, whatever.
It's on the high side, but...honestly not absurd? "Party" implies one night rager, but the source says "in-person company event." That seems more like a multi-day company onsite to me, and the total bill per person there probably includes travel, accommodations, food on top of any overall event costs.
Bringing a remote employee to SF just to work out of an office for a few days can easily cost a few grand.
airfare: $500, 5 nights (sun -> thur) in a hotel, fully costed: $250, per-diem of $100 6 days (fri is a travel day) is already $2350. If you rent a place that thousands can show up you'll be in for at least $5k.
We learned some tough lessons with media-chrome[1] and Mux Player, where we tried to just write web components. The React side of things was a bit of a thorn, so we created React shims that provided a more idiomatic React experience and rendered the web components...which was mostly fine, but created a new set of issues. The reason we chose web components was to not have to write framework-specific code, and then we found ourselves doing both anyway.
With VJS 10 I think we've landed on a pretty reasonable middle ground. The core library is "headless," and then the rendering layer sits on top of it. Benefit is true React components and nice web components.
[1] https://github.com/muxinc/media-chrome
reply