avg_dev

> “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.

> But `timeofday()` is not volatile, so `DEFAULT timeofday()` is going to lock the table for a long time.

Perhaps the “not” was a typo?

> Many other useful performance improvements, including the ability to avoid a table rewrite for ALTER TABLE ... ADD COLUMN with a non-null column default

https://www.postgresql.org/docs/release/11.0/

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.

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.

That’s my take anyway.

I wouldn't use the advice in this article. It's quite old and the stdlib now has support for new stuff via error wrapping.

> As Julie says when someone repeats that Amazon was started in a garage: Ain't no garages in the trailer park.

Not sure who Julie is, but I think she's spot on.

interesting site.

especially the sense of humor... like on gif

(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!")

If you happen to use Postgres, the approach is ultimately portable: it uses Pg database templates (also, regarding perf, the author recommends using a ramdisk and turning off fsync on your test DBs; you'll see this in the project readme). But you’ll have to write the code yourself.

I do think this is a level of indirection myself; if the generated code was perfect and always in sync, that would be one thing, but by definition it is not the case.

i often think of software as a series of problems. i don't have to worry about solutions initially. when we have polished off solutions to all of the truly immediately important problems - within some reasonable/useful level of engineering tolerances - the software can be thought of as done, for a time. just my opinion.

> 00:04:51 GET /w/atom.xml, unconditional.

> Fulfilled with 200, 502 KB.

> [...]

> A 20 minute retry rate with unconditional requests is wasteful. [...]

And If-Modified-Since makes a request conditional. https://developer.mozilla.org/en-US/docs/Web/HTTP/Conditiona...