2,490 karma · joined July 7, 2008
https://www.varnish-cache.org/docs/trunk/phk/varnish_does_no...
Can anyone explain why such an accurate clock is helpful? I can see that it's needed if you create a document on the East Coast at about the same time as you create a document on the West Coast, and you absolutely need to know which was created first, but for most applications can't you just go with whatever time the system that got the insert thinks it is??
(I get that the format of the Cookie header is probably much more structured/predictable than usernames or account details that might appear in the body, but surely a good cryptosystem would be 100% resistent to these sorts of side-channel attacks, without any need to guess which headers need to be handled more carefully.)
I'm not sure what the "essentially" means here, but this is the first "big" program I'm aware of that name-checks TDD, and a counter-example to my theory that programs where much of the programmer effort goes into algorithms and data structures are not suited to TDD.
Was the TDD approach "pure"? (Only one feature implemented at a time, with absolutely no design thought given to what language features might need to be implemented in the future.)
(e.g. Stripe and others document their API in terms of curl commands: https://stripe.com/docs/api.)
I do wish the curl UI was better, but I can't see it being trivially replaced. (It's a similar issue with git: bad UI, but every git question and answer is described in terms of the CLI, so even if you prefer a GUI client, say, you still need to be able to formulate your problem in CLI terms for anyone on stackoverflow to understand you.)
I'm coming to believe more and more strongly that there should be a difference in the way writing library code, and writing code that uses libraries, is approached. (This applies to the use of design patterns, abstractions, and various other "best practices.")
In many cases, there's a big difference in both programmer quality and the amount of time spent on each line of code between library code and application code. And worse, most of the time, when programmers come across good code, it's library code, not application code. This leads programmers to think that library code--with its multiple abstractions and design pattern complexity--is the right way to do things, and so then then apply this approach, quite inappropriately, to their application code.
This bit is also interesting: "Runtime dependencies are found by scanning binaries for the hash parts of Nix store paths (such as r8vvq9kq…). This sounds risky, but it works extremely well."
"describe changes in imperative mood, e.g. "make xyzzy do frotz" instead of "[This patch] makes xyzzy do frotz" or "[I] changed xyzzy to do frotz", as if you are giving orders to the codebase to change its behaviour."
http://git.kernel.org/?p=git/git.git;a=blob;f=Documentation/...
https://github.com/torvalds/subsurface/commits/master
Even if I can't code like Linus, I can at least try to write commit messages like his…
Full quote: "When I saw Mike Daisey perform this story on stage, when I left the theater I had a lot of questions. I mean, he's not a reporter, and I wondered, did he get it right? And so we've actually spent a few weeks checking everything that he says in his show."
From http://www.thisamericanlife.org/radio-archives/episode/454/t... or http://webcache.googleusercontent.com/search?q=cache:www.thi...