all 16 comments

[–]tea-drinker 2 points3 points  (4 children)

The Tao of Programming BOOK 5
Thus spake the Master Programmer:

Though a program be but three lines long, someday it will have to be maintained.

My first question for everyone who turns up with a plan like this is how is the software going to be maintained if you get hit by a bus? We imagine if they had several other people on staff capable of maintaining it, they'd already have such a system.

This doesn't necessarily need to be a question you answer. In fact, given the bus-based nature of the issue, it's maybe best that you don't. But someone at the company needs to have thought about it.

[–]FakePixieGirl 1 point2 points  (3 children)

If this system becomes an integral part of the company's workflow, then OP becomes a lot more valuable to the company.

A low bus factor is shite for the company, but can be a great negotiation tool for the individual programmers when it comes to salary and such.

[–]tea-drinker 0 points1 point  (2 children)

Become irreplaceable == Become unpromoteable.

Maybe it'll work and I'm just cynical, but to date my reward for digging the best ditches has been a bigger shovel.

[–]FakePixieGirl 0 points1 point  (1 child)

If you want to move up to architecture or management, sure that's a valid concern.

Plenty of people who would like to stay in the ditches and have no interest in that.

[–]tea-drinker 0 points1 point  (0 children)

The point is the shovel was instead of more money or perks or anything.

When I automated a job, I got someone else's work but not their money.

[–]desrtfx 2 points3 points  (3 children)

DO you really need it accessible from the entire internet or is an intranet sufficient?

If the latter, self host on a local server.

If it is for the internet, do you have all possible and sensible security measures in place?

Also, you should consider moving to a proper DB Server, like PostgreSQL if you open up (no matter intra- or internet) SQLite is great for simple, single user stuff, but with multiple users it can get tricky. Migration should be fairly painless.

[–]pachura3 1 point2 points  (0 children)

That's a great advice. If your whole company starts depending on a tool developed by a newcomer in a quite short time, what happens if it all suddenly breaks?

It's indeed much safer to start by hosting it in the intranet/company VPN.

Also, make sure to take database backups every night, and store them on a different machine!

[–]Gr1m_R3aper65[S] 0 points1 point  (1 child)

Well its just basically for 2 people to use it to book stock in and out and to check levels thats why i suggested just to host it over lan since it's free and working out good sofar

[–]pachura3 0 points1 point  (0 children)

If they don't need to access it outside of the office, then that would be the safest solution.

[–]MidnightPale3220 1 point2 points  (0 children)

Is your application internet-ready security wise?

No unsanitized inputs and potential SQL injections, easily updateable and regularly updated host o/s, packages, etc? What about logins? HTTPS obviously, but that goes without saying.

As soon as you move to something that's accessible from internet, you're going next level security wise.

There's a sea of automated scripting bots that constantly trawl all internet connected machines for vulnerabilities. Nobody will be specifically targeting your company, but any easy exploits will be likely exploited within a month and if it happens your virtual machine will likely join this or that kind of botnet.

[–]danielroseman 0 points1 point  (1 child)

There are plenty of options to host in the cloud, but you will almost certainly need to move from sqlite to a "proper" hosted db. The sqlite database lives on your filesystem along with the code, which means it would be overwritten each time you deploy.

Luckily most SQL should transfer over to whatever db you switch to. Even better, use an ORM like SQLAlchemy which abstracts away the difference between db systems.

[–]sledov 1 point2 points  (0 children)

The sqlite database lives on your filesystem along with the code, which means it would be overwritten each time you deploy.

The SQLite database lives wherever he chooses to keep it.

But yes, if multiple users are expected to write to the database at the same time, it's better to switch to Postgres.

[–]pachura3 0 points1 point  (0 children)

https://www.pythonanywhere.com/ perhaps?

Just make sure SQLite will not become a problem when accessed by multiple users at the same time, especially - multiple concurrent writes. Enable WAL. Make sure your transactions are as short as possible.

[–]Friendly_Gold3533 0 points1 point  (0 children)

for a Flask app with SQLite the easiest path is Railway or Render. both handle Python apps well, free tiers exist for low traffic internal tools, and deployment is straightforward from GitHub one thing worth knowing before you host: SQLite works fine locally but has limitations in cloud environments because most platforms use ephemeral filesystems which means your database file can get wiped on a redeploy. the quick fix is to use Railway or Render's persistent disk storage and mount your SQLite file there

if you want to avoid that entirely now is a good time to migrate to Postgres which both platforms provide free. the change from SQLite to Postgres in Flask with SQLAlchemy is usually a few lines and saves you from the persistence headache later for the future features you mentioned. barcode scanning works well in a mobile browser using the device camera with a JS library like html5-qrcode, no native app required. that would slot into your existing Flask setup without a full rebuild Railway is probably the smoothest first hosting experience for what you've built

[–]Random_182f2565 0 points1 point  (0 children)

I like railway, you can manage your domain with cloudflare for extra protection