Scheduler Brain Dump 19MAY2016

I had some time before medical appointment this morning to think a bit more about the Scheduler service I need to create for my PRC-119 app.  I have a tendency to think through solutions in my head but not write them down causing me to have to cover the same ground the next time I actually sit down to code.

What follows is a stream of consciousness “brain dump” about that feature/service and some other random thoughts.

Scheduler:

The basic premise with the scheduler will be that we’ll pass it the following information:

  • Reminder Message
  • Phone Number
  • DateTime for first occurrence
  • Recurrence (?, 1st iteration version is 10 days)

With the information above, the scheduler will iterate over the number of days and create a scheduled delayed_job job for the worker to process.

***Update 19MAY2016 0848*** 

In thinking about this more, the reality is that I’ll be passing a reminder object id (or just the object itself) to the scheduler and then the scheduler will iterate over the recurrences and create delayed_jobs.  I may need to use the delayed_jobs_recurring gem to actually get the behavior I want, but we’ll see.

I’m a little concerned that the scheduler will need to know too much about what the internals are of the reminder and be too tied to the reminder model.  Will think about this more.

***

***Update 19MAY2016 0904***  

I really think I should break some of this logic out into a service object rather than having the scheduler live inside the models.  For now just going to leave it in models and get it working.  I’ll take another look at how things are laid out and break the feature down into services afterwards if I feel so inclined.

***

For the time being we’ll ignore the follow-up reminder as it isn’t the key feature for now.

Potential Issues:

The scheduler will also need to assign each job in the recurrence with a unique identifier so that they can be located as a group at a later time.  This could be a unique hash of the phone number and created_at, but I’ll determine that later.

Current Schema:

Reminder (important portions)

  • reminder_text
  • phone_number
  • time
  • time_zone
  • user_id
  • created_at

Proposed Schema for Scheduler:

  • reminder_id (maybe)
  • unique_identifier
  • Here be dragons (other shit for later)

Associations:

A reminder will have a single scheduler (for now).

A scheduler will have one/many delayed_jobs (interesting thought…may escape the need for a separate unique identifier if I can figure this part out via an association…we’ll see)

Questions:

Do reminders actually need to “own” the scheduler?

Does the scheduler need to “own” the jobs?

Should all of these just be separate systems?

Random Thoughts:

I’m over complicating the whole system by trying to address too many little problems all at once while trying to plan for future needs.  I need to just get a base level of it working and then iterate off that.

Doesn’t help that I’m also thinking about work related things (inbound email via Mailgun needs to be finished today, routes and business logic included) and the departure next week of J.G.  

I’m much more stressed about the latter than I’d like to admit, he’ll be missed for his humor and stern (yet) patient people skills.  He’s made me a much better developer and I’ve learned more with him since October than I’ve learned on my own/with others in the past 2 years.

Also stressed out about career aspirations and the noticeable stigma of being a code school graduate despite the rest of my career experience.  Am I a fool for thinking someone would consider a code school graduate (despite my tech/writing/soft skills from the other 15 years of my tech career) for a developer evangelist position?

Current job-wise:  Will there be money for my position June 1?  July 1?  What’s my future look like here in the next 1, 3, 5 years?  

Leave a Reply

Your email address will not be published. Required fields are marked *