u/amiorin

Hi all, most of us don't like to write Terraform. Now there is an alternative. A skill to create a package skill and a skill to submit it to a catalog. There are already some package skills for Airflow and ClickHouse. I hope more will be shared in the future.

A package skill is deterministic code to reconcile your infrastructure with desired state. Under the hood it can run anything like Terraform, Ansible, or Kubectl.

The license is MIT.

https://www.getcolors.ai/skills

I have renamed BigConfig to Colors. The goal is still to fix DevOps but it was such big improvement over the original version that I have decided to change name. The gist is that you give your agent new skills to create a personal Paas, a K8s cluster, or any piece of infrastructure. The desired state is in YML and every package contains code in Clojure, Python, and TypeScript to reconcile your infrastructure with the desired state. Every codebase has also a SKILL.md so that you can delegate everything to your agent. Any feedback is welcome.

https://www.getcolors.ai

Hi all!

We are using Terraform incorrectly, and the same can be said for almost all DevOps CLI tools. These tools should only call APIs and implement the lifecycle of a resource. The problems started when we decided to give them more responsibilities, such as managing dependency graphs, execution order, and parallelism. Now we are stuck because they no longer compose well. Our workarounds have become brittle scripts used to glue together Terraform, Kubectl, and Ansible.

The solution is to keep the dependency graph in code:

• One graph for any tool: Standardize the workflow across your entire stack.
• Multiple graphs for actions beyond just create and delete: Easily handle workflows like backups, validation, and cost analysis.
• Aspect-Oriented Programming (AOP): Change behavior without changing the core infrastructure code. For example, a Terraform Backend is just a slight behavioral shift, a dry-run is just an "around" advice, and multi-cloud provisioning is just a "before" advice.

I have written my own implementation in Python, TypeScript, and Clojure, but you can easily ask an AI agent to build your own library in five minutes and finally take your infrastructure to the next level.

Just for reference, please build your own library in your favorite language.

https://github.com/amiorin/red (TypeScript)

https://github.com/amiorin/green (Clojure)

https://github.com/amiorin/blue (Python)

Just stumbled upon this and thought the r/emacs community would find it interesting: Helix is working on a plugin system based on Scheme!

As a dedicated Evil-mode user, I’m already a big fan of combining modal editing with the unmatched extensibility of a Lisp environment. Helix defaults to a Kakoune-style (selection-first) modal paradigm, but with this new Scheme plugin system, there is already a classic Vim emulation layer being implemented. Since that covers modal editing, maybe it's only a matter of time before someone uses Scheme to build out a full Emacs emulation layer too.

To be clear, Helix is strictly a terminal/TUI-only text editor. It obviously can't compete with the massive, unified application ecosystem of GUI Emacs (there's no native rendering for PDF view, web browsing, inline graphics, etc.).

I should note that this is all still under active development, so I'm not aware of any stable terminal plugins available to try just yet.

Here is the video covering it: https://www.youtube.com/watch?v=YDYTYktziyI

What do you all think? Anyone tempted to give it a spin once the ecosystem matures, or are we staying firmly comfy in our init.el?