Why should I care that the company is Swiss? The point of client-side encryption is that I don't need to worry about who's hosting my data or what jurisdiction they're under.
See, for example, Hushmail, which has no option but to cooperate with correctly formed legal documents. This means that they use the passphrase (which they can capture within a short time) of the non-java-applet version of their software, or they serve a modified applet.
Being in a different jurisdiction provides a small amount of protection.
I wonder if parent was merely advocating obfuscating sensitive data so that engineers don't accidentally see things like "Downsizing-2012.xls". As long as the obfuscation is reversible, the data is still there for those who need it.
Of course, encryption per se is overkill for that. Something like ROT13 would do the trick.
If you're going to obfuscate reversibly, it is much better practice to use strong obfuscation and log (irreversibly) any time the raw data is accessed so there is an audit trail.
The OP says that double-spacing is an obsolete holdover from the typewriter era, where the extra space made monospaced type easier to read. I'll go one further and say that spacing sentences using space characters -- any number of them -- is obsolete.
In the present era, the act of typing is separate from the act of typesetting. The comment I'm typing now may be typeset in Arial in Chrome, typeset in Ubuntu Mono in Emacs, or read aloud by a software program to a blind person. No prescribed number of space characters is going to be appropriate for all cases.
The reading software, not I, should be responsible for locating my sentence breaks and setting appropriate spacing there. Perhaps in the future we'll assist the software by marking up sentence breaks using a special character sequence. Ironically, a double-space would serve that function pretty well.
You don't like implied political correctness. OP doesn't like implied gender bias. I don't like grammatical convolutions like using "their". What's to be done?
That's the exact opposite of the situation. I pointed out that the founder is singular and female, but the "singular they" is used for indeterminate number and/or gender.
You're claiming that you can infer, just from a triple that I guess, whether I am attempting to confirm or refute the "ascending even numbers" hypothesis. But if I guess (2,4,6) and learn that it doesn't adhere, that's as much a refutation as if I guess (1,2,3) and learn that it does adhere. (2,4,6) looks like an attempted confirmation to you only because you have prior knowledge that the rule is not more specific than "ascending even numbers".
So I suppose it would be more accurate to say he is testing whether you adequately attempt to falsify your theory. If you only attempt to falsify it by finding false positives, but never false negatives, you are not doing it with sufficient rigor.
Is there an objective metric according to which guessing only positives is a less rigorous strategy than guessing both positives and negatives? Given no prior knowledge about the space of possible rules?
I'm currently appealing a similar rejection of an auto-renewing subscription app. Here's the rejection:
We found that the Purchasability Type for one or more of your In-App Purchase products was inappropriately set, which is not in compliance with the App Store Review Guidelines.
Your In-App Purchase is currently an Auto-Renewable Subscription. However, it would be more appropriate to use the Non-Renewing Subscription In-App Purchase type. Auto-Renewable Subscriptions are intended for periodical apps, such as magazines and newspapers. Non-Renewing Subscriptions should be used for products that are not appropriate for Auto-Renewable Subscriptions.
Nothing in Apple's documentation hints that Auto-Renewable Subscriptions are more appropriate for one class of app than for another, so I was hoping that my reviewer was acting on some subjective, high-level guideline that I could argue on. However, it's beginning to look as if there is a specific, unwritten policy against non-periodical apps.
Apple would do a big favor to developers by being a bit more open and transparent with the regulations.In your case this will probably be the relevant guideline that they may cite.
> 11.9 Apps containing "rental" content or services that expire after a limited time will be rejected
It seems that Apple's review team has interpreted SaaS to fall under this guideline.
Couldn't a system with N supervisor-actor relationships be rewritten as a single process with N try/catch statements, where the catch block simply logs the exception and jumps back to the start of the try block?
I haven't used Erlang, so the two patterns seem roughly equivalent. I've even heard exception handling referred to as "happy path programming" by way of contrast to return value handling.
In the common case, selling someone $50,000 of licenses is a $50,000 win for the company.
That actually sounds like a very uncommon case. Even fully client-side software has variable costs in the form of support costs.
Support costs aren't relevant to your parent's example, but they do imply another misalignment of incentives. If a salesperson's commission is based on revenue alone, she'll just as soon sell to a costly, high-maintenance customer as to a profitable, low-maintenance one.
This is also a wrinkle that comes up managing sales organizations, which is why sales account managers often get different comp rates for different products.
Again, just two issues I have here:
(1) Dev incentive comp and sales incentive comp aren't particularly comparable.
(2) Huge compensation for the best sales managers is an economic reality, not a philosophical issue, and if you're not going to compensate variably, you're shifting a lot of risk from the sales manager back onto the company.
