It's pretty clear. If you have your bank account with 2 owners, and with X on it, X/2 are yours and X/2 belong to the other owner, at any point in time.
Case in point, if one of the owners deceases, you can withdraw X/2 at most. The other half is blocked until the inheritance paperwork is completed and that half has a new legal owner(s).
That is obviously true but doesn't mean as much as you seem to think. Washing laundry is also not much work but it adds up to a lot over the years, especially if you skip a few weeks of laundry every once in a while. That is not an excuse to not do it.
The answer is the same in both cases: acquire some discipline and treat maintenance with the respect it deserves.
The "one-person framework" thing is a big draw. I'm amazed at how productive I was in it, and it's not just at the code level. Even though I've been doing sysadmin/devops/architect work for over 25 years now, it's just so damn nice now not to have to think about e.g. standing up a HA PostgreSQL cluster or Redis and deployment is largely a solved problem.
There are two types of devs: those that ship and those that fill out surveys (and not because their stacks are so much more efficient that they have time to fill out the surveys)
First of all, ruby-lsp does a great job at this, and the recent Herb helps with frontend templates.
This is enough to navigate between controllers, models and libs, unless you're trying hard to be clever which you shouldn't.
Then, in Rails, things have a canonical place in the codebase, that is consistent between codebases.
This is in contrast to languages and frameworks where every codebase is setup differently, but the static typing helps find code wherever it's hidden without pain, and thus without need for cleanup and thoughtful design.
To each their own, I prefer power for me, and pain for whoever drifts from the convention.
This is a massive change for cache in webapp templates as it makes their rendering more stable and thus more cacheable.
A key component here is that we are trusting the user's browser to not be tampered with, as it is the browser that sets the Sec-Fetch-Site header and guarantees it has not been tampered with.
I wonder if that's a new thing ? Do we already rely on browsers being correct in their implementation for something equally fundamental ?
I think this is mostly historical baggage unfortunately. Every codebase I've ever worked in there was a huge push to only use native ES6 functionality, like Sets, Maps, all the Iterable methods etc., but there was still a large chunk of files that were written before these were standardized and widely used, so you get mixes of Lodash and a bunch of other cursed shit.
Refactoring these also isn't always trivial either, so it's a long journey to fully get rid of something like Lodash from an old project
This has improved recently. Packages like lodash were once popular but you can do most stuff with the standard library now. I think the only glaring exception is the lack of a deep equality function.
LLMs are good at writing tests in my experience.
reply