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 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.
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?
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.
how is the webauthn story for FF? I recall that some hardware tokens could sometimes play weird with FF on Mac, I am not sure if Windows had the same thing. that was one practical advantage Chrome had.
(and a bunch of people seem to be interested in the "IP" note, but I took as, just trying to not get run into legal trouble for advertising "here's how you can 'steal' models!")
> “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.