DoubleFree

The postgres query optimizer will try to minimize the number of pages read from disk (and the number of intermediate pages written to disk). Benchmarking the query optimizer by making the shared buffers large enough to hold all the data therefore seems wrong, as you're then measuring the speed of the query optimizer and the join processor, instead of the quality of the generated query plans. It would not surprise me if the generated plans for these versions are actually all the same and this is only measuring execution speed.

A government's primary purpose is to act on behalf of its constituents, and if these daytrippers are substantially detrimental to Amsterdam's livability, they should be discouraged from going there.

Or, to put it in more financial terms, the cost of compensating for the negative effects of these tourists might be much higher than the tax revenue they bring in.

Fly postgres is not managed postgres, it's cli sugar over a normal fly app, which the [docs](https://fly.io/docs/postgres/) make quite clear. Their docs also make clear that if you run postgres in a single-instance configuration, if the hardware it's running on has problems, you database will go down.

I believe the underlying reason that precludes failing over to a different host machine, is that fly volumes are slices of host-attached nvme drives. If the host goes down, these can't be migrated. I _think_ instances without attached volumes will fail-over to a different host.

Of course, that's not ideal, and maybe their CLI should also warn about this loudly when creating the cluster.

I would substantially nuance most of what you say. I really like vim and use it almost exclusively, but it is not necessarily the "only" way, or even necessarily the "best" way to do things. If the vim grammar clicks for you, great, by all means use it. There are people for whom it doesn't click, and that's fine too. I do encourage everyone to try it for a bit.

I also would not say learning vim makes you a better programmer or a better writer. It makes inputting and changing text easier and faster, but that's not what programming or writing is about.

I agree that the vim grammar is nice, but the bigger thing that differentiates editing text in vim versus other editors is its modality. And it is the modality that allows it to have a grammar in the first place. And that grammar does break down in places, just look at every keybind starting with g.

So yes, try vim, because it is pretty great. But if it doesn't work for you, move on to something that does.

Space is not quantized, so yes, the electron has infinite possible locations. There are, however, places the electron cannot be, depending on its energy. See, the electron's energy is quantized, meaning it can only have a predetermined set of values (see atoms' electron shells). The energy determines the wave function and the wave function squared is the probability distribution for the electron's location. This wave function has roots, indicating where the electron cannot be.

I personally really like using Rust, but I don't think it's necessarily better than go. There are some areas where Rust will definitely be better or more ergonomic, such as bare-metal or low level systems programming tasks, but many other areas where Go's design works better and Rust will only hold you back (looking at you, borrow checker).

That said, I would still recommend learning Rust, because it will teach you about lifetimes and aliasing, even if you don't want to learn about them. When building for the web, I think Go's easier dynamic dispatch and GC will save you some headaches though.

Let's do a little calculation. For an upper bound, let's say you press your full weight onto it and the coffee grounds' resistance is not the limiting factor. That's maybe 90kg, times the acceleration of gravity, for about 900 newtons. That force is applied to a pi*(30mm)^2 or ~3^-3 m^2 area. That gives us a pressure of 900/3e-3 = 3e5 Pa or 3 bars.

Elderly people also use bikes and often transition to electric bikes or sometimes tricycles if needed. As other people have commented, public transportation in The Netherlands is also quite decent, so that also sees much use by the elderly.

std::thread::scope was reintroduced in 1.63

Rocket is moving towards async as well

There are some, the most promising of which to me are slint (runs anywhere, includes custom IDL), druid (from the xi-editor folks) and xilem (new architecture, from the druid folks)

They'll just have to remember that losing is fun

The problem of dangerous interactions between drivers and cyclists is much smaller here in the Netherlands, mainly due to two reasons.

The first reason is the infrastructure, both visible and invisible. Separated bicycle lanes are commonplace and in the few places where they intersect with car traffic, care is taken to make crossing safe and comfortable. This visible infrastructure is complemented by the concept of "Hoofdnetten", where the default routes to some place for different modes of transportation coincide for the least amount of time/space. For example, going somewhere by bike might take you through a residential neighborhood with barely any traffic, which is also slowed by speed bumps and narrowed streets, whereas buses will use a bus lane taking a slightly longer route, and car traffic has to go all the way around.

