Does this project have to be an endless single player game?

TL;DR

I'm hoping for any combination of the following:

1. People who want to see the Peace framework developed to viable-existence, to fund my existence.
2. Someone to take over and continue development of the Peace project.
3. Someone who finds the ✒️ dot_ix side-side project fun or fulfilling, to take over it / develop layout-rs as a replacement for GraphViz dot, and switch to encre-css for styling.

1. Motivation

Each time I provide or use a tool that manages software infrastructure, there is always something lacking. Pragmatically, an organisation whose business is to ship a product, cannot invest disproportional resource on improving tools beyond "it's efficient enough".

However, one of my desires is to have ridiculously good tools¹, because they can:

• switch dangerous buttons for safe ones
• simplify overwhelming information into someting understandable
• turn fear of mistakes into fun of learning

¹ ridiculous enough for a dreary-eyed 🦹 engineer to get excited

2. Demo

envman is a tool built using the Peace framework that:

1. Downloads a file from Github.
2. Creates some AWS resources.
3. Uploads the file to AWS.

The videos below show the beginnings of "ridiculously good".

2.1. Like Git, But With Infrastructure

Regardless of the process, a really nice tool would be able to do the following:

1. Tell me what the current state of a system is.
2. Tell me what will happen, if I were to run the automation.
3. Don't create twice the resources when I run it twice.
4. Don't clutter my screen with irrelevant detail.
5. Do tell me the detail, when I care².
6. Make sure everything is cleaned up.

These capabilities (among others) allow me to do what I want without needing to worry about making mistakes, or forgetting to clean up resources.

² Not shown, but detailed state is stored

2.2. Interruptible

If I change my mind, let me stop the process (safely!), change a parameter, and resume the process.

And don't throw away all the work that was done before -- determine what's there, and only change the parts that need changing.

2.3. Profiles (like Branches)

Sometimes I work with multiple environments, so let me switch between them.

And let me compare the state of two environments -- perhaps one is a replica of the other, so show me what's changed.

2.4. Communicate Clearly, Recover Cleanly

When something goes wrong, clearly showing which step went wrong (the red one!) and how to recover saves both time and effort in continuing in the flow.

Bonus points for recovering by simply pressing the "go" button again.

2.5. Visual

🚧 work-in-progress feature

Not everyone works on the command line, and even for the software-inclined, being able to see what each step of the process does, without running the automation, helps build understanding faster than simply seeing a list of steps.

Having real-time visibility of automation execution makes it clear which resources are interacting.

If there is an error, appropriate styling immediately draws attention to the resources are involved in the error.

Skip ahead to 5. Imagination if you don't care how it's built.

3. Distributing Effort

To build tools of this calibre everywhere, practically one would have to separate:

1. Logic common to items managed by automation (e.g. save / load / display information).
2. Logic to manage a particular item (e.g. download a file).
3. Parameters / values used in the automation (e.g. use this particular URL).
4. The combining of these parts (organisation specific process / intellectual property).

That way the overall goodness can be provided by the framework, automation logic is extendable and shareable, and everyone gets to keep their secrets.

source

Using a general purpose programming language to define these parts means:

• Tooling from that language is available to adhere to best practices.
• The standard packaging system handles publishing and distribution.

3.1 Incentive

Peace is intended to be low-friction to uptake³ -- developers who use Peace should not need to write much additional code than what they would have if they were writing basic automation logic.

It should be a matter of:

1. Creating types for the parameters and state of the item managed by automation.
2. Fitting the automation logic into the Item trait.
3. Instead of calling each automation step's function directly, putting that into a graph structure called a Flow.
4. Calling the appropriate Peace Cmd with the defined Flow.

which should be similar effort to writing a tool without the Peace framework.

For the web diagram, "item interactions" need to be defined, which Peace will combine with other Items to create a diagram that contains all items.

In practice, when switching from "just code a quick tool" to "write it using the Peace framework", anecdotally it's switching from 1 unit of effort producing 1 unit of value, to 1.5 units of effort producing 4 units of value.

³ this statement may not be well-fitting since it's written in Rust, but if you were to have written a small automation tool in Rust, it should be nearly identical effort, for significantly more value delivered

4. Side-Side Projects

source

In building this project, besides restarting twice, a number of side, side projects were created. The ones that are likely useful on their own are:

• ✒️ dot_ix: Interactive dot graphs (diagrams).
• 🛑 interruptible: Stops a future producer or stream from producing values when interrupted.
• 🧬 fn_graph: Runs interdependent logic concurrently, starting each function when predecessors have completed.
• 🗂️ type_reg: Serializable map of any type.
• 🗂️ resman: Runtime managed resource borrowing.

So in order for Peace to fulfill the "ridiculously good" notion, many side quests just had to be done.

4.1 Dot IX

dot_ix in particular has its own client side application to create SVG diagrams from structured input. I frequently use this to create various technical diagrams.

My wishlist for dot_ix:

1. For diagram generation, use layout-rs to generate the SVG in-process instead of delegating to a WASM-compiled GraphViz dot.

   Besides performance gains and portability, it may be possible to rasterize the SVG and render a diagram in the terminal.

   However, layout-rs only supports basic text labels, so a lot more development effort needs to be poured into it to unlock this possibility.

2. For styling, instead of using tailwindcss's non-production CDN JS and hacky CSS extraction, switch to encre-css.

   Perhaps update encre-css to synchronize with Tailwind CSS 4.0 as well.

It's too far down the priority list for myself to get to in the foreseeable future, but if someone were to do them I'll be grateful.

5. Imagination

There are nice things I imagined being able to do:

1. Visually select the items in the process that I want to run, then press go -- subset execution, with an interactive UI over it.
2. Selecting a node on the web diagram opens a panel with detailed information about that item.
3. Undo the last execution / make the environment as it was at this particular point.

Reaching that level of simplicity may take a few thousand additional hours of effort.

6. Summary

Chipping away at this for 5 years, it certainly feels too much for one person.

I had a plan to get this production ready and use it at work, but being on the screen for both work and home activities doesn't sit well.

So either this becomes what I work on full time (through sponsorship), or someone else who has the energy could take it and build upon what's there (and hopefully we share the same level of code-pedantry 🕵️).

Let me know (discord / email: mail@azriel.im).