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.
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.
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.
Socials:
- github.com/WillDaSilva
Interests:
Climbing, Cycling, DevOps, Data Science, Education, Fitness, Hiking, Music, Networking, Outdoor Activities, Open Source, Philosophy, Remote Work, Programming, Privacy, Startups, Social Impact, Science, Space Tech, Technology, Travel
---