There are multiple name suggestions when:
(1) Multiple items are being replaced and each replaced item had a different name.
(2) There would be a name collision. To resolve the collision, either one or the other variable can be renamed.
63 karma · joined October 21, 2011
[ my public key: https://keybase.io/brianhempel; my proof: https://keybase.io/brianhempel/sigs/EDzJfzCMT37hI9g7tQUuQwOFIaKtcMRQIf4kQNoEyP8 ]
There are multiple name suggestions when:
(1) Multiple items are being replaced and each replaced item had a different name.
(2) There would be a name collision. To resolve the collision, either one or the other variable can be renamed.
Copyright divestment by failing to put a proper copyright notice must happen with the "consent of the copyright owner". The song in the 1922 songbook said, "Special permission through courtesy of The Clayton F. Summy Co." without the appropriate copyright notice. The lack of proper copyright notice would have released it to the public domain (proper notice was included on other songs in the songbook). However, Warner/Chappell claims that Summy didn't own the copyright in 1922: the songbook asked the wrong people for permission.
"There is no evidence that the Hill Sisters (Jessica or Patty) granted anyone the right to publish the Happy Birthday to You! lyrics until 1935. The evidence instead shows that Summy sought and obtained a license to publish the Happy Birthday to You! lyrics from Jessica Hill in 1935."
As circumstantial evidence, Warner/Chappell also points out that in earlier court battles in the 30s and 40s the copyright holders never indicated that there was any authorized publication before 1935.
Warner/Chappell doesn't address the filmmaker's claim that a 1922 publication would put the song into the public domain in 1997. I'm confused here: Would the publication have to be authorized for the 1997 date to hold?
Filmmaker's request for summary judgement: http://www.scribd.com/doc/272751583/Birthday-Evidence
Warner/Chappell's response: http://www.scribd.com/doc/272870978/Warner-Chappell
Most browsers these days implement window.crypto.getRandomValues() so you could use that and do the generation client-side in Javascript. That way, I don't have to trust that you're not storing these passwords in preparation for a later attack.
1. Browser-encrypted so the server cannot decrypt it. The decryption key is stored in the URL fragment after the # so the server never sees the decryption key. (Fragments are not sent in HTTP requests.)
2. Secrets never touch disk. SneakyNote.com even goes to lengths to clear the in-memory buffers on storage/access.
3. Verified delivery. If you're going to send the link over an insecure channel, you can't prevent someone else from getting to it first. But you'd like to know if they replaced your link. The verification code step solves this problem.
4. Open source.
Incidentally, this is written in Go because it of its good HTTP support and because Go is a memory-safe language that will also allow you to clear memory.
Other reasons for "shoot to kill" relate to effectiveness: in the energy of the situation if you aim to wound you may either kill by accident, or not hit at all.
For example, if you search for "Bob Peterson", Postgres will rank these two documents the same:
"I saw Bob."
"I saw Peterson."
In contrast, an IDF-aware search would notice that "Peterson" occurs in fewer documents than "Bob" and score "I saw Peterson" higher for that reason.
[1] http://en.wikipedia.org/wiki/Tf%E2%80%93idf
[2] http://stackoverflow.com/questions/18296444/does-postgresql-...
Also, technically, it's a Ruby benchmark. The Rails version is going to be locked to 3.1.3 for as long as possible. The benchmark does not reflect speed improvements in the Rails codebase.
Though, yes, Rails serves less requests per second than many other things: http://www.techempower.com/benchmarks/
A micro-benchmark suite is better than a few micro-benchmarks, but really I would like a suite of real-world micro-applications.
I'm willing to add more benchmarks so it's not just Rails, but I simply don't know what to add.
Pretty graphs here: http://www.isrubyfastyet.com/ (I run a nightly benchmark.)
I will add 2.1.0 right now and hopefully we will have confirmed data in the morning.
EDIT: You mention 20% improvement on Rake tasks. Simple Rake tasks are dominated by Rails' startup time. My benchmark reads about a 15% improvement in startup time, which agrees with what you are saying.
However, the 1.9 series was a significant step back from 1.8.7 for out-of-the-box Rails startup time. Ruby 2.0.0 pretty much matched Ruby 1.8.7. Now with 2.1.0, Ruby is finally categorically faster than 1.8.7 for starting Rails. (Rails itself has also made improvements; but my benchmark has been locked at Rails 3.1.3)
"Download Samples Now" on this page: http://www.idc.com/MarketScape/index.jsp
To all would-be language designers out there: Are you aiming to fix a perceived language deficiency or a problem-solving deficiency?
C, Perl, etc. are abstractions of the problem of programming, not the problem of writing assembly.
In contrast, HAML is an abstraction of the problem of noisy HTML, not an abstraction of the problem of page layout.