day_planner 0.1.0.pre13 → 0.1.0.pre13.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: fe0b67a0f2c0e7778c4a887f6f613006ae087279
-  data.tar.gz: 70c202aa60f598592874b7b8f6c776bce4ecdbce
+  metadata.gz: 8c633428e3235dd6ccd41d385f3a3e2be4ad50dc
+  data.tar.gz: 7bef8683a5f7305b6833163078d7a8aa320aea47
 SHA512:
-  metadata.gz: 38b3ff69e2cd8fe89f0ab7ebcb4d3516dcdc155b7839792c855c8eb93f5953b71b52cbed36ef34f3f4a5e92aa24732b53a9190fc768a94d72bbce5ee3f0e4c1b
-  data.tar.gz: 03c1307bd2f011ecc445f7e979d80135d35c0fd26e1b7caf64762ac446e23b133304dc1ae6b75ae9dfa26d2faf2fdb414ee81f25894a8fea4a473392b5eb1754
+  metadata.gz: e8e2b4b2d08938aa508ba79de5cd726439975dba3ad09c70d91403788807ee21d746835f05af39b5cf759443b4123460133f8116dda0280fb1f26167120da31c
+  data.tar.gz: 84a3c37ad8aa2e7da0e4e469bb29ce16c61387ebdfb4db73f2a32cc93caeeb7d49d0bb1572451c01502c920187362a82f6ddafc57c31e6509cff982cf49b06d4

data/PLANS.md

@@ -5,19 +5,24 @@ This is basically a gimme as long as we're already recording stuff in a database
 * Delete only anonymous tasks on initialize, don't delete anything with a persistent name and interval
 ** But do delete any task with an unfamiliar name or name, interval combo
 * Don't worry about task content changing. Fine, change it. We don't store that in a database anyway.
+* Do delete any unfamiliar tasks (i.e. anything in day_planner_tasks that isn't listed in our schedule file)
 * Don't reinitialize persistent events, just keep them on schedule. This helps especially if e.g. dealing with a pricy API -- why pull more often than needed?
 
 ### Log each tasks's history ###
 HIGH PRIORITY: I want to be able to monitor the elaborate new scheduling algorithm appropriately. This needs to be optional, but it would be nice to have the ability to monitor at least how well the task adheres to the timeline.
+* Optional generator task to create a table of task history whatnot? Check for it on initialize and then start writing to it if it's there.
+* Read history, add method to calculate number of times task performed over timeframe.
 
 ### Attempt some degree of control with multi-process instances ###
 Not sure exactly how to do this.
 * Store a record of the scheduler's execution status in a database? Then use that to avoid it being unnecessarily run in multiple threads?
+* Whichever process hits first grabs it. For Heroku compatibility, though, I don't think we can rely on that over long periods.
+** How about if other processes monitor for it at the long_heartbeat? Need to find way to determine if anyone's checking, though. I'm not sure how Heroku's dyno-restarting stuff works, but I don't know that we get an alarm when a vital dyno is going down.
 * Hell, even an optional "view scheduler status" page in the app. Why not?
 
 ### Some degree of DB independence ###
 This needs to wait until we have the multi-process thing down.
-* Set a separate interval for updating the DB, and in between just use in-memory stuff?
+* Set a separate interval for updating the DB, and in between just use in-memory stuff? Call it the long_heartbeat.
 ** This probably would need to be done on some sort of basis of strict multiples, i.e. every 6th tick, update the database. Make sure that we can be okay with circumstances in which the DB is not up to date. (Tasks might resume unnecessarily soon, etc., but shit, do I care?)
 * The value of this is when the interval is quite low, at which point both the DB usage and the time that the queries take starts dominating the scene
 

data/lib/day_planner/version.rb

@@ -3,7 +3,7 @@ module DayPlanner
 	MINOR = 1
 	TINY  = 0
 	PRE   = "pre13"
-	BUILD = nil
+	BUILD = 1
 
   VERSION = [MAJOR, MINOR, TINY, PRE, BUILD].compact.join(".")
 end

metadata

@@ -1,7 +1,7 @@
 --- !ruby/object:Gem::Specification
 name: day_planner
 version: !ruby/object:Gem::Version
-  version: 0.1.0.pre13
+  version: 0.1.0.pre13.1
 platform: ruby
 authors:
 - Damon Siefert