3 ms·

Great, but do they really have to leave the cron schedule format as the only option for specifying? It seems like a great idea if it's 1975 and you are dealing

by ilaksh 3y ago

Great, but do they really have to leave the cron schedule format as the only option for specifying? It seems like a great idea if it's 1975 and you are dealing with limitations of that time. And I think it's good to keep it as an option. But why not include any kind of schedule specifier that is a bit less cryptic and error prone? Is it really so much code? Maybe someone has a package already that can wrap this or output a schedule from a human readable description or something. Maybe something like `human-to-cron`.

alexgarcia-xyz 3y ago
A JSON schedule format is coming soon: https://github.com/denoland/deno/pull/21340 https://github.com/denoland/deno/pull/21340
hu3 3y ago
This is something I like about in Laravel: $schedule->call(new DeleteRecentUsers)->daily(); $schedule->job(new Heartbeat)->everyFiveMinutes(); $schedule->exec('node /home/forge/script.js')->lastDayOfMonth('15:00'); $schedule->command('foo') ->weekdays() ->hourly() ->timezone('America/Chicago') ->between('8:00', '17:00'); $schedule->command('emails:send') ->hourly() ->days([Schedule::SUNDAY, Schedule::WEDNESDAY]); https://laravel.com/docs/10.x/scheduling https://laravel.com/docs/10.x/scheduling
- CGamesPlay 3y ago
  As someone who has not seen this syntax before, it's OK. But, "timezone" shouldn't be a separate method, it should be a parameter to the function taking the time specification. Functions named as nouns should be named "onNoun" instead (onWeekdays, onDays). It's also very unclear what happens if I do something like ->daily()->weekdays() ("daily on weekdays") or ->weekdays()->lastDayOfMonth('15:00') ("on the last weekday of the month at 15:00").
  - hu3 3y ago
    While I agree with most if not all your points. Let's agree that "should" is a strong word for what is basically our opinion. These are all debatable. For example: - Prefixing everything with "on" adds noise. It's debatably intuitive enough as it is. - Demanding timezone arguments on these methods also adds noise. More often than not you just want to use system default noise since it is such an important thing that you want to control at a higher level anyway. - It can be okay to allow edge/confusing states if the tradeoff is to keep implementation simpler. One can always rely on unit tests to keep expectations in check.
demosthanos 3y ago
The docs already link out to a cron string generator: https://www.npmjs.com/package/cron-time-generator https://www.npmjs.com/package/cron-time-generator

by ilaksh 3y ago

alexgarcia-xyz 3y ago

A JSON schedule format is coming soon: https://github.com/denoland/deno/pull/21340 https://github.com/denoland/deno/pull/21340

hu3 3y ago

This is something I like about in Laravel: $schedule->call(new DeleteRecentUsers)->daily(); $schedule->job(new Heartbeat)->everyFiveMinutes(); $schedule->exec('node /home/forge/script.js')->lastDayOfMonth('15:00'); $schedule->command('foo') ->weekdays() ->hourly() ->timezone('America/Chicago') ->between('8:00', '17:00'); $schedule->command('emails:send') ->hourly() ->days([Schedule::SUNDAY, Schedule::WEDNESDAY]); https://laravel.com/docs/10.x/scheduling https://laravel.com/docs/10.x/scheduling

CGamesPlay 3y ago
As someone who has not seen this syntax before, it's OK. But, "timezone" shouldn't be a separate method, it should be a parameter to the function taking the time specification. Functions named as nouns should be named "onNoun" instead (onWeekdays, onDays). It's also very unclear what happens if I do something like ->daily()->weekdays() ("daily on weekdays") or ->weekdays()->lastDayOfMonth('15:00') ("on the last weekday of the month at 15:00").
- hu3 3y ago
  While I agree with most if not all your points. Let's agree that "should" is a strong word for what is basically our opinion. These are all debatable. For example: - Prefixing everything with "on" adds noise. It's debatably intuitive enough as it is. - Demanding timezone arguments on these methods also adds noise. More often than not you just want to use system default noise since it is such an important thing that you want to control at a higher level anyway. - It can be okay to allow edge/confusing states if the tradeoff is to keep implementation simpler. One can always rely on unit tests to keep expectations in check.

demosthanos 3y ago

The docs already link out to a cron string generator: https://www.npmjs.com/package/cron-time-generator https://www.npmjs.com/package/cron-time-generator