tom-lord
Joined 11 years ago
Joined 11 years ago
I'm guessing the idea is similar to .London, .NYC, .Amsterdam, ... i.e. it would be used for a geographic indicator/market.
Unfortunately however, there are a lot of grey areas... To name a few:
* Amazon have been in a long dispute with the Brazilian government, over the right to operate a .amazon TLD - as the Brazilians claim it should instead be related to the rainforest.
* On the other hand, Amazon have secured TLDs such as .prime, which could also be disputed. Apple have won .apple, Sky have won .sky, ... the list goes on.
* Sometimes, the conflicts can even be with foreign languages. For example, Ferrero are now the registry operator for .kinder - but as this is the German word for "children", it's been the cause for similar debate.
Also, with regards to your concern that there is a lack of variety in available unrestricted TLDs - I disagree; if anything, there are far too many (there's hundreds!!).
Shell scripts are guaranteed to be runnable on all machines.
Unfortunately the shell "language" sucks, but still...
At least in some regexp engines, this is possible. There is a concept of possessive (as opposed to reluctant, or as it's often called, "non-greedy") quantifiers. Given the string "abb", consider the following regexes:
/[ab]+b/ -- matches "abb"
/[ab]+?b/ -- matches "ab"
/[ab]++b/ -- DOES NOT MATCH!! (Because there is no back-tracking.)
More info: http://www.regular-expressions.info/possessive.html
One regexp engine which implements this (see section 4): https://raw.githubusercontent.com/k-takata/Onigmo/master/doc... -- this is the engine used by modern Ruby versions.
I currently work in a small-ish company, where I am the ONLY person designing/developing multiple systems. (I do get some input now and then, but it's mostly all down to me.)
I like this idea in principle, but you don't always have the resources to achieve this!
[1] pry(main)> 10..100
=> 10..100
[2] pry(main)> (10..100).class
=> Range
[3] pry(main)> (10..100).to_a
=> [10, 11, 12, 13, 14, ..., 99, 100]The implementation of a ruby hash is now as a doubly linked list [0]. This has inevitably caused a slight performance hit, but the benefits far outweigh the cost IMO.
[0] https://www.igvita.com/2009/02/04/ruby-19-internals-ordered-...
* No comparison with other countries, and their respective policies.
* No data on where these students graduate from, or in which subjects, or with which grades, or what their average salary is X years later, or whether they'll actually be able to pay back the loan.
It's missing a huge amount of important information; you really can't justify the conclusion "tuition fees are good" from this alone.
95% of the time, yes. However, the "official" rule is simply that such methods must return a value that can be EVALUATED as true/false. There are plenty of methods in the ruby core/standard library which end in a "?" but do not return true/false, such as:
* File#size (http://ruby-doc.org/core-2.2.3/File.html#method-c-size-3F) returns Integer or nil.
* Integer#nonzero? (http://ruby-doc.org/core-2.2.0/Numeric.html#method-i-nonzero...) returns self or nil.
This misunderstanding of what "?" methods are allowed to return is an ongoing problem in the community, e.g. https://github.com/rails/rails/issues/20110