if a test is flaky, but it covers something useful, it should be made not flaky somehow. if tests are slow, but they are useful, then they should be optimized so they run faster. if tests cover some bit of functionality that the software no longer needs to provide, the functionality should be deleted from the code and the tests. if updating a small bit of code causes many tests to need to be adjusted, and that's a pain, and it happens frequently, then the tests should be refactored or adjusted.
> Confidence is the point of writing tests.
yes, agreed. but tests are code, too. just maintain the tests with the code in a sensible way. if there is something worth deleting, delete it; there is no gospel that says you can't. but tests provide value just like the author describes in the "fix after revert after fix after revert" counterexample. just remember they're code like anything else is all and treat them accordingly.
I experienced this when working at a giant company where all the teams were required to report their "code coverage" metrics to middle management.
We had the flaky test problem too, but I think another angle of is being shackled to test tech-debt. The "coverage goals" in practice encouraged writing a lot of low quality tests with questionable and complex fixtures (using regular expressions to yoink C++ functions/variables out of their modules and place them into test fixtures).
Fiddling with tests slowed down a lot of things, but there was a general agreement that the whole projected needed to be re-architected (it was split up over a zillion different little "libraries" that pretended to be independent, but were actually highly interdependent) and while I was there I always felt like we needed to cut the Gordian knot and accept that it might decrease the sacred code coverage.
Not sure if I was right or what ever happened with that project but it sure was a learning experience.
I believe PostgreSQL does this since v11, which was released in 2018: (current is v17)
> Many other useful performance improvements, including the ability to avoid a table rewrite for ALTER TABLE ... ADD COLUMN with a non-null column default
I think there is some restriction there, like the default can't be "volatile" - I can't remember the precise definition here but I think current_timestamp would be volatile, but any static value would not.
That is correct, for non-volatile default values Postgres is quick, which means that it is generally a safe operation.
Also interesting, `now()` is non-volatile because it's defined as "start of the transaction". So if you add a column with `DEFAULT now()` all rows will get the same value. But `timeofday()` is not volatile, so `DEFAULT timeofday()` is going to lock the table for a long time. A bit of a subtle gotcha.
I really enjoyed this article. I liked what the person had to say about “care” especially, and the sort of crappy scarf that his mother-in-law still loved.
I’m both an amateur musician and a professional coder.
Definitely IMO code is a real physical thing that produces tangible results. (I personally think that code operationally is a physical thing, down to basics like logic gates and stuff. We abstract far away from that with high level languages but even making a pixel change colors is inherently, to me, altering physical reality)
But the experience of writing code and making music with your body is such a different one. You will feel and think about the code in a more imaginary and thoughtful way (you could write all your code in a notebook or a text editor and you would just be writing or typing on a keyboard) whereas the music (I play a wind instrument) is a tactile experience in the sense that it will physically be something you hear and you can actually feel the vibrations in your body; I might be wrong but I think that is what hearing is. And there is a real bio-feedback thing going on because you use your body to physically make it happen and you get immediate or very near immediate feedback (auditory, etc. You may even hear or see feedback from other musicians or even listeners). It’s just a viscerally different experience.
There’s nothing fake about seeing metrics on a dashboard or tests going from red to green or money or bits of data flowing around, at all. But it is experientially much different from the feeling of playing an instrument.
tbh i don't feel like the people who scheduled a 10 min meeting did anything wrong. the room is marked as free during that time; they know they will be done in 10 mins; it's a shared resource... what's the point of a schedule for a shared resource if people don't respect it?
I scrolled too far down to find this... Perhaps it's selection bias, but surely there are others that see it this way?
I do have empathy for the people in the room who expected to have 10 more minutes for there meeting, and I'm not a pedantic rule follower, but I expect some grace and self awareness here.
Yes, your meeting was unexpectedly interrupted, but my meeting was unexpectedly delayed. Your problem was caused by a system that—however unfair or inscrutable—we all have to conform to. My problem was caused by ignorance, accident, or malfeasance on your part. If I show respect and empathy in this situation, I expect you show some respect and humility.
just a quick response, i have asked a few Go questions that he (ILT) has answered on public forums. i don't work at google and never have. but he was clear and thoughtful with me. most of all, he was helpful.
basically they separate the compute and storage into different components, where the traditional PG use both compute and storage at the same server.
because of this separation, the compute (e.q SQL parsing, etc) can be scaled independently and the storage can also do the same, which for example use AWS S3
so if your SQL query is CPU heavy, then Neon can just add more "compute" nodes while the "storage" cluster remain the same
to me, this is similar to what the usual microservice where you have a API service and DB. the difference is Neon is purposely running DB on top of that structure
So how is this distributed Postgres still an ACID-compliant database? If you allow multiple nodes to query the same data this likely is just Trino/an OLAP-tool using Postgres syntax? Or did they rebuild Postgres and not upstream anything?
You're welcome. I think for the write part, it's always back to the old classic consensus. In then end there always that distributed voting mechanism to decide the write order
It's only serverless in the way it commits transactions to cloud storage, making the server instance ephemeral; otherwise it has a server process with compute and in-memory buffer pool almost identical to pg, with the same overheads.
You shouldn't be getting downvoted. Serverless is nothing more than a hype which is meant to overcharge you instead of running it on a server owned by you
That's a reductionist view of a technical aspect because of the way the technical aspect is sold. Serverless are VMs that launch and turn off extremely quickly, so much so that they open up new ways of using said compute.
You can deploy serverless technologies in a self hosted setup and not get "overcharged". Is a system thread bullshit marketing over a system process?
> “it is blasphemy to delete a test”,
was ever a thing. i still don't.
if a test is flaky, but it covers something useful, it should be made not flaky somehow. if tests are slow, but they are useful, then they should be optimized so they run faster. if tests cover some bit of functionality that the software no longer needs to provide, the functionality should be deleted from the code and the tests. if updating a small bit of code causes many tests to need to be adjusted, and that's a pain, and it happens frequently, then the tests should be refactored or adjusted.
> Confidence is the point of writing tests.
yes, agreed. but tests are code, too. just maintain the tests with the code in a sensible way. if there is something worth deleting, delete it; there is no gospel that says you can't. but tests provide value just like the author describes in the "fix after revert after fix after revert" counterexample. just remember they're code like anything else is all and treat them accordingly.