WillDaSilva

In a typical Rust project you organize your project into many crates. I haven't checked, but I'd guess that the vast majority of those dependencies are internal dependencies. After all, this project started by running an automated C to Rust converter, which the authors claimed produced over a thousand crates.

For what it's worth, Immich supports this too. You can create an album (for each event), create a shared link, allow public anonymous uploads for the shared link, and then give the link to everyone at the event, and ask them to upload their photos. It can be done from any web browser.

It's pretty easy these days to spin up a local Postgres container. Might as well use it for prototyping too, and save yourself the hassle of switching later.

There's a repository setting you can enable to prevent actions from running unless they have their version pinned to a SHA digest. This setting applies transitively, so while you can't force your dependencies to use SHA pinning for their dependencies, you can block any workflow from running if it doesn't.

Pulumi may be what you're looking for. Same concept as Terraform, and many of its provider libraries are just wrappers around Terraform provider libraries, but you can use a variety of common programming languages to declare your desired state, rather than HCL.

Timezones are not static, and actually change somewhat frequently. A program that converts any given future time to UTC risks becoming incorrect about when that time is due to political changes that affect the timezone the given future time was in.

I was able to get a Pasmo card as an alternative to Suica, and it was rechargable with cash. I also did the same with an Icoca card. I didn't need a Japanese address in either case. I just bought the cards from machines at a couple of the larger metro stations. They could be reloaded with cash at any metro station.

I fully agree. The rate limits are how you control the behaviour of the clients. My suggestion of leaving caching to the clients, which they may want to do in order to avoid hitting the rate limit.

There are times when a cache is appropriate, but I often find that it's more appropriate for the cache to be on the side of whoever is making all the requests. This isn't applicable when that is e.g. millions of different clients all making their own requests, but rather when we're talking about one internal service putting heavy load on another one.

The team with the demanding service can add a cache that's appropriate for their needs, and will be motivated to do so in order to avoid hitting the rate limit (or reduce costs, which should be attributed to them).

This is exciting to see. I run some latency sensitive code on Lambda with the Node runtime, so cold starts are troublesome. I hope I'll be able to use this one it's in beta or fully released.

Distributing your backup over the spare storage of many other NAS servers is the main idea behind Storj, which provides a remarkably cheap price per TB per month.

It is done, albeit rarely due to how expensive and complex an operation it is. My friend's mother moved her house a few kilometers across some farmland. It was a rather large 2 story tall house, with a basement. It had to be moved to a plot that had a similar foundation and basement prepared for it.

If they sell their land, then presumably they'd receive a substantial windfall with which they could buy a new cheaper place, or rent. If they don't receive a substantial windfall, then the amount they were paying for the LVT must've been low.

Assuming the tax is high enough (or grows over time to become high enough) to offset the negative externalities, and that the money raised is used to offset negative externalities, they're better phrase not as "it's fine to burn up the world as long as you're rich", but rather as "it's fine to emit CO2 as long as you sufficiently offset the damage". Accounting for the damage could involve investments into green technologies, or paying ordinary people to make the tax popular, among other things.

Personally I like the idea of setting the price for emitting 1 ton of CO2 equivalent emissions to the realistic cost of capturing 1 ton of CO2. At least, that seems like a reasonable end goal for a carbon tax, since that could fully account for the negative externality. This would of course be obscenely expensive, which would be a strong incentive to lower carbon emissions where possible, and for people to consume less of products that require large emissions to make or use.

The carbon tax would also have to apply to imported goods to be effective, and tracking how much tax should apply to imports would be even more difficult than doing so for domestic sources of pollution.

I would assume because the tool is updated frequently, and has a tendency to not work properly if you aren't using the latest version.

While the downsides of this are obvious, I wonder if in the long run this would push our cities towards better designs, by encouraging the mixing of residential and office buildings, and by encouraging improvements to implementing public transit that can quickly and efficiently move a dense population between their homes and their jobs. It probably wouldn't work, but I can dream.

Not at all, since those who aren't rich primarily use public transit to get around this area, which benefits massively from reduced car traffic.

I stand corrected. Thanks for sharing that info.

No way he would have done that without copyright.

Was his creation of his autobiography primarily motivated by money? I would assume not.

