day_planner 0.1.0.pre13.1 → 0.1.0.pre13.2

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 8c633428e3235dd6ccd41d385f3a3e2be4ad50dc
-  data.tar.gz: 7bef8683a5f7305b6833163078d7a8aa320aea47
+  metadata.gz: ea1a8388bee3db6d14b3f8e87ae7a015ea6fb9e9
+  data.tar.gz: 1a3add64f1cf3ea29bcaf0ce9e5821360e02d8f9
 SHA512:
-  metadata.gz: e8e2b4b2d08938aa508ba79de5cd726439975dba3ad09c70d91403788807ee21d746835f05af39b5cf759443b4123460133f8116dda0280fb1f26167120da31c
-  data.tar.gz: 84a3c37ad8aa2e7da0e4e469bb29ce16c61387ebdfb4db73f2a32cc93caeeb7d49d0bb1572451c01502c920187362a82f6ddafc57c31e6509cff982cf49b06d4
+  metadata.gz: d444e21d7abbca089a2ce5082fd91d3dc6e91d1162cf93e629a88a8c3121b18bd366ceb6c5169654af7ef5d2ad8fcc8f7a8b81608db2d57bcbce040be196d6cf
+  data.tar.gz: 23e61d289e2b28534dc1f54afe4699c07ddc200442c8dc308b84ef49f33b426b341df838455a741d319fe8e99f9af5bb0787dd4bbac142f2536afc5b021e2c05

data/PLANS.md

@@ -3,7 +3,7 @@
 ### Track tasks across application launch instances ###
 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
+	* 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?
@@ -17,13 +17,13 @@ HIGH PRIORITY: I want to be able to monitor the elaborate new scheduling algorit
 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.
+	* 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? 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?)
+	* 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
 
 ### Other task scheduling techniques ###

data/lib/day_planner/version.rb

@@ -3,7 +3,7 @@ module DayPlanner
 	MINOR = 1
 	TINY  = 0
 	PRE   = "pre13"
-	BUILD = 1
+	BUILD = 2
 
   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.1
+  version: 0.1.0.pre13.2
 platform: ruby
 authors:
 - Damon Siefert