Execute ruby code sometimes (little helpers to encourage variety)(github.com)
github.com
Execute ruby code sometimes (little helpers to encourage variety)
https://github.com/sudara/sometimes
5 comments
So, the code is like 15 lines and tossed together (currently using both Kernel.rand and Random, which is silly) — but I'd love ideas on how to make it better, how else to encourage unpredictable or more "human" behavior, other libs, etc!
When I think about creating lifelike responses, I tend to think of action potentials. Have a counter which tends to decay toward zero over time. When you attempt to do something, nudge the counter upwards. When the counter exceeds some threshold, do some behavior and the clear the counter. Note that this kind of mechanism is inherently stateful.
That said, I think that incorporating randomness or hidden variables into a user interface is rather misguided. Making a system harder to reason about takes control away from the user- it's basically an even more severe version of the problems with "Do What I Mean" in general.
That said, I think that incorporating randomness or hidden variables into a user interface is rather misguided. Making a system harder to reason about takes control away from the user- it's basically an even more severe version of the problems with "Do What I Mean" in general.
"Lifelike responses" — nice.
I like that "action potential" idea – I was trying to think of a good implementation for "do something twice a month per user" — decaying counter is a nice idea.
I'm with you on willy nilly making parts of your UI random — my use case is for changing up the text in greetings, general play with copy, and once in a while showing something like a tip or a "welcome back" message. Basically, small touches that convey a small sense of variety (vs. RANDOMLY DONT SHOW THE NAV!)
I like that "action potential" idea – I was trying to think of a good implementation for "do something twice a month per user" — decaying counter is a nice idea.
I'm with you on willy nilly making parts of your UI random — my use case is for changing up the text in greetings, general play with copy, and once in a while showing something like a tip or a "welcome back" message. Basically, small touches that convey a small sense of variety (vs. RANDOMLY DONT SHOW THE NAV!)
For printing varied text strings, what I've done is allow entries in the string table to have multiple text strings rather than just one. So if the code asks for the string GREETING, for example, rather than the string table code getting this one and only text for GREETING ("hello", say), it randomly picks one from the set (you might have "hello", "hi", "good day", perhaps).
Then whoever looks after the wording can just add as many strings as they like, for any messages they think could do with some variety. No forward planning required, because the code to do this is centralized, so it works for any string.
Then whoever looks after the wording can just add as many strings as they like, for any messages they think could do with some variety. No forward planning required, because the code to do this is centralized, so it works for any string.
The problem with using Random for displaying nice touches and reminder notices is that, well, it's random. It won't take very long for a user to get a rare and annoying "Have you thought about upgrading?" (or similar) message three times in a row, at which point they're likely to get annoyed.
I wouldn't worry about the implementation too much since, as you say, it is really very little code and easy for anyone to code up themselves.
What is awesome about what you've done is the idea and the interface. I'd focus on expanding that with more interesting use cases. For example it would be cool if this hooked more neatly into rails localization where I could say something like:
= t('some_set_of_possible_stuff.*')
Or whatever. I agree with the other poster who states it makes your app more hard to test however that is not a good enough reason to not do something by itself. It just means you need to be measured in how and where you do it and careful. In the right app, the value to the end user experience wrt personalization is super high so it is worth it.
What is awesome about what you've done is the idea and the interface. I'd focus on expanding that with more interesting use cases. For example it would be cool if this hooked more neatly into rails localization where I could say something like:
= t('some_set_of_possible_stuff.*')
Or whatever. I agree with the other poster who states it makes your app more hard to test however that is not a good enough reason to not do something by itself. It just means you need to be measured in how and where you do it and careful. In the right app, the value to the end user experience wrt personalization is super high so it is worth it.
It seems like this would be a particularly handy syntax for random behavior in game programming. I usually use `if random() < .15` as an idiom for "do 15% of the time", but this is way more readable.
> sometimes do
> rarely do
Are terrible for maintainability. Imagine that you are reading through the code of a programmer who used this library - What is 'sometimes'? What is 'rarely'? It would need to be documented on each usage to save half an hour of digging and cursing for the poor sap who encounters it.
> 1.percent_of_the_time do
For the same reasons, this would be better named "times_out_of_one_hundred" since The Time usually means a time of some sort being somewhere (i.e. the 21:43:21 type of time).
At least you foresaw some peoples' reactions to this:
https://github.com/sudara/sometimes/blob/master/test/helper....
> rarely do
Are terrible for maintainability. Imagine that you are reading through the code of a programmer who used this library - What is 'sometimes'? What is 'rarely'? It would need to be documented on each usage to save half an hour of digging and cursing for the poor sap who encounters it.
> 1.percent_of_the_time do
For the same reasons, this would be better named "times_out_of_one_hundred" since The Time usually means a time of some sort being somewhere (i.e. the 21:43:21 type of time).
At least you foresaw some peoples' reactions to this:
https://github.com/sudara/sometimes/blob/master/test/helper....
Agreed with all of that! Especially the poor sap who is reading the code wondering WTF...
So — my thinking for those two methods is to purposefully encourage being imprecise. We are always so obsessed with being exact in programming. And typically for good reasons. But in some cases, perhaps it doesn't matter if it's 50% of the time or 20% or 10% of the time. Just sometimes, not all of the time.
That being said, you bring up a fantastic point: what the hell does 'sometimes' mean? Half the time? What does rarely mean? It's certainly going to depend on the individual. No answers here, except I'm leaning towards redefining "sometimes" to mean between 15-50% of the time.
So — my thinking for those two methods is to purposefully encourage being imprecise. We are always so obsessed with being exact in programming. And typically for good reasons. But in some cases, perhaps it doesn't matter if it's 50% of the time or 20% or 10% of the time. Just sometimes, not all of the time.
That being said, you bring up a fantastic point: what the hell does 'sometimes' mean? Half the time? What does rarely mean? It's certainly going to depend on the individual. No answers here, except I'm leaning towards redefining "sometimes" to mean between 15-50% of the time.
Googling for ["sometimes do" ruby] returns this library as the 2nd result.
I do something similar, but only for historic reasons. Back when I started playing with unix (3 years ago), I was learning cron jobs and I had one output "yo" to me everyday at 651 PM.
My system Yo's me ever since.
My system Yo's me ever since.
[deleted]