A tax wouldn't stop spam - spammers don't send the emails from their own email accounts, they send it from Joe Average's computer which has been taken over by malware.
If you don't want spam, get a good filter (I barely remember what spam looks like since moving to Gmail). Every time someone does this, the return for spam diminishes. When the return becomes worth less than the hassle, it'll decline.
I don't use anything more complex than a bookmarking service (delicious) to tame my personal chaos, and I'm the most chaotic person I know by a couple of orders of magnitude, literally.
Sorry Alberto, but a lot of that is context-specific advice given as general advice.
1) 'days', 'temp', 'data', etc are perfectly valid variable names in context. I'm gobsmacked that anyone can think 'temp' is a bad variable name.
3) A comment next to one instance of the variable is not sufficient - would you be happy working on code where the variable names are 'a', 'b', 'c' etc., with or without a comment in one particular place? I wouldn't.
4) I'll leave aside the eternal debate over hungarian notiation, and just point out that 'red_apples', 'yellow_apples', 'green_apples' etc would more properly be
'apples_red', 'apples_yellow', 'apples_green' etc. Least specific differentiators first.
5) Negative names are fine, in context. I don't find it any harder to parse 'disabled' than '!enabled'. I find it more distracting to have the redundant 'is' in the variable name, and it's only ever correct in some contexts. Even if I were to concede the point of polarity, "if disabled" is less of an obstacle than "if not is enabled".
Then there's the issue of default - I find it much clearer in the wider scope to label the variable according to exception. For example, if a setting is enabled in 99.9% of cases, I'll use 'disabled' as the variable. If the majority is disabled, I'll use 'enabled'. This links the variable name with the intent more clearly.
7) I'm sure on occasion there's a good reason to have two identical types with different names instead of one type with a property to differentiate the two, but that ain't it. Changing the property of the item represented should map cleanly to changing the property of the variable. Your way would have you copy one type of variable to another in order to change the property. "Order->approved=true", or better still let Order do the work itself for extensibility with "Order->approve()", but not "approvedOrder = nonApprovedOrder; nonApprovedOrder = null;". Gah!
That's not an acknowledgement - that's a pitiful attempt to deny that the data they have is worthless, and that they damn-well know it.
And then there's apologists such as yourself - trying to tell me that actually Time did 'detect and extinguish' the hack attempts as they claim, but that real users still voted the same way as the disabled hack had attempted to. Purlease. Did they also manage the additional, 20 character message organically too?
Or, he knows full well but thinks that holding the population steady at 'too many for the world to cope with' is an issue that still needs addressing...
Nice to see someone who gets noticed pointing it out. The blindingly obvious shouldn't need pointing out by anyone, of course, but hey, people as a whole are mind-numbingly stupid.
Dear rubists: The move to Scala is besides the point, the battle is long over. Ruby on Rails is not scalable. End of. The beacon of scalability you hold up for us to gaze at in awe, Twitter, fixed just about all of its scalability problems with SQL caching. That's SQL caching, also known as 'bypassing Rails'. If you can't reduce the known facts to this obvious conclusion, you have no business arguing about scalability.