Heh,
how about forcing LaLiga to show evidence about damages? Because surely everyone who pirated their content would have paid if free streams weren't available, right guys???
Heh,
how about forcing LaLiga to show evidence about damages? Because surely everyone who pirated their content would have paid if free streams weren't available, right guys???
If you want the magic explained, here's a start: https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch
Well, what problems are you trying to solve by having the classes all access each other's data members? Why is that necessary?
Not only is that headline's grammar exceptional(ly bad), for a moment I thought the developer of Control was named Alan Wake. Like, how did they manage to butcher that so badly?
Because you don't need to have significant experience or rent a VPS in order to do that, and I can respect that. We don't need to force FOSS developers to become proficient in everything.
What needs to happen is some kind of tool (ideally FOSS) that lets you spin up an actual forum with the same difficulty to set it up as Discord.
Huh, TIL.
Regarding your edit, that amount wasn't the cumulated cost of whatever Limewire were distributing, that would be idiotic indeed; rather the RIAA tried to call for a ruling that somehow those guys were causing $150,000 in damages - per instance. Now the article unfortunately doesn't state how they possibly tried to justify that number, and I can't be bothered to research that myself. Another thing that would interest me is how the plaintiff expected them to pay with almost every dollar on Earth.
So while I don't think this had anything to do with "lost sales", I do agree with the possible fines and damage calculations not being fit for any sort of realistic purpose at all.
Wow, writing the same paragraphs three times... What an abomination of an article.
On a serious note, they shouldn't have been so greedy then and waited until prices had fallen again... This looks exactly like the dotcom bubble crashing because investors just couldn't hold their horses.
I don't really like including pedestrians in there. Like sure, you can fit a bunch of people in a small area, but another point you shouldn't ignore is the throughput over time, and pedestrians are by their nature rather slow. Obviously if you're looking at shopping in a street lined by shops left and right, then that street becomes tailor-made for pedestrian traffic (and nothing else except perhaps bicycles). But public transport is much better suited for travelling any further distances, and that should be the main focus when deciding to ditch cars.
Funnily enough, in D&D 5E that wizard explicitly can cast that spell (if you're equating Power Word Kill to Avada Kedavra)
That's something I would disagree with though. "Sticking with plain HTML and CSS" is way more work, and often has significantly less functionality, than building a website with a framework.
There are two different things mentioned here, which I feel I need to clarify:
First, what you said about merging / creating a PR with broken tests. Absolutely you shouldn't do that, because you should only merge once the feature is finished. If a test doesn't work, then either it's testing for the wrong aspect and should be rewritten, or the functionality doesn't work 100% yet, so the feature isn't ready to get merged. Even if you're waiting for some other feature to get ready, because you need to integrate it or something, you're still waiting, so the feature isn't ready.
At the same time, the OP's point about tests being supposed to fail at first isn't too far off the mark either, because that's precisely how TDD works. If you're applying that philosophy (which I personally condone), then that's exactly what you do: Write the test first, checking for expected behaviour (which is taken from the specification), which will obviously fail, and only then write the code implementing that behaviour.
But, even then, that failing test should be contained to e.g. the feature branch you're working on, never going in a PR while it's still failing.
Once that feature has been merged, then yes, the test should never fail again, because that indicates a new change having sabotaged some area of that feature. Even if the new feature is considered "essential" or "high priority" while the old feature is not, ignoring the failure is one of the easiest ways to build up technical debt, so you should damn well fix that now.