Llm-buddy is an “Emacs package that watches your recent buffer edits and asks an LLM to review them. When it finds something worth pointing out, it can add a short inline note in the relevant buffer or show a message in a popup buffer (it usually does the former).
The goal is lightweight feedback while you work: typos, logic mistakes, questionable edits, or prose issues that a normal compiler, linter, or spell checker may not catch.”
A while ago I saw a promising Clojure project stepwise [0] which sounds pretty close to what you're describing. It not only allows you to define steps in code, but also implements cool stuff like ability to write conditions, error statuses and resources in a much-less verbose EDN instead of JSON. It also supports code reloading and offloading large payloads to S3.
I’ve recently started an open-source self-hosted data platform (https://github.com/kot-behemoth/kitsunadata) with Dokku being a great initial deployment mode. It’s mature, simple to get started and has tons of docs / tutorials.
Obsidian.nvim (https://github.com/epwalsh/obsidian.nvim) has been working really well for me. I use Obsidian mobile app (it’s not the best in this space, but still very good). And on my laptop, I’ve got neovim - getting to the daily note is one key combo. It’s also super fast and syncs using Obisidan Sync (or you can do your own).
> Before I start working on a feature, I simulate how it's going to work in my head and try to identify all the hurdles and alternatives; sometimes several levels down in the hypothetical component/module hierarchy. I do brainstorms, draw diagrams and make lists of pros-and-cons. I use as many visual aids as I can get.
Remarkably, this is how 37Signal's Shape Up (https://basecamp.com/shapeup) encourages defining feature work prior to building.
In particular, the concepts of Rabbit Hole (as explored with senior developers prior to coding), Breadboarding and Fat Marker Sketches (having a high-level but end-to-end map of the feature) are almost identical to what you're describing.
I found this approach both intuitive in my personal development work, and as a tech lead for lean teams. Funnily, quite a few people really struggle with the concept of "thinking through the feature end-to-end", and not just "let's start with one piece and then figure it out". It's great to do development in small chunks with unknowns, but we still need to know what we are all trying to achieve!
(not affiliated with Shape Up / Basecamp, I just feel Jira leads to hugely suboptimal and waterfall-y processes).
I use direnv myself, and it's great. However, for anyone trying it out I'd caution that it doesn't play well with conda - the Python package management system (see this open issue https://github.com/direnv/direnv/issues/326). It can be a dealbreaker for some.
XTDB (https://xtdb.com) while is not directly for Postgres is at least not reliant on devs knowing Clojure. It's very close to Datomic in terms of approach. They expose SQL, Java, HTTP APIs.
Highly recommend LogSeq (https://logseq.com). It started out as very Roam-inspired, but with focus on actually supporting both Org and Md. It’s quite GUI-heavy with good shortcuts support.
Juxt were very vocal about making Crux available beyond Clojure (can't find the exact quote right now, unfortunately). Perhaps the last time you checked it, any non-Clojure support was still WIP. However, since then they definitely have Java API available (Javadoc here: https://crux-doc.s3.eu-west-2.amazonaws.com/crux-javadoc/20....), as well as REST API (see https://opencrux.com/docs#restapi).
Have you heard about Basecamp's solution to this, Hill Charts (https://basecamp.com/features/hill-charts)? It's definitely not an 'enterprise' solution, but I find its simplicity a really good map for the _true_ workflow of developers. That is to say, it's abstract and simple enough to use for devs, while meanigful enough for managers to gauge progress.
Plus, their writeup on imagined vs discovered tasks and how Jira et al give false sense of control when creating tickets upfront is also illuminating: https://basecamp.com/shapeup/3.4-chapter-12
Have you had a look at Joplin (https://joplinapp.org)? It's mature, open-source, has e2e encryption, is markdown-backed, and supports syncing via Dropbox. Also supports attachments.
I actually switched to it from org-mode, but still edit the notes in emacs because of keymap (via "Edit in external editor" feature).
I actually am in the same position as you - my main text editor is Emacs (well, doom-emacs). After trying out Bear, Standard Notes etc, I couldn't give up editing plain md files that easily. Org-mode is amazing, but the attachments story is just not solved, especially once you throw mobile into the mix.
I've settled on Joplin, as it's the only serious note-taking app that allows for Emacs-friendly workflow by simply using external editor. I just set the external editor command to be 'emacsclient -c'. Now, when I'm editing a note, I just press Cmd-e, and get Emacs for editing - just for that note. Once I finished editing, it's "C-c k", and Emacs closes and I'm back in Joplin.
I actually set Joplin's layout to always show the rendered md, so that it's basically a pretty front-end for my Emacs-powered editing workflow. Beyond that, syncing and attachments are what makes it more or less perfect second brain system for me.
My current client is a sophisticated AI/ML startup/consultancy, Faculty (https://faculty.ai). They have extensive experience in a variety of areas, and do some cutting-edge stuff. If you're intested, either ping me (email in the profile) and I can connect, or use the website.
Llm-buddy is an “Emacs package that watches your recent buffer edits and asks an LLM to review them. When it finds something worth pointing out, it can add a short inline note in the relevant buffer or show a message in a popup buffer (it usually does the former).
The goal is lightweight feedback while you work: typos, logic mistakes, questionable edits, or prose issues that a normal compiler, linter, or spell checker may not catch.”