
Rails deployment missing piece, filled in - koops
http://github.com/javan/whenever/tree/master
======
stephenjudkins
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
Because if you have more than one machine running your app, you've got to
reinstall the crontab everywhere. This keeps it DRY.

~~~
patio11
It also means that your crontab just went in source control, which is a detail
a lot of people (i.e. me) forget.

------
tjogin
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
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
> 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
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.

~~~
teej
> 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
_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.

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

------
Hexstream
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)

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

~~~
teej
Not without a little hacking. After a little digging, it looks like it has an
implicit Rails dependency
([http://github.com/javan/whenever/blob/f036675e94cd9dd9b21d2c...](http://github.com/javan/whenever/blob/f036675e94cd9dd9b21d2c1af9b96846d945545b/lib/base.rb))

~~~
javan
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"

------
sunkencity
just bite the bullet and learn to use crontab ffs.

nice sugar though...

------
acangiano
Nice, but does it work on Windows?

~~~
javan
Do cron jobs work on Windows?

~~~
acangiano
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.

