rudasn

No db on the receiver and log-based storage on the senders (using standard log rotation to manage size). A systemd service to write to logs, another to read the last value and push to remote if it has changed. Bash all around.

Other than absolutely 0 maintenance required, and just a $5 droplet, the thing I like the most is the dashboard. It just looks like a spreadsheet. A row for each server, a column for each metric. Click on a cell to view charts for that metric. If metrics are failing health checks cell goes orange, or red if critical. Otherwise it's all gray.

So I can have the dashboard open on a screen and just glance at it and know if something is off. I haven't seen anyone else providing such a dashboard, maybe you can give it a go:)

When you right click on a Web page, such as the one you are reading now, and select View Source you can see the html, css and javscript that your browser reads in order to display the page.

Anyone can learn about these technologies and a good starting point would be Mozilla Developer Network (MDN for short) where they have all sorts of documentation on how to get started and what is the state of the art.

Of course, there is a lot more to it but if you just copied/pasted some files on a Web server and it worked this is all you need to know for now.

For anyone just learning about this.

Hope you find a host soon!

I think the main advantage these kind of tools bring is the user-friendlyness for both the developer and customer, in terms of UIs, security, and auditing.

App deployments, new releases, and all they entail are never in reality a commit/button push away. There's a bunch of stuff that needs to happen before, during, and after, with each app and deployment target having its own unique set of peculiarities.

That's the main problem these tools need to solve, but that's where the money is, I guess.

Cool. So the tar would be uploaded to the hub and from there the user can manage deployments. Or maybe even create draft? deployments from the gh action and the user would only have to confirm/approve before shipping to clients.

> Do you have an exact upgrade case in mind?

Yeah, some apps could get quite complicated due to <reasons> and a single `docker compose up` for deployment won't cut it. For example, user may need to do a backup before deployment or some post deployment steps like db migrations. These steps may depend on which app version you are updating from, so even though they can be handled from within the app some logic/state is needed to determine when to execute them.

The ability to specify pre-deploy, post-deploy and a custom deploy command (not just docker compose up) would be helpful.

> A deployment can either be managed by the vendor or by the customer.

But not both? Can't the customer invite the vendor back to allow them to perform such actions when necessary?

The customer portal is a good idea, the ux needs a little polish I think. Make it super easy to see if there's a new app version, a button to install it, and perhaps real time feedback/progress. Some customers would also appreciate the ability to export a list of app deployments with logs for auditing.

I've been through the docs and could find if there's a way to deploy a git repo, or a tar file, that contains the docker compose file instead if copy pasting. What about env variables?

Also couldn't find how you specify the endpoint(s) of an app. Does the agent just calls `docker compose up` or is there a way to specify the command(s) that should be executed during installation, upgrade, etc.

The customer portal is a great idea. It's not clear though, if the customer portal is enabled for a deployment and the customer can manage their deployment (eg, update to new version), would the isv not be able to do that from the vendor portal? Is it all or nothing when it comes to client self-service?

Thanks, great stuff I look forward to trying it out!

Whichever versioning scheme you end up choosing, the important bit is to keep documentation for all versions. Bonus points for mentioning in the docs when a feature was first added.

Some examples off the top of my head include python docs, django, bootstrap, postgres and celery.

Document the old pattern, document the new pattern, discuss, and come up with a piece by piece plan that is easy to ship and easy to revert if you do screw things up.

Unless the old pattern is insecure or burns your servers, that is.

Any particular reasons you haven't built upon wireguard that would handle encryption/security for you?

Can anyone recommend a linux tool for removing exif data from images and metadata from pdfs?

Can it also generate letterheads? Like the ones you see on invoices and such.

Many times I get a blank page or a turn javascript on page, and at that point I just hit back and move along. Sometimes, when the comments are positive or I think the content would be interesting to me, I use the Share feature to open the page on Firefox, for which I only have an ad blocker.

For sites I often use that require javascript, like HN or github, Chrome makes it very easy to enable javascript just for those.

For example, there was a link the other day about a new documentation site builder or whatever that I was interested in and all I got was a blank page. Closed the page.

As for the extra work, it depends on what you're building. For my side project I knew I wanted minimal js to begin with and was using django so making it non-js-enabled friendly was not a huge amount of effort for me. But I wouldn't consider it if I was using a javascript framework with server side rendering or any of that fancy new age stuff. That just creates more problems than it solves (ie the project may be dead before it goes public).

Quick edit: I write js for a living and I really like the language. As a user, not so much.

If the idea/product is just nice to have, or marginally makes it easier for some employees to do their job, you will be fighting an uphill battle that not be worth your effort or money or time.

Have you found the small hospital you will be selling this to? Or made a list of such potential clients?

And why would a small hospital be more willing to buy than other, bigger ones?

Maybe there's a feature or two that you/doctors have not considered useful but your clients find crucial, and you must focus on those ones more than anything else.

Maybe there's a reason almost all hospital/health-related software is bloated and sucks for anyone actually using it.

Maybe you should be spending more of your time thinking about these questions and how to answer them before spending any more money on this.

I'm not trying to stop you, just point you to what I think is the right direction. I could be very wrong here, is what I mean.

If yes, and they somehow validated your idea and implementation of it, congrats! You have completed the hard part of developing commercial software. Asking anyone for 2-3k is a very easy now.

If no, you may be overestimating the usefulness of your product, or the willingness of hospitals to pay for something like that, or underestimating the work required to get it done in a way that both fulfills the needs of your target customers and their own compliance-related must-have requirements.

The majority of IT projects fail for being under scoped or over budget or both. As a new med school grad, you may be lacking the knowledge, skills, experience to pull off a project like this in the way you hope.

My advice would be to think it through rationally. You may not have found the billion dollar idea, and if you have, maybe you are not equipped right now to pull it off in the way you think you should.

Good news is you can work these issues and achieve your goals. But it may be way more work than you'd think. Especially in this field.

I find it makes it easier for people to see and understand the goal of your changes and helps them focus on the how in the code review.

When others do that in their PRs I can jump straight into the tests files and get a better understanding of the what is proposed (or at least start the review process in a more substantial way - get the important stuff addressed early on).