GEMs pollution or not?

Hello,

While developing a module that implements a « CRON calendar », I also
created a few « utility modules ».

When you develop such module, you write functions that are not coupled
to your module.

For example : a function that returns the list of “days of the month”
that correspond to a list of “days of week” (within a given month of a
given year). This function may be used for other purposes than a « CRON
calendar ». Therefore, I put this function in a « date utility module ».

1 – I can include the « date utility module » within the « CRON
calendar GEM ».

or

2 – I can create a « date utility GEM ». The « CRON calendar GEM » will
have a dependance with the « date utility GEM ».

The second solution seems better. But : the « date utility GEM » may
change in the future, since I’ll be adding more and more functions into
it. In other words : this GEM is a kind of heap of functions with no
other thing in common than date and time finality.

If everybody creates a GEM for this kind of thing, this may pollute the
GEM repository.

What’s your advice?

Thanks,

Denis

On Wed, May 29, 2013 at 1:58 PM, Denis BEURIVE [email protected]
wrote:

given year). This function may be used for other purposes than a « CRON

The second solution seems better. But : the « date utility GEM » may
change in the future, since I’ll be adding more and more functions into
it. In other words : this GEM is a kind of heap of functions with no
other thing in common than date and time finality.

If everybody creates a GEM for this kind of thing, this may pollute the
GEM repository.

What’s your advice?

First off, look for existing gems with such functionality. If nothing
fits, but something is close, consider contributing to that gem. If
nothing is close, write a new gem.

However, don’t use a gem as a junkdrawer. Just because something has
to do with date or time processing, doesn’t mean it should all go in
one single gem.

The overall approach of separating things into self-contained modules,
though, is very sound. Just make sure your interfaces to them are an
established contract with your callers/users (which hopefully will
grow to beyond just yoursef). Don’t break interfaces. Period. But when
you have to (you really don’t!) make sure to version them correctly.

Not sure what your question about the repository is. I imagine if your
referring to rubygems.org someone owns the name cron already so you
may have to use a different name or namespace it.

As far as the decoupling question think what cron really is. It’s a
higher level job scheduler which parses a table created by the user
(i.e. crontab) to provide periodic automation of system level tasks
(i.e. clean core dumps, clean /tmp check filesystem healths and so
forth). Cron is built on top of at which is basically a procedure
queue for running processes at set time. Cron is also the daemon
whereas both at and batch commands are The at command utilized the
unix date and mail commands. Break it down per function for your
abstraction: cron is your daemon, at is your scheduler, calender
(date) is an interface which both at and cron will depend on. by
having the separate modules for each will aid in the re-usability your
looking for and also reveal the UNIX philosophy as well. Another
command to look at implementing would be the jobs command which acts
as a superviser for your processes state.

Happy Hacking!

~Stu

You wouldn’t be the first. It’s a great way to learn by reimplementing
such things. I’m sure there is a joke in there somewhere on
reinventing the wheel as opposed to simply adding yourself to the
wheel group.

~Stu

Thank you very much for these responses.

I did not find the CRON GEM… I have reivented the wheel :wink:

Best regards,

Denis