I don't understand why people (Greenpeace) are so against The Ocean Cleanup - complaining that we need to fix the problem at the root instead of cleaning up the mess afterwards. Why can't we do both?
Probably because of the Shopping Cart Tragedy: The thinking that you can leave your shopping cart in the middle of the parking lot because it's someone's job to collect them.
So people might throw trash into nature because they think that someone will collect it.
I think we're at the point where the people who are going to throw trash are going to throw trash, and I don't believe something like the ocean cleanup will increase how much trash people throw into nature.
You can make the same argument that you shouldn't clean your own house because that will just encourage others to make it dirty again. And thats obviously not how it works. Some people throw trash and some don't.
I wish it was as simple to solve as the Shopping Cart Tragedy. If you have an Aldi near you, you know that they never have problems with anyone leaving carts in the lot. A simple case of misaligned incentives that is easily solved with an effective solution. Shame that no other vendor in the States does it.
For those not familiar with Aldi in the States, they have a very rudimentary analog system that locks the carts up, and you put a US quarter in the lock to unlock the cart. You shop, put your groceries away, and when you go to lock the cart back up you get your quarter back. A quarter is basically nothing in today's modern age, but the mental desire to get it back is apparently powerful enough to incentivize people to walk the cart the 10 meters or so back to where it belongs. I haven't been to the Aldi's in Germany but I assume they work the same way.
Don't forget that NGOs also need to justify the cause of their existence, if needed by undermining what they consider a "threat".
Fighting to fix the problem at the root is an effort that will take decades. Interfering with the clean-up in the mean time because it might change the perceived urgency of the problem tells you a lot about what you need to know.
Kicking and screaming, I finally succumbed to TypeScript on the server. I used to do everything with Phoenix or Rails, but nowadays its hard to fight the full-stack type safety (even if its mostly an illusion) of something like Remix/Hono with React + Drizzle/Kysely.
I hate having to wire everything together, and how I might have to rewrite it next month, and how there is no standardised way to do anything, and how I have to install a library for everything and figure out how to make them work together.
Storing the data directly inside the application still means you need to store it somewhere, likely a SQL database (such as PostgreSQL). These databases are insanely well engineered and very very fast, but compared to a key value store such as Redis and Memchached they are comparatively slow and resource hungry (because they are optimized for different things).
So if you can fetch some cached data from a Redis key, even if on the same machine, it will cost you significantly less than querying a relational database.
As someone who upgraded from an Intel Mac to an M1 mac, the memory is a non-issue. Three years ago I would have laughed if you said I would be happy with "only" 8GB, but now I am.
I thought I'd be happy with 8GB based on benchmarks and sensationalistic videos (thanks, Max Tech), but I absolutely wasn't. Apple silicon Macs or maybe Macs in general handle high memory pressure (graph in the red) terribly. The system will get extremely slow and laggy, develop audio issues and eventually lock up.
I ran into that all the time on the 8GB model (admittedly with multiple RAM-intensive apps and lots of tabs open), while it now happens very rarely on my 16GB model.
Is that high memory pressure slowness issue the same when there is lots of HD space left? Apple devices have had issues with “low” amounts of HD space for a long time, and I’m curious if the M* continue the trend.
Also: this makes a red flag of the recent shift to half-speed drive performance
React is * old * (in the frontend world), stable and very very well known. It is a solid, responsible choice to build your framework on top of React in 2022.
You can upgrade a 7 year old React app with very little fuss. Unfortunately, you cannot say the same about Vue or any of the modern libraries. They also have no track record to indicate they will exist 10 years down the line, but I'm pretty sure my React apps will still be fine.
That being said, I'm very excited about SolidJS[1] and the other modern libraries that use JSX.
Vue is about as old as React, and upgrading a React app from class-based to hook-based is as much, if not more, work than going from Vue 2 to Vue 3 (but I don’t want to do either one).
I’m exceedingly unexcited about anything that uses JSX, which is a blight on the landscape.
I found this[1] on the documentation. But in general staging environments, continuous integration and continuous delivery are not built into frameworks (Rails, Phoenix, etc).
Congrats! I've been keeping up with Redwood since the original announcement, and the progress they've made has been incredible. The generators and command line utilities are top notch (compared to Rails, thats a high bar to clear) and the general structure of everything seems very well thought out. Still missing a good official solution for background jobs, but I see there is a workaround in the 'How To' section on the documentation. The core team members are super nice and the community is very welcoming.
I'm not convinced the "client side app + Graphql server" is the best model for most startups, however. I tend to lean more on server rendered pages with a little bit of progressive enhancement. But I assume the people who made Redwood are more knowledgeable than me :)
> I'm not convinced the "client side app + Graphql server" is the best model for most startups
Startups don't know what they need when just getting started. When you have a Graphql api you can spin up any number of other tools not just "client side apps", it can connect to a mobile app, cli, any number of other tools and you don't need to go back to the drawing board to make it happen. I've been using Redwood for quite a while and on my app I just spun up a public api with api keys and still maintain my private api specifically for internal app use in less than a day. When I started my project I didn't know I would need that.
Alright, that is a very good point. If the possibility of other nodes interacting with your service is high (ie “you’re gonna need an API eventually”), this might well be the best option.
Fly is compelling enough to use without all the global deployment options they offer[1] but it's assuring to know if you ever do need to deploy globally, they can support that better than most.
