It's mostly because it's was a different scarce resource at that time that was seen as non-optimal use by the players, the courier. It can ferry item to you, in a normal game there was only one of them for your whole team, which mean using it would take that ability away for your teammate during the ferry time.
One constraint to those showmatches at the time was that every heroes had their own courier, and player at that point were not accustomed to using it for "low value" travel, unlike the AI that was using it liberally.
In a later patch, the 1 courier per hero feature was added, and now pro players are much better at managing it, but at that time it was truly a heavy opportunity cost.
The thing is even locals will have a greater time during the nicer times. Using Montreal, where I was living until a few years ago, is a much nicer place to wander around when there's no snow. It's a colourful city, lively and full of small and big activity to do, so you can get by with the sort of tourism you described in high season (summer), but also end of spring and early fall.
In the winter, it's a cold, wet and relatively low interaction time of the year. I assume some place have a high, low and dead season for tourism, and I personally aim for low, but to each their own. Quebec in general is a great place for winter vacation, just have to go outside Montreal island.
When an entry can belong to 0 or 1 related object only. Not that I'd put a constraint in such scenario, but I imagine a User can optionally have a Subscription, so subscription_id is either nil or present, and said subscription cannot be associated to any other User.
The foreign key only gaurantees that the other entity exists.
The unique constraint ensures that only one pair of entities has this relationship, preventing a one-to-many binding.
The distinctness of NULL allows you to have multiple entities with the same NULL value without violating the above UNIQUE constraint.
The "NULL is empty" vs "NULL is unknown" is a series of trade-offs of labor-saving. Imho, the wrong trade-offs were made, but once the choice is made it makes sense to continue and be consistent with it. I'd rather be consistently wrong than inconsistently right.
Double quotes allow you to do string interpolation, which is not possible with single quotes. So I assume one faction argues that everything should be double quoted because it's does not matter if there's interpolation or not, while the other group would rather only use double quotes when necessary, otherwise use single quotes.
I'm personally part of the second group simply because my linter forced it, but at the end of the day, it's such a low impact we don't really care.
> would rather only use double quotes when necessary, otherwise use single quotes
So in that case, they're not used randomly according to the individual user's preference. There's a consistent rule. It's helpful for readability, too. And not sure about Rubocop in Ruby, but many linters in other languages can pick up on these different applications.
Generally in ruby/rails, the people in favor of double quotes would use double quotes all the time.
Rubocop would have you use singles for non interpolated and double for interpolated.
I get that there is a potential to catch some kind of error where you use double quotes on a string that will interpolated something which it wouldn't if it were in single quotes. In 12 years, I've never had that happen. I have, however, had it happen dozens of times where I changed something from interpolated to not and then I have to bounce over to change the quotes. This happens a lot and is annoying.
It's also an eyesore when you have an array of messages, each neatly aligned, but some are interpolated and some aren't, so the quotes change.
In Ruby, knowing that a string has interpolation is easy enough by seeing the #{} in the middle of it. It's hard to miss, really.
The single/double quote cop which is turned on by default is also counter to the existing style of every-string-is-double when it came along.
interpolation isn't the only difference between single- and double-quoted strings. If you need control, etc., characters via backslash escapes, you must use double (or semantic equivalents like %/%Q). If you need non-eyesore strings with literal backslashes, you need single (or semantic equivalents like %q.)
irb(main):001:0> puts '1\t2',"1\t2"
1\t2
1 2
> In Ruby, knowing that a string has interpolation is easy enough by seeing the #{} in the middle of it.
One constraint to those showmatches at the time was that every heroes had their own courier, and player at that point were not accustomed to using it for "low value" travel, unlike the AI that was using it liberally.
In a later patch, the 1 courier per hero feature was added, and now pro players are much better at managing it, but at that time it was truly a heavy opportunity cost.