I want a bidirectional SaaS <=> YAML/JSON adapter. So that I can push and pull our CRM (and other SaaS utilities like project management) into a common (schematized) YAML format.
The YAML then can be analyzed and modified using LLMs and/or stored in git.
And then use the bidirectional sync to reconcile conflicts and push.
So I can do work processes on the console, and still collaborate with people who want the native web UI.
Thinking of Terraform, you have data blocks that can grab data from an external source. Still trying to grok what would be a convenient way of doing something like this - whether that gets generated to DSL, or if data pulled in dynamically as you build the org graph...
Having your plain-text workspace as a unified structural source where you pull in data from external systems would be potentially powerful.
There's a sync engine behind it so the UX is extremely responsive.
I’ve done something like what you’re talking about before for a CMDB, though it was one way YAML -> DB sync. Many to many relationships were a pain to view, there’s not a great way to put them in YAML that makes them easy to read. Can’t embed them because then you have multiple copies and which one is the real one. References suck because you can’t see the relationship and the related objects at once.
The real killer is permissions, though. Your sync tool basically has to have admin privileges, which means permissions have to be checked at merge time, and then you’re rebuilding the entire permissions flow as a git hook.
SQL with RLS is capable of implementing permissions in a way that works for both API access and direct SQL access. I get the feeling few companies do it, but they could.
While mine is functional, yours looks A LOT more refined, so I think I will play around with it and see if I can't adapt it to my needs.
I try to work in the terminal as much as I can since that's where I'm most comfortable, but when it comes to business software like CRMs, HRMs or ERPs, especially geared toward smaller shops, the selection for terminal-based options is severely lacking.
If you can export to structured data such as JSON, I guess Typst would be a perfect fit for that job.
gnu and emacs already have a long history of cli and text friendly solutions that LLM dev agents can easily use and are trained on.
Or for structured data, just use a database. Dev agents can work with SQL just fine.
The first person that makes emacs for the hoi polloi will suck up all the emacs people as well just based on interop frustrations.
I still can't believe that after seeing how slack just released irc for grandma's and pointy haired bosses that no one has done the same for a sensible defaults for normies emacs.
I live in the terminal, but most people in my company, including developers rather stay away from it
(1) Command lines lack the discoverability element of GUIs (and TUIs), where the available choices are typically laid out in front of you. Just look at the command "firm -c list contact" in the screenshot in the linked readme - no doubt it's sensible, but you wouldn't just type it in out of nowhere. You could argue that good docs fix this, but they'll never be a substitute. (Silly analogy: imagine if your toaster had buttons just labelled "1", "2", "3" and you had to refer to the manual for which meant toast, defrost, extra browning.)
(2) Command lines lack the visual persistence of the data you're operating on (like a list of files in a directory, or project/people data like in this program). If you rename a file and you then re-run ls and now everything appears in a slightly different place on the screen (because the previous listing had shifted up when you ran "mv") it's visually jarring in a way that just operating directly on the data isn't. Not-silly analogy: it's like how no-one today would dream of operating on a text file using a pure line editor like ed. (Even command-based editors like vim persist the file data in the main visual area.)
Command lines are much better than GUIs/TUIs for some applications, for example when called from a script, or where you might need to compose a complex command and then tweak and re-run it (in fairness, that might apply to OP's project). But I think techies sometimes get a bit carried away. GUIs are sometimes a legitimately better choice.
Allows for a GUI for tasks that need that better context or hand holding. But then the CLI is there when there is a workflow the GUI doesn't support comes up. Bonus of scripting being possible with the CLI too.
Challenges this approach has is that you have to have a test suite that exercises both workflows or due diligence to make sure they both work as development continues.
Also not all programs can be done acceptably with a CLI. Real time 3d games are an easy example of a GUI only task.
1. It tends to be bloated, with developers slapping framework upon framework, creating a mess of background wiring that is prone to a dictionary's worth of issues that will either frustrate the user or confound the person maintaining it.
2. UX Designers approach their jobs incorrectly; they assume they are smarter than the user. Interestingly, this might actually be true on paper in most cases, but the practical reality is that the user needs to do things the user's way, not the way the the developer wants them to.
If we could find ways to smooth those two glaring issues, I posit that we'd see a lot of problems with productivity and workflow melt away. Caveat; I'm not a software developer, so I'm sure anyone who is thinks I'm speaking out of school right now. Fact is, I've worked in a few different industries over 40 years, and one of the biggest thorns always seems to boil down to the software not being quite right for the team/application, so workarounds have to be invented, adding layers of complexity on what is already a decidedly fragile system.
To me, it’s obvious that if a certain command feels cumbersome (e.g., (1)), you can just create an alias, script, or panel to make it behave exactly how you want. In contrast, a GUI usually forces you to use the functionality as it was envisioned by the product team that designed it.
Ultimately, GUIs target the average user, providing a good experience on average across all users.
With terminal apps, if you are patient and willing to learn how to customize your shell, you can make an excellent environment which would offer a huge boost of productivity
- CLIs are powerful but hard, basically an exercise in mnemonics.
- GUIs are much friendlier, and can be faster than CLIs for certain use cases. While complex and bloated, they have their use cases to shine.
- TUIs are basically less expressive GUIs, since they're limited to text, but you must go out of your way to make them bloated and slow; they usually are very snappy.
All have their best and worst scenarios, no need to argue which is better. Use what fits best with your workflow, no size fits all.
People who lionize the terminal are silly, it's objectively bad and the fact we use it at all is just the inertia of TTY.
Trying to put GUIs in terminal, all this stuff, it's a hack, a sign of failure to make progress.
In an alternate universe Emacs wouldn't be culturally anti-human and we'd have a data first gui instead of app siloing. Some Emacs custom setups are the fucking future, context switching, everything is so perfect, but because the interop is so bad you can't use it in your day job.
But most OSS OS devs have spent all their time focused on the system part and not the operating part.
Human factors and human interfaces are still mostly ignored, and that's just from a sole user perspective, most developers of UI don't treat the networked/relational aspect as a first class UX issue for an OS.
And that's partly a failure of imagination, a failure of loving people as much as tech and also because distributed collaboration is fucking hard and most people just rewalk existing paths.
Maybe LORO is the only truly interesting open source project right now, but Ai can't write those algorithms so even their implementation is under explored.
My guess is that the console is a much better and natural UI because it goes in one direction and is less confusing and productive for humans.
In the end we seems to move back to it through the chatbot paradigm, because it is in the end a console...
- Schemas and relationships live in models.py, actual data is persisted in Sqlite - I can dump to JSON or XML with Django utils for LLMs - Query engine can simplify reuse Django syntax, like `Firm.objects.get(owner_name__like="john", date__gt=2015)`, fetch related names, aggregate subqueries - Format as tables
But ... why invent a new file format? Why not just make in JSON, so it is easier to integrate in other toolchains (e.g. having a python script add customers based on external APIs without having to write your own output generator)?
But each of formats seemed nice at first.
So I understand that sometimes it’s easier to invent a new format. But compatibility with other formats can definitely be a problem lately.
My question is: how does the proposed system handle multiple editors working on the same text file?
https://github.com/42futures/firm/blob/31fc084b7c7855bef9694...
I do wonder how much value all this work adds compared to having e.g. JSONC files with schemas. (Or HCL-syntax-for-JSON to visually match this work and then JSON schemas.)
I love little CLI tools for managing productivity
Which is well timed because I've been increasingly leaning more into Tana but also being like "it would really suck if this tool goes away". Having something that has the same ergonomics of Tana but is more open is really interesting.
1. Appeal to some of the crowd here 2. Potentially run in the background as meta layer for llm ( as crazy as that sounds, the annoying reality is that it is happening already, but in the most annoying way possible 'worst of all worlds' version )
For our Django development agent, we use a similar structured approach where each feature is broken into steps. Found that explicit dependencies (vs implicit) prevented a lot of circular issues.
Curious about your experience!
Reminds me also a bit of
It seems Windows Defender flags the zip download as a trojan. Likely false positive since scans on the unzipped exe (Defender and virustotal) come back clean.
I'd suggest providing a way to disable the builtin schemas in case someone wants to use it for more tech things as opposed to business things.
I’d love to simply map all the relationships between stock, assets, tools like invoicing, APIs all in a place like this.
But I have to agree I think CLI alone would result in it being usable by only me.
EDIT: just wanted to add I’m interested in where this project goes.
The project is structured as libraries such that you could build an editor separately, but it's not something that has taken priority for me (as the only user, so far).
Thinking about an LLM use case, not needing a query language should remove translation risk I'd assume?
To be clear, I'm trialing this out in my own small business. Whether it's ergonomic enough to add value and whether it's scalable, I don't know yet. So far, so good, though.
