rudasn

Nice, I've been doing the same for the past week building on an old prototype I made. Agent takes up the task, completes it and provides a video of the functionality in the Pr. It then goes on and writes docs for it along with a more polished how-to tutorial with screenshots and video. Definitely stealing some of your stuff as well, yours look much better! Thanks :)

Managed on-prem perhaps? Setup a server at their office.

I have a hub and spoke wireguard nerwork that has been working somewhat perfectly for years, but there always are a couple of servers that just dont want to play nice. They connect to the hub, all good, and after a few minutes/hrs connection drops and handshakes fail. Using wireguard-go on docker (older linux machines) for all of them. Its a pain.

Someone quoted Idiocracy here the other day. "But it's hot electrolytes!"

Thanks:)

Hi Philip!

We develop one or more apps that we deploy on-prem. An app for us is a git repo with a docker compose file. On-prem is either a Linux server or a Linux vm that we have ssh access to (normally via Wireguard vpn).

For app updates, we use ansible to ssh into machines, run pre-deployment scripts, pull git repo and docker images, restart containers and run post-deployment scripts.

It could be better, but it works for us.

The biggest bottleneck we have now is communication with customers, scheduling of updates, letting them know of breaking changes or new features, that kind of stuff.

The apps are provided "fully managed". They dont know and don't care about the details I just described, but they do need assurances that everything is done "properly".

What we think would help us a lot is a way to easily let them know of new releases of any apps they have installed, let them read release notes, docs, and be able to either deploy on-demand or schedule a deployment at a certain time.

Although having fewer things for us to do is nice, what is crucial is to oversee deployments and make sure they are successful (and intervene if not).

Is distr for us?

Why not have two blog posts, one technical and one informative/tl;dr style that links back to the technical one (or includes specific excerpts)?

More like giving formula for free to new mothers to begin with, and when they wouldn't produce their own (as there was no "demand") they would later need to buy more formula.

(250 miles is about 400km and 3350 ft is about 1km)

There was a stackoverflow question (IIRC) long ago on how to disable a mobile phone's camera shutter sound, and the answer was to record the sound, inverse it and play it when the camera is activated so that the two sounds cancel each other out. Not sure if it worked though, or if it helps in your case, as precise timing is needed for this to work.

"Who is hiring" threads might be helpful, as others have said.

I'm also available for contract work, check my profile for relevant links and contact info :)

Off topic, but it's threads like these that keep me on HN. Gold :)

Ok so this looks like something I would use for an app we're deploying on-prem. I'm thinking it would make new deployments/releases a bit easier if we could "advertise" upcoming features/versions and allow users to leave feedback, express their interest, or at minimum just let them know what's coming.

My questions are, can I use this without embedding your js, does it support vanilla js frontends, and how easy it is for marketing folks to build and maintain your newspage (eg starting from release notes in markdown).

I think answering these kind of questions in an FAQ on your landing page would help. I could get the gist of your offering by scrolling but no real "aha!" moment. Too much text for not enough info. (For me at least).

Also, really glad your site works without js enabled, bonus points from me!:)