301–310 of 378 posts
Yeah, it works when it works. Just that in many cases you'll run into scenarios with it when it completely doesn't or is missing something crucial and we'll get another prodigal son story about going back to Postgres.
Such as?
Everytime I try to use SQLite I run into db locking issues where I seemingly have to try to run my query in a retry loop. Am I doing something wrong or does SQLite just not play nice in multi threaded contexts?
SQLite is a great but complex software. In order to properly use it, you do need to read the documentations, guides and resources available at the official website. If you don't, you will shoot yourself in the foot. In that sense, I have the impression SQLite is different from other database software. You can usually get by with Postgres or MySQL (after they are set up) without looking at their docs. I spent several…
If you are blindly doing multi-threaded connections without understanding the implications, you also risk corrupting the database entirely.
Earlier quoted context omitted.
One significant caveat: "Free projects are paused after 1 week of inactivity." I'm not complaining, but I reckon a lot of hobby projects would see sporadic activity. For example, I used to upload a list of my CDs to a VPS, so that when I found something interesting at a music store, I could check to see whether I already own it (#FirstWorldProblems).
If you're going a week without activity then SQLite is basically as overkill as PostgreSQL is.
This sentiment pops up regularly on HN, and I've seen at least one article per month for the past few months, but the trouble is, none of them seem to help you actually deploy it. They assume you're comfortable spinning up public web servers. If you want to use a PaaS to deploy an app, because you don't want to spend your time learning to be a sysadmin, then all the tutorials are going to put you on the Postgres path…
> I'm an application developer and I do not want to become a release engineer. I resent even having to learn Docker. :-) Sorry, but that's a terrible attitude to have. You don't need to be a full-blown sysadmin to know how to do basic deployments, and learning these things will make you a better developer.
If you just want to do the minimum to run the app, it will make you worse and usually utterly terrible sysadmin, as it usually is going to be "do the minimum required amount of copy-pasting from tutorials to make the stuff running".
Then inevitably don't update shit, nor even set unattended-upgrades package.
And if the server won't get hacked from bad firewall and no updates, the server will ran out of space because dev of course didn't thought about data management and some log file in wrong place without rotation overflowed.
That's from decade+ of fixing shit of developers that think that tutorial on internet made them sysadmin.
Earlier quoted context omitted.
> I'm an application developer and I do not want to become a release engineer. I resent even having to learn Docker. :-) Sorry, but that's a terrible attitude to have. You don't need to be a full-blown sysadmin to know how to do basic deployments, and learning these things will make you a better developer.
So many things (deployment and productionizing) are easily possible without Docker, so why add that layer of complexity unless you know you have a good reason? Why make Docker and essential part of a system before you actually need it? There’s a reasonable chance that you never need it. I know this, because a lot of business and hobby systems have been in operation since before Docker existed. Docker has value in man…
Go app which is one blob and some static file ? Sure. Java app that just needs JVM in system ? Go ahead, .service systemd file with some limits is all you need.
Ruby on Rails ? Put that radioactive shit in container, else your server will need to have a bunch of -dev packages just to compile gems and make it running (or alternatively you'd have to compile the gems on same environment server is running, which is more work than just making a container)
Earlier quoted context omitted.
> I'm an application developer and I do not want to become a release engineer. I resent even having to learn Docker. :-) Sorry, but that's a terrible attitude to have. You don't need to be a full-blown sysadmin to know how to do basic deployments, and learning these things will make you a better developer.
I don't know why this is downvoted, it's probably the best advice on this page. Learning a few things about deployment definitely helps to make better software.
Earlier quoted context omitted.
Agreed. Too much reliance on AWS, Heroku etc. can leave you without vital Linux skills. Linux cli tools are not just for getting a job done, though they're great at what they do. No, they're part of the *nix culture which is what open source software is based on. Only recently have I become aware that it was better to have entered software development in or before the early 2000s, ie. before The Cloud took off. You w…
I used slackware linux. I wrote assembly code when I was a teenager. I use 'perl -i -pe' constantly. I still don't want to learn a bunch of arcane flags from a bunch of tools with a million gotchas. Sorry. I'd rather focus on the code craft that gives me joy these days. Sorry, I detest this attitude of: "Well I was hazed so why aren't you hazed too?" Did I mention that Russ Cox and I used to write C code with pen and…
Docker, k8s and friends are essentially just level above the "just CM", still just use basic linux primitives but with some coordination.
The "new toys" are essentially abstractions on what sysadmin would do (anyone remember building chroots ? Yeah I don't liked it either, even if it felt "cool" the first time I did it) and every abstraction will leak which means once you are big and complex enough you will need to debug it. Just that random hobby project probably won't get there and even for work it probably might be someone's else job to debug that
> I should STFU? Give me a break
...you probably should, your whining and bragging doesn't add anything to discussion. "Oh I played with cool kids few decades ago, look at me Mr. Important"
This sentiment pops up regularly on HN, and I've seen at least one article per month for the past few months, but the trouble is, none of them seem to help you actually deploy it. They assume you're comfortable spinning up public web servers. If you want to use a PaaS to deploy an app, because you don't want to spend your time learning to be a sysadmin, then all the tutorials are going to put you on the Postgres path…
You can run small project on $5 VPS with Postgres just fine tho...
Managed services in cloud are usually massively overpriced
Earlier quoted context omitted.
So many things (deployment and productionizing) are easily possible without Docker, so why add that layer of complexity unless you know you have a good reason? Why make Docker and essential part of a system before you actually need it? There’s a reasonable chance that you never need it. I know this, because a lot of business and hobby systems have been in operation since before Docker existed. Docker has value in man…
entirely depends what you're deploying. Go app which is one blob and some static file ? Sure. Java app that just needs JVM in system ? Go ahead, .service systemd file with some limits is all you need. Ruby on Rails ? Put that radioactive shit in container, else your server will need to have a bunch of -dev packages just to compile gems and make it running (or alternatively you'd have to compile the gems on same envir…
I've been deploying Rails since v 2, and never with Docker. The only time I ever had trouble was setting up Rails dev on M1 Mac when M1 was new. In Linux production, it just worked; and pulling/building gems was less a drag than what people regularly experience in the NPM world.
To be fair, I don't use a ton of gems because I generally don't like additional dependencies unless the value is really there. So maybe my use cases have been too basic to experience the pain.
For data science purposes, it seems to be quite interesting.