301–310 of 413 posts
The cycle of expertise : - what is X, I just do Y - wow I can see so many limits of Y, now I do X - I use X for literally everything - now that I properly understand the limits of Y but also the heavy constraints of X ... maybe Y is enough - I use Y for literally everything rinse & repeat. The thing is with actual usage and actual context one does learn and thus can get away with a lot more "basic" solution but it do…
Persistence in folly leads a fool to enlightenment.
Earlier quoted context omitted.
I assume they meant a log like a WAL. A WAL should be (quite literally?) all you need for durable workflows. A distributed WAL (to survive a machine death) would also probably be something I'd want, and … something I'm not sure you're getting directly from SQLite.
Is it common to use logs as a proxy for write-ahead logs?
I've replaced all of these with Go + SQLite: 1. Intercom 2. Zendesk 3. Email marketing 4. Kanban 5. Todo 6. Our billing stack 7. Our issue tracker 8. Our forum 9. Uptime monitor 10. PagerDuty (clone) I have dozens of products I sell, so I thought: why not build everything ourselves? All of these run on the same server and use very little memory. I replaced all the SaaS tools we used with these. I also moved to dedica…
The cycle of expertise : - what is X, I just do Y - wow I can see so many limits of Y, now I do X - I use X for literally everything - now that I properly understand the limits of Y but also the heavy constraints of X ... maybe Y is enough - I use Y for literally everything rinse & repeat. The thing is with actual usage and actual context one does learn and thus can get away with a lot more "basic" solution but it do…
It is a source of expertise, because you really learn a lot from it. But when you become old (43 over here), you really learn to appreciate “boring” solutions.
I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency. This is what database _servers_ are for, e.g., Postgres, MySQL, etc. Their entire job is to allow you to modify data from multiple processes, on different machines, at the same time. This is a foundational principle of computer science. It seems to me that the "SQLit…
You seem to have a rather limited understanding of what kinds of concurrency exist and how those needs are best met. Whether something is a server or not is not very relevant to this discussion. SQLite is an excellent production db for many real world workloads, as has been widely documented. It is very different to Postgres, so requires learning a whole new skill set. One way to think about it is that SQLite can wor…
I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency. This is what database _servers_ are for, e.g., Postgres, MySQL, etc. Their entire job is to allow you to modify data from multiple processes, on different machines, at the same time. This is a foundational principle of computer science. It seems to me that the "SQLit…
Earlier quoted context omitted.
Internet Explorer 6 was the most widely deployed awesome piece of software. Those that hated it need to look a bit harder.
It was not really “deployed” by a lot of people in the same sense. It was forced upon most of us(not me, I used BeOS then Debian then FreeBSD). I deployed phoenix.
The cycle of expertise : - what is X, I just do Y - wow I can see so many limits of Y, now I do X - I use X for literally everything - now that I properly understand the limits of Y but also the heavy constraints of X ... maybe Y is enough - I use Y for literally everything rinse & repeat. The thing is with actual usage and actual context one does learn and thus can get away with a lot more "basic" solution but it do…
Yup, when I look back at the silly stuff I did when I was somewhere in the middle (CQRS + event sourcing I’m looking at you), it’s interesting. It is a source of expertise, because you really learn a lot from it. But when you become old (43 over here), you really learn to appreciate “boring” solutions.
I don't understand this obsession with SQLite for real, production apps. SQLite is an embedded database, completely unsuitable for managing concurrency. This is what database _servers_ are for, e.g., Postgres, MySQL, etc. Their entire job is to allow you to modify data from multiple processes, on different machines, at the same time. This is a foundational principle of computer science. It seems to me that the "SQLit…
"Just use postgres" "Just use sqlite" "Juse use a monolith" "Just use sftp" "Just use an ec2 instance"
Usually these people have flunked out of the school of (distributed system) hard knocks. They couldn't hack it and are retreating to familiar.
The funny part is when one of those people fluke themselves into senior management when their saas takes off.
Inevitably they have to suck it up and hire experts in the same technologies that "no one needs".