7 ms·

Rails deployment missing piece, filled in

41 points by koops 18y ago

acangiano 18y ago
Nice, but does it work on Windows?
- javan 18y ago
  Do cron jobs work on Windows?
  - acangiano 18y ago
    No, they don't. My question asked whether yours was a convenient wrapper for cron jobs or if you implemented the same functionality in a cross-platform manner. Thanks for your answer.
tjogin 18y ago
Very good addition to Rails, truly a missing piece as putting stuff in cronjobs spreads the logic of the app around. This makes it more readable as well.
- koops 18y ago
  Right--whatever your session cleanup strategy is, it's got to be run from cron. It's great that the author includes a cap task in the documentation, though the role should usually be db, not app.
  - teej 18y ago
    > whatever your session cleanup strategy is ... not really. If you're using cookie-store (the Rails default) or mem-cache-store (the fast, scalable option) there isn't any need for a session cleanup strategy. I can definitely agree with the point on documentation - killer docs with real-life scenario examples are really key in adoption for stuff like this.
    - jrockway 18y ago
      Storing sessions in a cache is a really bad idea. Too many sessions, and they start expiring randomly. I have been bitten by this, so I always store sessions in a non-lossy data store now. (BerekelyDB, FWIW.) (As for in-cookie sessions, I like the idea, but it does require some server-side state to allow a user to invalidate his previous sessions. If someone steals the cookie, they have access to the system "forever", and the user has no recourse. The solution is to store a serial number in the user object, and reject sessions less than the current number, but I don't think Rails implements it this way by default.) I am also not a big fan of running the cleanup job from cron. My main application has an event loop capable of firing timers (libev), so I use that to kick off a (forked) cleaning process. That requires no additional configuration on the system that the app is running on, which is just the way I like it. (Yeah, I know I am reinventing UNIX. UNIX needs to be reinvented.) The event loop has other advantages, like non-blocking IO, and non-blocking subprocess invocations. A request can literally wait all day for a database query, and it won't prevent the app process from handling other requests.
      - look_lookatme 18y ago
        Rails doesn't have any user management functionality. Most of the user libs do something to this effect with auth tokens.
      - teej 18y ago
        > storing sessions in cache is a really bad idea I've never had this issue, so I'm either using a bigger cache than you, or I'm storing less in the session. >. Cookie store I can't really speak to why the rails core team made this default, I think it's a step backwards. > libevet... That's certainly an option too. The beauty of this tool though isn't in the ruby syntax for cron. It's in using capistrano deployment flexibility and expressiveness for managing distributed crontabs.
        jrockway 18y ago
        I can't really speak to why the rails core team made this default, I think it's a step backwards. "It's cool." Seriously though, they probably picked it because it requires no configuration. It also avoids hitting the database for things like "Logged in as jrockway", which is always a good thing.
  - javan 18y ago
    I'm the author -- thanks. To keep things very clean, we created a :cron role for our deployment (which happens to be the same server as our :db). I imagine that many people are running on one server and so the :app role is fine. The point is that you can deploy different cron schedules to your various server types using roles.
stephenjudkins 18y ago
Why not just use cron for this? Yes, the syntax for this does look a lot cleaner, but cron really isn't that hard to use. Why add another layer of complexity (which may break and be difficult to debug) when you could simply add lines to a crontab? Bonus feature: "USING THE "—write-crontab" OPTION WILL COMPLETELY OVERWRITE ANY EXISTING CRONTAB ENTRIES!" Wow. I like Ruby but many in the community's obsession with reinventing the wheel (with slightly more syntactic sugar and a hip github page) is pretty difficult for me to understand.
- koops 18y ago
  Because if you have more than one machine running your app, you've got to reinstall the crontab everywhere. This keeps it DRY.
  - patio11 18y ago
    It also means that your crontab just went in source control, which is a detail a lot of people (i.e. me) forget.
  - stephenjudkins 18y ago
    Why not just keep the crontab file in your repo? A rake task that does `cp #{project_dir}/crontab /etc/crontab` would be sufficient to meet the same needs.
- javan 18y ago
  Whenever simply generates your crontab file for you using a cleaner syntax. It hasn't reinvented anything or added any complexity. You are just using cron.
  - Tichy 18y ago
    But presumably you have to learn the new syntax?
- tlrobinson 18y ago
  Indeed, Ruby fans (I refuse to call them "Rubyists") love to talk about how Ruby is a great language for creating DSLs, which is true, but that doesn't mean you should create a new DSL for everything just because you can.
sunkencity 18y ago
just bite the bullet and learn to use crontab ffs. nice sugar though...
juliend2 18y ago
nice, but is it possible to use it somewhere else than Rails, like say, Merb or Sinatra?
- teej 18y ago
  Not without a little hacking. After a little digging, it looks like it has an implicit Rails dependency (http://github.com/javan/whenever/blob/f036675e94cd9dd9b21d2c1af9b96846d945545b/lib/base.rb http://github.com/javan/whenever/blob/f036675e94cd9dd9b21d2c...)
  - javan 18y ago
    It will work FINE without Rails. The code you're pointing to simply finds the Rails root if it exists as a convenience. If one doesn't, you have to manually tell Whenever your path: set :path, "/path/to/my/app"
- jcapote 18y ago
  I wrote something very similar to this a little while ago that's framework agnostic, http://www.github.com/jcapote/theman http://www.github.com/jcapote/theman
  - juliend2 18y ago
    cool, i didnt know about http://rufus.rubyforge.org/rufus-scheduler/ http://rufus.rubyforge.org/rufus-scheduler/ , that you're using in this project.
Hexstream 18y ago
Cool. I'm in support of any syntax front-end that brings us closer to a future where everyone uses s-expressions for everything. ;P (it's not s-expressions, but it's a step in the right direction)
fizx 18y ago
Lol, I wrote "RailsCron" in 2005-2006. Funny to see how the ruby community iterates.

41 points by koops 18y ago

acangiano 18y ago

Nice, but does it work on Windows?

javan 18y ago
Do cron jobs work on Windows?
- acangiano 18y ago
  No, they don't. My question asked whether yours was a convenient wrapper for cron jobs or if you implemented the same functionality in a cross-platform manner. Thanks for your answer.

tjogin 18y ago

Very good addition to Rails, truly a missing piece as putting stuff in cronjobs spreads the logic of the app around. This makes it more readable as well.

koops 18y ago
Right--whatever your session cleanup strategy is, it's got to be run from cron. It's great that the author includes a cap task in the documentation, though the role should usually be db, not app.
- teej 18y ago
  > whatever your session cleanup strategy is ... not really. If you're using cookie-store (the Rails default) or mem-cache-store (the fast, scalable option) there isn't any need for a session cleanup strategy. I can definitely agree with the point on documentation - killer docs with real-life scenario examples are really key in adoption for stuff like this.
  - jrockway 18y ago
    Storing sessions in a cache is a really bad idea. Too many sessions, and they start expiring randomly. I have been bitten by this, so I always store sessions in a non-lossy data store now. (BerekelyDB, FWIW.) (As for in-cookie sessions, I like the idea, but it does require some server-side state to allow a user to invalidate his previous sessions. If someone steals the cookie, they have access to the system "forever", and the user has no recourse. The solution is to store a serial number in the user object, and reject sessions less than the current number, but I don't think Rails implements it this way by default.) I am also not a big fan of running the cleanup job from cron. My main application has an event loop capable of firing timers (libev), so I use that to kick off a (forked) cleaning process. That requires no additional configuration on the system that the app is running on, which is just the way I like it. (Yeah, I know I am reinventing UNIX. UNIX needs to be reinvented.) The event loop has other advantages, like non-blocking IO, and non-blocking subprocess invocations. A request can literally wait all day for a database query, and it won't prevent the app process from handling other requests.
    - look_lookatme 18y ago
      Rails doesn't have any user management functionality. Most of the user libs do something to this effect with auth tokens.
    - teej 18y ago
      > storing sessions in cache is a really bad idea I've never had this issue, so I'm either using a bigger cache than you, or I'm storing less in the session. >. Cookie store I can't really speak to why the rails core team made this default, I think it's a step backwards. > libevet... That's certainly an option too. The beauty of this tool though isn't in the ruby syntax for cron. It's in using capistrano deployment flexibility and expressiveness for managing distributed crontabs.
      - jrockway 18y ago
        I can't really speak to why the rails core team made this default, I think it's a step backwards. "It's cool." Seriously though, they probably picked it because it requires no configuration. It also avoids hitting the database for things like "Logged in as jrockway", which is always a good thing.
- javan 18y ago
  I'm the author -- thanks. To keep things very clean, we created a :cron role for our deployment (which happens to be the same server as our :db). I imagine that many people are running on one server and so the :app role is fine. The point is that you can deploy different cron schedules to your various server types using roles.

stephenjudkins 18y ago

Why not just use cron for this? Yes, the syntax for this does look a lot cleaner, but cron really isn't that hard to use. Why add another layer of complexity (which may break and be difficult to debug) when you could simply add lines to a crontab? Bonus feature: "USING THE "—write-crontab" OPTION WILL COMPLETELY OVERWRITE ANY EXISTING CRONTAB ENTRIES!" Wow. I like Ruby but many in the community's obsession with reinventing the wheel (with slightly more syntactic sugar and a hip github page) is pretty difficult for me to understand.

koops 18y ago
Because if you have more than one machine running your app, you've got to reinstall the crontab everywhere. This keeps it DRY.
- patio11 18y ago
  It also means that your crontab just went in source control, which is a detail a lot of people (i.e. me) forget.
- stephenjudkins 18y ago
  Why not just keep the crontab file in your repo? A rake task that does `cp #{project_dir}/crontab /etc/crontab` would be sufficient to meet the same needs.
javan 18y ago
Whenever simply generates your crontab file for you using a cleaner syntax. It hasn't reinvented anything or added any complexity. You are just using cron.
- Tichy 18y ago
  But presumably you have to learn the new syntax?
tlrobinson 18y ago
Indeed, Ruby fans (I refuse to call them "Rubyists") love to talk about how Ruby is a great language for creating DSLs, which is true, but that doesn't mean you should create a new DSL for everything just because you can.

sunkencity 18y ago

just bite the bullet and learn to use crontab ffs. nice sugar though...

juliend2 18y ago

nice, but is it possible to use it somewhere else than Rails, like say, Merb or Sinatra?

teej 18y ago
Not without a little hacking. After a little digging, it looks like it has an implicit Rails dependency (http://github.com/javan/whenever/blob/f036675e94cd9dd9b21d2c1af9b96846d945545b/lib/base.rb http://github.com/javan/whenever/blob/f036675e94cd9dd9b21d2c...)
- javan 18y ago
  It will work FINE without Rails. The code you're pointing to simply finds the Rails root if it exists as a convenience. If one doesn't, you have to manually tell Whenever your path: set :path, "/path/to/my/app"
jcapote 18y ago
I wrote something very similar to this a little while ago that's framework agnostic, http://www.github.com/jcapote/theman http://www.github.com/jcapote/theman
- juliend2 18y ago
  cool, i didnt know about http://rufus.rubyforge.org/rufus-scheduler/ http://rufus.rubyforge.org/rufus-scheduler/ , that you're using in this project.

Hexstream 18y ago

Cool. I'm in support of any syntax front-end that brings us closer to a future where everyone uses s-expressions for everything. ;P (it's not s-expressions, but it's a step in the right direction)

fizx 18y ago

Lol, I wrote "RailsCron" in 2005-2006. Funny to see how the ruby community iterates.