Both examples have the same behavior for me on firefox mobile. So their solution isn't universal for all browsers :(

Depends on which classification system you use. Botaically it is a fruit. But culinarily it is a vegetable.

I would want a smaller device and larger screen. Aka reduce the bezels. The deck has comically large bezels.

Also, the size of the device does not have much to do with its weight. I would rather a larger comfitable device then a tiny one that gives me cramps to use. Lighter weight is always a plus. But not always worth the tradeoffs. I would not want a lightweight device that only lasts 30mins of usage.

If you can drop a .env file on a server. You can drop a well formed .ini file instead. I don't see any reason to ever parse a env file as a ini file.

The ownership model is Rust's core innovation. Every heap allocation has exactly one owner — the variable binding that "holds" it. Ownership can be moved to another binding, at which point the original is invalidated. It can never be silently copied (unless the type implements Copy).

While each of these is not wrong in isolation, together they are. If we are talking about data stored on the heap that last bit is not true. Types that hold a raw pointer cannot be made Copy. Only simple types can be made Copy, ones that don't own any non direct data and as such can be stored on the stack and simply memcpyed to get a copy.

Functions can do all this. Computed properties are just syntactic sugar for methods. That is it. IMO it makes it more confusing for the caller. Accessing a property should be cheap - but with computed properties you don't know it will be. Especially with caching as your example. The first access can be surprisingly slow with the next being much faster. I prefer things to not do surprising things when using them.

These are not quite equivalent. In terms of short-circuiting yeah they both short-circuit when they get the value. But the latter is returning from the current function and the former is not. If you add a return to that first example then they are equivalent. But then cannot be used in line. Which is a nice advantage to the former - it can be used inline with less faff as you can just assign the return to a value. The latter needs you to declare a variable, assign it and break from the loop in the if.

Personally I quite like how the former requires less modification to work in different contexts and find it nicer to read. Though not all logic is easier to read with a stream, sometimes a good old for loop makes the code more readable. Use which ever helps you best at each point. Never blindly apply some pattern to every situation.

There is also the BREACH which targets gzip/deflate compression on http as well. But also, don't see how that affects disk encryption.

Looks to be an exploit only possible because compression changes the length of the response and the data can be injected into the request and is reflected in the response. So an attacker can guess the secret byte by byte by observing a shorter response form the server.

That seems like something not feasible to do to a storage device or anything that is encrypted at rest as it requires a server actively encrypting data the attacker has given it.

We should be careful of seeing a problem in one very specific place and then trying to apply the same logic to everything broadly.

What is a fake port?

I have started using work trees recently as well, but have a different flow to the author and everyone else. I typically use two work trees, one on main that I do all my work on. That is work and create commits directly on the main branch.

But then to push I have another clean work tree that I use to create and switch branches on then use that to create working sets of changes by cherry-picking from master into different branches to push and create PRS from. And never edit files on this work tree so that I never have to stash anything.

Then just git pull --rebase=interactive origin/master to remove merged commits from master as they get merged upstream. This let's me build on pending PRs or switch to other tasks at will and just sort them into separate PRs as required.

I like this as when working on a feature I often find a refactoring I need to do, so can isolate that refactoring and create a PR with only that change while continuing to work on the feature on top of the PR.

Or have some temp debugging stuff locally that I want to use across changes that will end up in different PRs without having to copy paste them between branches.

I don't know, it does have official in the name tag. People would not lie about that. Right?