834 karma · joined May 14, 2009
Edit: This looks pretty great, but I should probably point out that it turned my 5.5 mile commute into a 8.5 mile one. Realize it's probably trying to avoid larger streets; Hope this is or becomes configurable.
Yeah, I'm now a better player than most at work, but I wouldn't say work games aren't interesting to me. I have so many fundamentals to work on! It can be a challenge for me to even consistently hit a ball back in a way that a novice can continue the rally (especially when dealing with a trickier shot).
I definitely think the higher level games are crucial for success, too; I just find that I get some value out of almost any game (if I look for it).
I don't know if the gaze detection can be fooled by a corpse with its eyes open, but supposedly Face ID checks for body temperature as well.
I see that there tags, categories, and budgets. I understand the differences between these, and why they are presented as different concepts. How did these different features evolve? Did you have budgets first, then categories/tags? Did you ever consider implementing categories as tags and not having a separate category concept?
Just wondering if what you have now evolved from a simpler model (at least fewer concepts—maybe not simpler implementation or mental model), and if so why/how.
For what it's worth I had the choice to pay a bit more to get a different Leaf that had a new battery (replacement under warranty). Given that I don't drive much (6 mile commute), I figured a slightly healthier battery is probably not going to be as useful to me, and the car/battery will deteriorate from age before mileage is as much a factor.
I noticed when reading the reviews that what seemed to be a common complaint was that the randomization would repeat an exercise type too often. Now, I know you've fixed this because I just spent five minutes reading the release notes for every release in the last year--but if you used the ability that Apple added to reply to these reviews, then someone wouldn't have to do that in order to figure out if the issue was addressed.
That said, I suspect the example would be much faster if you didn't use the pipeline, because a single tool could do it all (I'm leaving in the substitution and column print that are actually unused in the result):
awk '/^x/{gsub("a","b");print $2; count++}END{print NR}' foo.txtWhat’s often lacking though is a clear path for reporting security issues to people such as this representative. They don’t have a process to flag something for the security team.
I wonder how this feature came to be? What were those meetings like?
* Always make a way to examine the data that's coming in (over network, arguments, whatever) to make sure your code is receiving the input it expects, and to be able to predict output/state changes.
* Similarly, have a way to see the data/state changes produced by what you wrote.
* Don't log all this by default.
* ...except for unexpected outcomes. By all means, check your inputs and loudly complain if they are garbage in a way that's unrecoverable.
* Be judicious about how much of this you normally expose to a user; don't overwhelm a user with unactionable noise.
Edit: this is in response to your asking for feedback about categories/demand.