The second reason is that here, everyone is a cyclist. Going for groceries? Five minute bike ride, much easier and quicker than going by car. Kids cycle to school alone from a young age. Going out for drinks? Bike. Because everyone is a cyclist and there are cyclists everywhere, cyclists are equal participants in traffic and are treated with care and respect.

In general, you don't verify am email address to prove that the user owns it, but to verify they can receive mail on it, for password recovery purposes and account information. Reversing the process verifies the user can send from the address, which is orthogonal to the goal

Years ago I stumbled onto competitive Tetris because the YouTube algorithm pushed the Jonas vs Joseph match on me. I didn't expect it to be exciting, but it was actually captivating and I've followed CTWC (very) passively ever since. The excitement from the commentators is also very infectious.

It depends. For operations or aggregates on a single field, it improves cache locality, whereas if operations act on all, or most, fields of the struct, it hurts cache locality. The exact same tradeoff differentiates OLTP (transactional/row stored) databases and OLAP (analytics/column stored) databases.

The quote "Efficiency with algorithms, performance with data structures"[1] is very applicable imo.

[1] https://isocpp.org/blog/2014/12/efficiency-with-algorithms-p...

Matrix math in python is a bit clunkier, because matrices are not native to the language. That said, numpy, the standard for matrix math in python, is quite nice. Its documentation is, imo, miles ahead of matlab's and the APIs are a bit more sane.

K-9 Mail really is the grandfather of powerful E-mail apps, but I have switched to Spark a few years back when it became available for Android and never looked back. It's just a breeze to use. Sure, I have some gripes with it, but I really like the Google Inbox style of organizing my mail and keeping my inbox tidy.

I just use two or three drops of water from a pipette, which for some whisky really opens up the flavors. Most of the improvement for me comes in the form of mouth feel (it gets a bit more viscous and smooth) and in the nose. Anything more than a few drops will destroy these effects for me and just water the whisky down.

This reminds me of a blog post from Aleksey Kladov: https://matklad.github.io/2021/01/03/two-kinds-of-code-revie...

They state that reviews are not only meant to ensure good code, but also good coders. That means mentoring, but also merging the code if it's not perfect. Then, afterwards, when touching the affected part of the code again, cc the original author in a fixup PR. I have first-hand experience with this way of reviewing and I really like it.

I have been using tridactyl for the better part of three years now and it's pretty great. It has a feature similar to DDG bang search, where you can add your own search prefixes to search any site. The "hinting" is also very powerful and scriptable. I have used vimium in the past and it never clicked with me as well as tridactyl.

I find the interface of GitHub (and therefore gitea) much more usable than gitlab's. Gitea is also easier and lighter to self-host than gitlab. Gitlab's CI offering is awesome though and really makes it stand out among software forges. Honorable mention towards sr.ht which is very appealing to me because of its lightweight design and usage of email for "PR's" and issues and soon IRC for chat.

First things first, I think companies should be up-front with their customers. That means not marketing non-AI solutions as AI. However, lots of companies do not sell AI, they sell a service. And as long as that service is good, it should not matter to the customers if part of that process is manual, as long as you do not lie about it.

I am not saying this is the best way to handle things; it's just the way I interpreted the "MVP as mock up" idea.

I think the point here is that your MVP should behave like the actual product in the eyes of the customer, but you do not have to actually build the functionality. By providing a lot of the service manually, you can get your initial customers quickly. Having customers means getting feedback from the product's target audience. Getting this feedback before actually heavily investing in automating the product means when you do automate, you have a much better idea of what the final product should look like and which features you should prioritize, wasting less time and money on building the wrong things.

Compiler explorer actually supports running the binary now!

Does anyone know how Flutter fares when it comes to accessibility?

I believe one of the Dev sprints before 1.0 focused primarily on accessibility and there is a label widget that can wrap any widget to provide a name for screen readers.