What I'm not getting: If Project Gutenberg is US based, how can they be dragged in front of a German court at all? How could a German court enforce anything on a US based entity? So couldn'd PG's response just have been to ignore the case? What would have happened then?
This is going to be a dumb question I fear...
If, as the article says, photons can't travel through a vacuum how are we able t see the stars (let alone distant galaxies)? Is it just because space isn't enough of full vacuum, or what am I missing?
I know it's not exactly HNewsy, but I felt the need to upvote this because, frankly, this made me smile and also I am highly sympathetic to this sentiment right now.
If it's just about having a usable safe, it's an easy decision. They just need to decide whether the cost for the locksmith is worth it for them to have a usable safe...
If it's about what might be in there... shouldn't it be fairly easy to drill a small hole (given the right type of drill) and use a miniature/endoscopic camera to take a look?
So? You still have the hole and can peek inside to see if is empty or not. And if it's not then get it out and sledgehammer it in your garden, just for fun, then sell it to your local junk yard.
On the other hand, that you want to use it, then design your own robot and try all combinations. There is no time constraint since you're the owner, no need to "finish in 3 days"
Programming Windows 5th Edition by Charles Petzold, still commands a price on eBay for its Win32-centric program development strategy. IIRC 6th edition used C# .NET and 7th and 8th went all in on UWP.
Just noticed that the 5th Edition is still available on Kindle (at least on Amazon Australia) and is a lot cheaper than I expected it to be. The hardcover edition is still very expensive there though.
Somehow, the examples all sound more like a quality and/or testing issue. The workflow seems prone to people rebasing to a buggy state and at that point, in a non-trivial system, all bets are basically off. Basically I need to be able to have a "JTB" about a pull request having undergone enough review and testing before being merged on the master that it doesn't introduce such glaring regressions as cited in the examples.
If that cannot be ensured, I'm setting myself up for one goose chase after the other...
> The interesting thing here is that the common response here is: "Hey that's a great theory, but in real life, I just paid off my mortgage with my proceeds from bitcoin."
Mortgages have been payed off with lottery wins. That doesn't make lottery tickets a good investment.
You are both correct and wrong: I want X/0 to immediately crash (fatal error) before the bad data that caused my to try to divide by zero gets propagated farther. Now that I think about it, I really want X/Y where Y is "close" to 0 to crash too.
Of course I made the above up on the spot, but it is a reasonable thing to do for some situations. Those who know floating point math are well aware that dividing by something close to zero tends to result in very large errors, vs the true answer. (particularly if the division is part of a larger calculation)
I think what the above returns depends on the language. In java I think there is an actual run time exception for this. The point of the original comment is to show how 100% coverage is easy to achieve but often meaningless.
There is some other more abstract concept related to the classes of input that can possibly be passed to a method. IMHO 100% coverage and "test first" have done more harm than good to the cause of automated testing.
The point is being certain I haven't missed an edge case somewhere.
The hard part is the percentage rgb() values, of which there are technically an uncountably infinite number (since any real number in the range 0-100 is a legal percentage value). For those I generate all 16,777,216 integer values, and verify that converting to percentage and back yields the original value.