Okay, so my User models are able to 'spend' points to give karma (arbitrary points) to other users - each time the User gives a point, their karma_amount is decremented, as you might expect. I'd been originally planning on making it so a user couldn't give karma to another user more than once, but then I thought that it would be cooler to have a finite stock of points that replenishes, by say 1 point every two days.
I'm not quite sure how to accomplish this though - if it was a Ruby script on my machine, sure, but does anybody have any tips having tried something similar in Rails?
My other concern is that if every user has a ticking clock on the live app that'll slow the whole thing down. I guess what I'm asking in a nutshell is: what is the 'Rails-y' way of doing this? Naturally I'd rather find something robust or elegant than just hacking away.
Thanks very much.
You want something that run every period of time (two hours in your example). The operation itself (replenish_karma) could be a simple controller action (be sure to restrict its access, still), then you just need to be sure to call it on a regular basis.
A very simple way could be a simple cron on the server that would initiate a call to that specific route. If you want something inside your rails application, you may want to take a look at background task libs such as delayed_job or resque.
Related
New to Rails, and looking for the 'right' way to do something that seems straight-forward, but nothing I've read about sounds quite right.
I have a Rails app on Heroku, and I've added a call to an endpoint that depends on an external system. If that call is unsuccessful there'll be some follow up needed, so I save details to the error log. I've added a notification email (to a slack room for this sort of thing) to prompt me to check the logs and follow up if it happens.
In case the endpoint gets bogged down and fails repeatedly, I want to be able to throttle the slack alert so I don't spam everyone (for example, only email the slack room if 30 min have gone by since the last time it alerted).
To do this, I imagine I need:
somewhere to save a timestamp for the last email notification for the error
whenever the error occurs, compare with that timestamp and only email slack room if the 30-min window has passed. Then update the timestamp with the new value.
What's an appropriate place to save this kind of timestamp value? I've read that global variables are the devil (and wouldn't actually work in this case), but the other options (adding database field, trying the simpleconfig gem) seem excessive/incorrect for something internal that I don't even know will happen once, let alone frequently.
Is there a lightweight way to get this done?
A popular choice would be to store it in a Redis store -- especially if you already have one set up for something else, like caching. As this is itself ephemeral data, you could even use the Rails.cache API to abstract away the detail and have this code just trust that it gets stored somewhere.
Failing that, the most straightforward solution is probably to create a tiny single-row table and store it in there: it's overkill, but doesn't involve doing anything unusual, or that would look out of place in the middle of a Rails application.
As a quick and simple solution, though, a global variable isn't out of the question: it has strong limitations, like it won't be shared across multiple server processes, and it'll go away any time the process restarts... but if those add up to a risk that you'll get, say, 4-6 notifications in an error-heavy 30 minute period -- maybe that's good enough? (It'd also give you a "reset on deploy" feature for free, so you know immediately if the problem's still occurring after you think you've fixed it.)
I'd like to infrequently open a Twitter streaming connection with TweetStream and listen for new statuses for about an hour.
How should I go about opening the connection, keeping it open for an hour, and then closing it gracefully?
Normally for background processes I would use Resque or Sidekiq, but from my understanding those are for completing tasks as quickly as possible, not chilling and keeping a connection open.
I thought about using a global variable like $twitter_client but that wouldn't horizontally scale.
I also thought about building a second application that runs on one box to handle this functionality, but that seems excessive if it can be integrated into the main app somehow.
To clarify, I have no trouble starting a process, capturing tweets, and using them appropriately. I'm just not sure what I should be starting. A new app? A daemon of some sort?
I've never encountered a problem like this, and am completely lost. Any direction would be much appreciated!
Although not a direct fix, this is what I would look at:
Time
You're working with time, so I'd look at what time-centric processes could be used to induce the connection for an hour
Specifically, I'd look at running a some sort of job on the server, which you could fire at specific times (programmatically if required), to open & close the connection. I only have experience with resque, but as you say, it's probably not up to the job. If I find any better solutions, I'll certainly update the answer
Storage
Once you've connected to TweetStream, you'll want to look at how you can capture the tweets for that time period. It seems a waste to create a data table just for the job, so I'd be inclined to use something like Redis to store the tweets that you need
This can then be used to output the tweets you need, allowing you to simulate storing / capturing them, but then delete them after the hour-window has passed
Delivery
I don't know what context you're using this feature in, so I'll just give you as generic process idea as possible
To display the tweets, I'd personally create some sort of record in the DB to show the time you're pinging TweetStream that day (if it changes; if it's constant, just set a constant in an initializer), and then just include some logic to try and get the tweets from Redis. If you're able to collect them, show them as you wish, else don't print anything
Hope that gives you a broader spectrum of ideas?
I want to make a game in rails (not with flash, just html). Every action should take some time to execute. For example, user can send an action to his hero "go learn ". It should lasts for 10 minutes. What's the best way to implement it?
I want to store player tasks in my database, but how should I do their execution?
1 way: when user log in or do something, check his tasks and look for finished ones.
2 way: check tasks on my app every X seconds and look for finished ones.
3 way: use something like Delayed Job gem. Do you think its good for my problem?
You could use delayed job, to run the task.With that there is problem that you will have tomanage "many" workers when there is extra load on the site, but its not that bad either, its doable as long as it "runs" every task exactly after 10 minutes.
You can still use a combined approach using 1 & 2 which would generally work.
I am now researching for a solution to perform similar task and just recently came across a railscasts episode that I found worthy of noting down.
Using custom deamons (and a number of other interesting topics) found here.
P.S.
I see that you have asked this question a while back. Could you please share how you ended up implementing your solution.
Cheers
Alright, this is a design question more than anything. I am making a text based game using Ruby on Rails 3, and I'm not sure the best way to implement what I want to do. In the game, the user gets a bunch of goblins, and can tell those goblins what to do. One of the available actions is attack, which as you can assume, means your tribe attacks something else, whether it be an opposing tribe, or a NPC settlement.
If you choose to attack an opposing tribe, then your goblins go off to attack. There is a set point when the battle will commence, (let's say, 10 minutes in the future). Here's the question, what's the best way to implement running the simulation for the battle in exactly 10 (or X) minutes in the future? Because if the simulation is run too soon or too late, then the entire outcome of the battle could be changed by what the opponent does.
(I know it's a little vague, but for those of you who have played Ogame, entire battle outcomes can change if the simulation is run a second too soon or late.)
I was looking at ways to implement having something run at X time in the future (this episode, and the two previous), but it doesn't seem to be tuned toward something that needs to be run precisely at time X. I also looked in to Ruby timers, but there doesn't seem to be a consistent one, like there is in java, nor do they automatically make the data persistent. I was hoping for low coupling too, perhaps using the observer pattern.
So there you have it. If I send my attack, or want to do anything at exactly time X in the future, what's the best way to do this in Ruby on Rails?
Simple answer: Don't
You should save the time (now+10 minutes) in a database and then run a cronjob every minute (or whatever you prefer). This should then evaluate all fights that should be fought at that time.
For best practices on this behaviour see A cron job for rails: best practices?
You could also add a check if a fight can be fought on every request you get. This way you'll get a little bit more randomness when the fight will start exactly and depending on the traffic of your site, this could be like every second. Remember to start a thread to evaluate the fight, depending on the amount of your calculations. Otherwise some users can experience massive lags.
The typical thing to do if you want some event to happen in the future with ruby on rails is to use cron to fire externally (as simon suggested) or use the delayed_job gem and set a job for the future. You can also use rufus-scheduler gem like this:
scheduler.in '10m' do
puts "something happening 10 minutes from now"
end
Like with browser games. User constructs building, and a timer is set for a specific date/time to finish the construction and spawn the building.
I imagined having something like a deamon, but how would that work? To me it seems that spinning + polling is not the way to go. I looked at async_observer, but is that a good fit for something like this?
If you only need the event to be visible to the owning player, then the model can report its updated status on demand and we're done, move along, there's nothing to see here.
If, on the other hand, it needs to be visible to anyone from the time of its scheduled creation, then the problem is a little more interesting.
I'd say you need two things. A queue into which you can put timed events (a database table would do nicely) and a background process, either running continuously or restarted frequently, that pulls events scheduled to occur since the last execution (or those that are imminent, I suppose) and actions them.
Looking at the list of options on the Rails wiki, it appears that there is no One True Solution yet. Let's hope that one of them fits the bill.
I just did exactly this thing for a PBBG I'm working on (Big Villain, you can see the work in progress at MadGamesLab.com). Anyway, I went with a commands table where user commands each generated exactly one entry and an events table with one or more entries per command (linking back to the command). A secondary daemon run using script/runner to get it started polls the event table periodically and runs events whose time has passed.
So far it seems to work quite well, unless I see some problem when I throw large number of users at it, I'm not planning to change it.
To a certian extent it depends on how much logic is on your front end, and how much is in your model. If you know how much time will elapse before something happens you can keep most of the logic on the front end.
I would use your model to determin the state of things, and on a paticular request you can check to see if it is built or not. I don't see why you would need a background worker for this.
I would use AJAX to start a timer (see Periodical Executor) for updating your UI. On the model side, just keep track of the created_at column for your building and only allow it to be used if its construction time has elapsed. That way you don't have to take a trip to your db every few seconds to see if your building is done.