I have seen team members fall below expectations, or burnout, or otherwise become unproductive, but then recover. In every case, their manager was a key part of the solution (and sometimes a key part of the original problem). If a person is really stuck on their current work, it can be demoralizing to have it taken away and assigned to others, but it can also be a relief. One thing that I've seen help is to let devs be more self-directed. Try to nudge them towards things that are important for the business, but focus on doing that by really convincing them of the value of that work. If they don't want to do that work, try to understand why, and consider changing plans based off of that.

Have you ever tried to hire developers? I have, many times. It's shocking how incapable most people with a history of working as senior developers for 10+ years are at basic programming questions. I'm talking about stuff at the level of Fizz Buzz, or barely more difficult, being solved in a language of their choice with ample time.

Through all of the technical interviews I've run on behalf of multiple companies, I've become convinced that our industry is full of imposters. A terrifying number of people who are employed as developers cannot code, beyond making tiny edits to existing code, or slinging StackOverflow answers and AI generated content around. They cannot think for themselves. They rely heavily on their coworkers to make any substantial progress. If anything, modern AIs have made these people more difficult to spot. I've found these imposters within the companies I've worked for too, and if it's not possible to move them to a non-technical role where they can be productive, then it's best to fire them. If that isn't possible, then keep them out of the way of any critical work, but know that they'll continue to be a drag on their team, and will decrease the moral of those on their team who have to keep covering for them.

Once I even worked on a team (as a junior) where only 3 members out of ~16 even knew the language that was exclusively used for the job. The remaining team members accomplished nothing every day. Those stand-up meetings were painful. Drawn out to 45+ minutes of standing in a circle while the unproductive team members found new ways to explain why they haven't made progress. Then I'd see them return to their desks, and not even open their IDEs for weeks at a time. They seemed to keep their jobs because their boss didn't want to fire them, and it cost him nothing personally to keep them around, offering them a sort of corporate welfare. Perhaps having such a large team even helped him politically, but it's unclear if he cared about that since he also spent almost all of his time slacking off, playing games in the break room, while the 3 productive team members carried the rest of the team.

When they suggest you pin your dependencies, they don't just mean your direct dependencies, but rather all transitive dependencies. You can take this further by having a lock file that account for different Python versions, operating systems, and CPI architectures – for instance , by using UV or Poetry – but a simple `pip freeze` is often sufficient.

I've migrated a couple moderately large projects from pyenv & poetry to uv, and it has been great. The switch was easier than I expected. I uninstalled pyenv after a few weeks, as I realized that uv makes it irrelevant. I've also replaced pipx (which manages Python tools/programs each with their own virtual environment) with uv's tool feature. I used uv for every new Python project. The only thing it's missing that's important for me is support by Dependabot on GitHub. Once Dependabot can update its lock files, I'll be able to uninstall poetry.

Are we going to start filing lawsuits against sugar manufacturers for all of the health issues they caused?

Like with the fossil fuel industry, the sugar industry also invested heavily into misleading the public about how damaging their product is. With that in mind, it seems at least somewhat reasonable for governments to file lawsuits against them to punish them, and to recoup some of the lost value due to their negative externalities.

Celery workers default to acknowledging messages messages as soon as they've been recieved, leading to them failing to be processed if the worker crashes. Dramatiq, by contrast, will only acknowledge a message once a worker has finished processing it. As a result each message may be processed multiple times (if the previous worker handling it crashes), but there's a guarantee that each message will be processed to completion at least once.

They also call more attention in their docs to how to make the broker confirm message delivery than Celery does. Overall Dramatiq seems more concerned with robustness and reliability than most other Python task queue frameworks.

They compare themselves against Celery here: https://dramatiq.io/motivation.html

Notably, it appears the authors of this study are the owners of https://www.earthing.com, which sells products to help ground people. This is called out in the study. Given this massive conflict of interest, I can't put much stock into these findings until they're replicated by independent researchers. Absent that, I'll assume that this study is manufacturing a (possibly false) scientific basis for buying the grounding products.

Netflix is a major force behind the development and uptake of web DRM, which I'd consider pretty evil.

Even if we accept that the personal vehicle provides a better experience for an individual in a vacuum compared to ideal public transit, we're left with the critical problem that if a significant number of people choose to use personal vehicles instead of public transit, then there will be so much traffic that the experience will be awful for everyone. This traffic will cause travel delays, noise, pollution (from exhaust, brake dust, tire dust, etc.), and create an unpleasant dangerous environment for pedestrians and cyclists.

kdb doesn't support effecient vector similarity searches, or efficient storage of high-dimensional vectors. It isn't really in the same class as the vector databases discussed in this post. It's more suited for time series data.