Would love to see a video on how to do notifications based on future events. Could be recurring or not. For example in gmail I can schedule to get notified by email 10 minutes before an event. They're pretty spot on. Would love to see your take on how something like that could be built.
Sounds interesting. I'll put this on my list of episodes to cover.
At a first glance, I would approach it a few different ways:
1. use sidekiq-cron and create a scheduled task to monitor all of the "notifications" that need to be sent out. Downfall is that as the application grows, even a well indexed table could start to get slow to query.
2. use sidekiq to tie into activejob's perform at. With sidekiq it would look something like this
And the benefit of this approach would be that the query wouldn't need to happen since the job is already queued to execute at a later time. The downfall of this could be an improperly configured Redis instance (memory set to volatile instead of nonvolatile) which could result in missing jobs.
If data integrity was an must, I typically prefer persistent queues like delayed_job over in memory. However, this is questionable on "data integrity", but it makes me feel better inside that critical data is not lost in a memory/persistent (write cache to disk) queue.
Regardless, I think option 2 would be a better way to go, there would just have to be some sort of hook to remove the job if the scheduled event were cancelled.
Although it's possible to use IceCube with Date instances like you've shown when selecting the "start" and "end" dates, IceCube actually works with exact Time objects and will convert it for you internally. You can see this in the occurrence output, where it defaults to 00:00 of your local system time zone. (This might turn out to be UTC on your server, and different from your workstation, or it could be affected by the current `Time.zone` setting in Rails... it might be what you expect, or maybe not. Just be aware.)
If you're thinking of using the schedules for anything like reminders, you will have more accurate results if you build your schedule with an actual Time object instead of a Date. When using Rails, you can get a local time (TimeWithZone) for any zone like this:
# Get a zone instance, (or else set it globally via Time.zone): zone = ActiveSupport::TimeZone["America/New_York"]
# Get any time in that zone, or parse from a string: now = zone.local(2017, 9, 1, 12, 0, 0) now = zone.parse("2017-09-01 12:00:00")
# Then use it with the schedule: schedule = IceCube::Schedule.new(now)
IceCube will then correctly handle things like Daylight Saving Time changes.
Very useful, thank you!
Would love to see a video on how to do notifications based on future events. Could be recurring or not. For example in gmail I can schedule to get notified by email 10 minutes before an event. They're pretty spot on. Would love to see your take on how something like that could be built.
Sounds interesting. I'll put this on my list of episodes to cover.
At a first glance, I would approach it a few different ways:
1. use sidekiq-cron and create a scheduled task to monitor all of the "notifications" that need to be sent out. Downfall is that as the application grows, even a well indexed table could start to get slow to query.
2. use sidekiq to tie into activejob's perform at. With sidekiq it would look something like this
And the benefit of this approach would be that the query wouldn't need to happen since the job is already queued to execute at a later time. The downfall of this could be an improperly configured Redis instance (memory set to volatile instead of nonvolatile) which could result in missing jobs.
If data integrity was an must, I typically prefer persistent queues like delayed_job over in memory. However, this is questionable on "data integrity", but it makes me feel better inside that critical data is not lost in a memory/persistent (write cache to disk) queue.
Regardless, I think option 2 would be a better way to go, there would just have to be some sort of hook to remove the job if the scheduled event were cancelled.
Although it's possible to use IceCube with Date instances like you've shown when selecting the "start" and "end" dates, IceCube actually works with exact Time objects and will convert it for you internally. You can see this in the occurrence output, where it defaults to 00:00 of your local system time zone. (This might turn out to be UTC on your server, and different from your workstation, or it could be affected by the current `Time.zone` setting in Rails... it might be what you expect, or maybe not. Just be aware.)
If you're thinking of using the schedules for anything like reminders, you will have more accurate results if you build your schedule with an actual Time object instead of a Date. When using Rails, you can get a local time (TimeWithZone) for any zone like this:
IceCube will then correctly handle things like Daylight Saving Time changes.