Not literally required, because languages typically support UTF-8 source files, but it would be difficult to use most popular software libraries without being able to at least read English.
The whole query builder is an optional abstraction built onto the ORM. It has many benefits, but will also never completely support every SQL variant in existence, as is true with all query builders. so I feel as though the only responsible way to build ORMs is with escape hatches, and this is one of them.
The lack of expressiveness in query builders that the author refers to in their first post as a motivation for ditching them is an easily solvable problem. It seems like most ORMs have easily solvable design issues though, and I would definitely agree that you should ditch tools that get in your way. What I've been doing is sporadically working on an _experimental_ Golang ORM called Trance, which solved this by allowing parameterized SQL anywhere in the builder through the use of interfaces. e.g.,
Turbo is just a front-end library it doesn't matter what your backend stack is. You can do all of that with a MPA approach, including partial DOM updates, with just the JSON API for your mobile apps being the missing part simply due to not needing it for the browser implementation. Serializing JSON on the backend and transforming it into HTML via React should always be slower than just sending the same HTML over the wire. I'll have to benchmark Pocket SQL to get frontend numbers, but it is perceptibly instant with requests taking single-digit ms, so it's not like the server-rendering part of it is slow. I'm glad the SPA approach worked out back then! The point I'm making is that MPAs are worth another try with modern tooling.
That's interesting because a CRM sounds like a strong use case for server-rendered HTML: Relatively low interactivity outside of form handling, which is consistently a weak point for SPAs. I wonder how different your experience would have been back then if you had modern browser APIs and something like Turbo, because the manner in which you go about the JS makes a huge difference. I would not advocate that people use HTMX for example, which strikes me as just being inline JS.
Simplicity is relative. I wouldn't call having to reimplement basic browser features like forms simple compared to slapping Turbo on server-rendered HTML (which took me ~50 LOC last I did so on Pocket SQL).
It's a lot less bandwidth to serve one login screen than the entire contents of all of your source repositories to a bunch of crawlers. You can also cache that one login screen in memory.
It seems like git self-hosters frequently encounter DDoS issues. I know it's not typical for free software, but I wonder if gating file contents behind a login and allowing registrations could be the answer for self-hosting repositories on the cheap.
I can't speak for HTMX specifically, but going to progressively enhanced server-rendered HTML from React requires a certain amount of mental deprogramming. I've been using Turbo lately for side projects (e.g., Pocket SQL) and found it involves working much more closely with browser APIs, but also writing way less UI code. Pocket SQL required writing about 50 lines of JS and people probably wouldn't notice that it's not a SPA unless they looked under the hood.
Depends on the parents because a lot of them are more than qualified. The typical education major isn't exactly a scholar, but that is also true of most people.
God forbid people have standards of basic human decency. "Trump bad" posts being popular on a website is a world of a difference from a rich guy buying another platform with the specific goal of bringing back literal nazis, as proven in released court documents, doing it, and then going above and beyond by posting that kind of content himself.
Maybe if he wasn't personally and very publicly trolling an entire open-source community, which has created financial burden for users, then people in that community wouldn't be so upset.
Unless you're at a theme chop shop, then you might as well move onto greener pastures. There are so many alternatives now for website control panels like Wagtail, Payload, and Craft CMS.
I finally quit my barren Twitter when the Musk takeover resulted in my feed being flooded with porn (including illegal content) and arabic carpet cleaning ads. I seriously doubt anyone's default Reddit front page has ever looked like that.
Does it really take any more time to secure a VPS than a docker container on a custom runtime for a hobby project? Either way you still have to run software and OS updates.
The main edge Nvidia has in gaming is ray tracing performance. I'm not playing any RT heavy titles and frame gen being a mixed bag is why I saved my coin and got a 7900 XTX.
Swarm works just as well in a single host environment. It is very similar to compose in semantics, but also does basic orchestration that you would have to hack into compose, like multiple instances of a service and blue/green deployments. And then if you need to grow later, it can of course run services on multiple hosts. The main footgun is that the Swarm management port does not have any security on it, so that needs to be locked down either with rove or manual ufw config.
You should try swarm. It solves a lot of challenges that you would otherwise have while running production services with compose. I built rove.dev to trivialize setup and deployments over SSH.
What is the motivation of emulating an ascetic lifestyle by consuming low quality goods? It sounds like you're doing it to save money rather than reduce total consumption, but for what greater purpose?
People who are serious about doing remote work are going to pass on anything that indicates hybrid. The simplest screening technique is to give instructions within the job post to submit via email rather than the job board form. Even before LLM slop became the norm people were spamming their resumes with Easy Apply.
It's all unencrypted secrets from perspective of an attacker. If they somehow already have enough access to read your environment variables, then they can definitely access secrets manager records authorized for that service. By all means put secrets management in a secondary service to prevent leaking keys, but you don't need a cloud service to do that.
Painful is an understatement. Keys for sensitive customer data should be derived from customer secrets either way. Almost nobody does that though, because it requires actual forethought. Instead they just slap secrets in KMS and pretend it's better than encrypted environment variables or other secrets services. If an attacker can read your secrets with the same level of penetration into your system, then it's all the same security wise.
KMS access is granted by either environment variables or by authorizing the instance itself. Either way, if the instance is compromised, then so is access to KMS. So unless your threat model involves preventing the government from looking at your data through some theoretical sophisticated physical attack, then your primary concerns are likely the same as running a box in another physically secure location. So the same rules of needing to design your encryption scheme to minimize blowout from a complete hostile takeover still apply.
First-class kafka compatibility could go a long way to making it a justifiable tech choice. When orgs go heavy on event streaming, that code gets _everywhere_, so a vendor off-ramp is needed.
Seems like really cool tech. Such a bummer that the it is not source available. I might be a minority in this opinion, but I would absolutely consider commercial services where the core tech is all released under something like a FSL with fully supported self-hosting. Otherwise, the lock-in vs something like kafka is hard to justify.