"...hard to imagine scenarios where [file-level compatibility] is useful" what am I missing? Surely dropping a more performant dbm into an existing project would be the application? No?
imho the vaunted readability of custom elements has long been available with haml, with added readability by virtue of the indentation rules replacing closing tags. Not sure why it didn't really gain much traction, maybe the pre-processing is problematic when there's no server-side framework like Rails?
Developers like to copy/paste UI component example HTML from Tailwind/Bootstrap documentation, they like predictability/portability. They don't want a project that's half HTML and half HAML...ie, Vue/React using HTML/JSX vs 50% of Rails views in HAML, 50% old ones in HTML.
Just like how using Vanilla JS is much smoother and reliable than using the latest wrapper framework.
I worked on a project that used haml, and merge conflicts in the haml files were very hard to resolve due to the lack of any nesting info besides indentation.
I think it's worse than, e.g., typical yaml files because the nesting is deeper.
beneath the fancy graphics there's zero explanation of how these are manufactured, how they're constructed, or the magnetic field patterns. No actual deployments or demonstrated applications, just graphics. It's a 3-person company that "expects to begin testing of this exciting new technology early in the 2nd quarter of 2023".
your rage suggests that you think ChatGPT is making value judgements about elegance or simplicity. You surely know where it picked up those concepts don't you?
"...but will constantly run in to situations where another gems code is using the method that just changed". I've worked with Rails for 20 years and haven't seen this. Have I just been really lucky?
I'm sure your test suite showed the warnings about the Redis `exists()` change for many versions prior to its actually being changed, right?
I’ve worked on rails apps for a while now and on previous jobs it wasn’t so bad, but those were smaller apps. At the current company, almost every update manages to slip something through CI that blows up on production. Even with 30,000 rspec tests and tons of cypress tests. The CI is set up to raise exceptions on warnings, but I think it only applies to warnings raised by rails.
I guess rails works alright at the start, but eventually your app gets so big that it becomes a nightmare to verify updates before they roll out.
In this case no because the broken code was in another gem (sidekiq) using the redis gem. Our CI does not run the unit tests for every library we import. Only our own.
Try idealist.org
But mostly there's not enough $ in non-profits to pay a s/w dev.
Another approach is to work hard, retire early, and then do the work pro-bono. I have been doing s/w for non-profits since I retired at 51 20 years ago.
Or just do both at the same time if possible. When I started my daytime job eight years ago, I managed to negotiate a four-day-week. Since then I used the fifth day to do freelancing in projects I find interesting and over the years I've shifted to use it mostly to do voluntary IT work for a local non-profit.
The daily structure of work life allows one to avoid facing some questions that otherwise arise. Financial independence forces one to explore how one wishes to spend one's time when the work constraints are eliminated. This can be a very exciting, fruitful and rewarding endeavour. I highly recommend it.
I got a lot out of Jennifer Widom's "Introduction to Databases" MOOC from Stanford. Particularly the normalization concepts. (Don't take them too far, though, as they say "Normalize until it hurts, denormalize until it works"!)
Yes this is exactly what you need to do. And yes it takes some careful design to eliminate power supply noise.
NeuG has some low quality sources of entropy, and also provides analog input for the user to supply with whatever they wish. It does not address the design of a good white noise generator, unfortunately.
