i’ve been a big fan of Jujutsu (jj) since adopting it a few weeks ago. things i used to avoid with git like proper rebasing and focused commits become so much easier, in addition to the benefits of conflicts being easier to handle. the learning curve i thought was going to be grueling only took a couple days to get used to, and honestly interop with GitHub and my team’s particular workflow were the hard parts. so not only is it useful, powerful, and becoming more important to my workflow all the time, it’s a joy to use compared to git.

i guess honorable mention to zoxide, which has basically replaced cd for me since it does everything cd does but also keeps a small db of your most commonly visited directories so you can just do z Downloads or z my_project or whatever from any directory

deleted by creator

first, i’m biased. i’m a home row kind of guy. i live in the terminal.

Which of the preferences you mentioned discounts this project?

i’ll be direct: light weight dependencies. i understand why you’d use Electron to build a UI, but does an API tester need a UI as a first class feature? i think something like hurl shows it’s not necessary. i get that maybe it’s an accessibility problem (juniors and Java devs being afraid of the command line etc), but UIs are not composable. i could run hurl (or curl for that matter) via bash or nushell or Elisp or Rust or Powershell or JavaScript or GitHub Actions or as a k8s postDeploy… and, not to draw the ire of Lemmy armchair zealots, they’re not easily usable by agents. an 8B model on my Macbook could figure out hurl, no MCP or crazy preprompting required.

plus: user adoption. this is the self hosted community, so maybe not everyone here has the same concern, but i can’t just commit a bunch of exotic files to my shared repositories. Bruno was a tough adoption, even though it seems obvious to version control this stuff and it was the only real option at the time. now i’m tired of Bruno cuz it goes out of date cuz it’s not easily scriptable with our internal auth services because it runs everything in its bespoke UI. if they haven’t made a button for it, you can’t do it. that’s the problem with UI dev tools.

no shade, i understand some people would be totally lost if their IDE didn’t have a big green run button.

i’ve been looking for a silver bullet in this space. hurl[1] seems promising as well. i feel like Bruno has always been jank, and going 1.0 didn’t help. at work i’ve stuck to vibe coding my API test code with a stack of TOML configs, that way i get to reuse/test my client code as well.

what i want is something version controllable with lightweight dependencies that i can automate easily. i’m afraid that discounts this project. not going to ask my team to download Yet Another Electron API client UI. i’m hesitant to introduce hurl, which can at least be scripted.

1: https://hurl.dev/

lots of good reasons to spin up containers for development is my point, especially for an embedded system with exotic system dependencies (compared to Node.js, for example).

Home Assistant is a “simple app” that i have to open ports for.

does that mean they have a good reason? maybe not.

really? i mean, people have done it for friggin vanilla ass Node.js servers. Android projects can have weird dependencies that a container might help solve (NDK etc).

i’m not saying that it’s my preferred way to build, but that wasn’t the question.

yeah i get that.

generally most modern UIs are moving away from those reactive patterns (React, Svelte, etc) just cuz the composition can be optimized (Kotlin compiler plugin, shadow-DOM, etc), and a lot of people—myself included—find that declarative design easier to reason about. and yeah i guess i outed myself as an Android dev, but i can’t in good conscience recommend the node based Android XML UI lol (although that’s a different SDK).

anyway, not to yuck your yum. i played around with JavaFX back in the day but never made anything to speak of. i’ll have to check out more of your blog!

JavaFX with Kotlin

mad lad.

what makes you snub Compose UI?

honestly, i 100% do not miss GUIs that hopefully do what you want them to do or have options grayed out or don’t include all the available options etc etc

i do get burnout, and i suffer many of the same symptoms. but i have a solution that works for me: NixOS

ok it does sound like i gave you more homework, but hear me out:

• with NixOS and flakes you have a commit history for your lab services, all centralized in one place.
• this can include as much documentation as you want: inline comments, commit messages, living documents in your repository, whatever
• even services that only provide a Docker based solution can be encapsulated and run by Nix, including using an alternate runtime like podman or containerd
• (this one will hammer me with downvotes but i genuinely do think that:) you can use an LLM agent like GitHub Copilot to get you started, learn the Nix language and ecosystem, and create Nix modules for things that need to be wrapped. i’ve been a software engineer for 15 years; i’ve got nothing to prove when it comes to making a working system. what i want is a working system.

someone was asking for a GUI, so not going to be an ffmpeg expert. likely the LLM would recommend ffmpeg anyway. plus you would run YOLO (or maybe CLIP) locally; it has been running on Android phones since 2020 at least. a Jupyter notebook would also give a quick and dirty GUI to visualize and document the solution. plus “motion detection” is probably not the full story, and any video will probably have artifacting that means you’d have to tune the motion detection algorithm or end up with a bunch of garbage artifacts/false positives in the end. also, sounds like the user isn’t looking for something long-running like Frigate. if the user isn’t familiar with Python and wants to do something downstream like sort the outputs or whatever, an LLM would help with that.

sure, programmatically, it’s not a difficult problem, but like it or not it can be solved by someone without an advanced CS degree with an LLM precisely because the problem is easy. no easily ready solution exists, but that doesn’t mean it can’t be done. “just use ffmpeg” to someone like my dad who might have the know how to install Linux but isn’t a programmer isn’t exactly the simple advice it sounds like.

i’d vibe code something in Python for this tbh, but i have some expertise in this area already. you could even get some classification going with a YOLO model to help you narrow down the search. it won’t have a GUI unless you count Jupyter notebooks.

normally it’s for syncing across machines, but it is convenient for setting up new machines. i use chezmoi and Nix and some other tools to keep things in sync

i host my dotfiles on GitHub, but any cloud provider or self-hosted git instance will do. otherwise, rsync, scp, or a good old fashioned thumb drive

nice. simple and modular i like. i deal with far too many “one stop shops” at work to bring that home

we use Jenkins + a bespoke wrapper at work. thats left a bad taste in my mouth enough to avoid Jenkins altogether

this is my experience as well. we have a bespoke wrapper around Jenkins, and the more we can test locally the less time we have to spend waiting for the system to fail. it’s one of the reasons i’ve adopted just to script things locally as if it was CI.

heck yeah this is the review i was looking for 💯

you’re right. i just expected it to be an increase 😅

i honestly didn’t look that close, obviously haha

but yeah, i’ve been kinda looking for a reason to de-Microsoft my stuff

good lead. it’s just the one project for now, and to my surprise it’s actually a dependency for the ollama-rs project, so i feel somewhat obligated to keep it stable.