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.

https://alphieui.com/docs responds with a 404

"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!:)

Super cool and congrats for getting it done. You should be proud, even just for persisting all these years.

Also, I'm surprised "All your base are belong to us!" hasn't been submitted yet!

Cool, I've been working on similar my self. Not released yet, haven't had the time recently.

Curious as to why you store the data in the database in b64 as opposed to files on disk. What's the reasoning for that? Doesn't it make storage/backups/etc more complicated?

Not an expert myself, I opted for in browser encryption, in chunks, so as to avoid memory limitations (at least in some browsers, not FF yet), and in browser gzip so as to keep file size down and speed things up.

I find your niche quite interesting (journalists, whistleblowers) but given the high stakes of that perhaps an open source or more collaborative approach would be easier to promote.

Another idea I've tried out but not pursued, is some sort of browser extension/addon (I used nwjs, similar to electron), that offers client side encryption for any site (form field really). So you'd only post encrypted stuff to whatever service (email, reddit, hn, whatever) and only anyone with the key would get to read it (well, assuming they have the key and the same extension). Just throwing the idea out there, I'm sure others have thought about something along those lines before. The details to get it right are tricky (UX wise), but for your target audience it may be well worth the extra work.

Keep it up!:)

Chrome with JS disabled works good enough for me on mobile. It's also easy to whitelist specific sites. But mostly, if I get a blank page I just go back.

I have two!

One is a webapp I wrote almost 20 years ago for my dad and it's still being used today. It runs on IIS and built with asp classic and vanilla html/css/js (no frameworks back then). They use it to track orders and invoices to suppliers/vendors and ensure what they receive is what they ordered.

The other, an electron-type app that saves people hundreds of hours per month by letting them bypass some bad UIs and interact with external services directly. It's been running for 6 years, only had to make very few updates, and it's the one thing I don't need monitoring for - not only it's been quite stable, I get called immediately if it breaks (eg when external services change their endpoints).

Great feedback thanks! Will definitely consider this.

Ephemeral, client-side encrypted sharing of files, text, html, and forms.

Just prototyping at the moment, but the goal is to allow users to not only share files (even big ones) but also forms, like Google forms, but encrypted and one time only (read once).

The use case I have in mind is allowing businesses to create GDPR forms (with private info, consent, etc), share unique urls with specific customers, and once the data is received by the business delete it from the server.

This could be useful to businesses that don't have a customer-facing portal, but have to deal with PII and the customer needs to consent and verify the data and what it's used for.

The data is encrypted client side (web crypto) and the password either shared in the url (in the hash fragment, also encrypted by a key stored on the server) or by other means (eg. could be the recipient's dob or id number or some other previously shared or known value).

Still trying to figure out the details, use cases, business value but the core backend is done so is the client-side crypto stuff. I managed to get chunked AES-GCM working so that it doesn't load the whole file in memory in order to encrypt it, it does that in chunks of let's say 2MB. Chrome also has chunked requests (in addition to responses) for sending the file to the server, but would probably need to come up with some other mechanism to get that working on other browsers (like send the chunks in multiple requests and append to a single file on the server, but that adds more complexity so I'm still working it out).

Build the image on the deployment server? Why not build somewhere else once and save time during deployments?

I'm most familiar with on-prem deployments and quickly realised that it's much faster to build once, push to registry (eg github) and docker compose pull during deployments.

Yeah. I'm curious what George Carlin and Gil Scott Heron would have to say about all these.

Yeah, not a big deal but completely useless nonetheless as you would never really query your table for just the one decimal column (eg the price) but a couple more (eg the category and the price) so you'd have a multi-column index on those columns. The index on just the price column never gets used.

I bet you haven't seen indeces on decimals though! Fun times :)

Have you looked into browser-side gzip stream, file system api, and service workers? Maybe your "edge" could be end-users.

There was also this guy, don't remember his name, whom you could email your questions/issues etc, reply with great detail and post the discussion on his website for others to learn from. Like a one on one precursor to stackoverflow.

I remember email him and asking about why my photo gallery didn't work when I tried to save the "currently selected image" as a cookie. He replied and explained to me that cookies contain string values and that you can't save a reference to a DOM element as a cookie. So, cookie = document.getElementById('image0') will not work, but cookie = 'image0' will :)

I had very similar concerns when I was building my sideproject.

But I was determined to ship, so once the code was deployable (the bear minimum, nginx with ssl setup) I pushed to my VPS and posted a link on HN. It was late Sunday night, was very tired, but just wanted to get real user feedback. But I also knew the chances of anyone seeing the link and actually giving feedback were slim, so I tried not to worry too much about it. The important bit was taking the first step and shipping something. Everything else follows from that.

So, my advice is to put it out there and invite people that could give you helpful feedback. Avoid toxic communities as that will only add to the stress.

Best of luck!

Oh this is more interesting than I thought! It definitely has some (early days) technoratti feel to it.

Hey! Thanks for maintaining chartjs :)