If you wanted even more flexible schedules, you might want to look into Later.js ( http://bunkat.github.io/later/ ), a small library I created just for this purpose. It supports composite and exception schedules, cron schedules, and lots of different time periods. Everything can be specified using an API or using English text. I also built replacements for setTimeout and setInterval to use Later schedules, so it shou…
Very cool. How robust is the english parsing? For example, would it understand something like "The first wednesday of every month"? Either way I will definitely check it out.
If you wanted even more flexible schedules, you might want to look into Later.js ( http://bunkat.github.io/later/ ), a small library I created just for this purpose. It supports composite and exception schedules, cron schedules, and lots of different time periods. Everything can be specified using an API or using English text. I also built replacements for setTimeout and setInterval to use Later schedules, so it shou…
Very cool. How robust is the english parsing? For example, would it understand something like "The first wednesday of every month"? Either way I will definitely check it out.
You can see the grammar and lots of examples at http://bunkat.github.io/later/parsers.html#text. For your question, it would be 'on Wednesday on the first day instance every 1 month' or 'on the first day instance on Wed' would also work.
Any word on how this affects battery life, specifically on Macs? I've had to turn on atrun on my MacBook Air and it has absolutely destroyed my battery life.
Curious, why the choice of mongo vs something like redis?
The choice of Mongo vs Redis was intentional. Without configuration Redis doesn't guarantee persistence as well as Mongo. Since Redis is often used for non-critical data such as sessions I didn't want to enforce sacrificing performance of sessions for persistence.
Looking at these scheduling modules, I wonder to myself why saving a .json file wouldn't be more simple. Filesystem cache, available to all workers on the system and no dependencies required.
I mean, if you're worried about cluster workers file reading being slower than a db connection, the json store could be write-only most of the time and only read on app startup while schedules are synced over cluster messaging.
Any word on how this affects battery life, specifically on Macs? I've had to turn on atrun on my MacBook Air and it has absolutely destroyed my battery life.
I haven't tested on a laptop be honest. Interesting point. What is atrun? I'll do some research and see if I can do anything about it... For reference node idles at about 3% CPU on my dev-box.
The choice of Mongo vs Redis was intentional. Without configuration Redis doesn't guarantee persistence as well as Mongo. Since Redis is often used for non-critical data such as sessions I didn't want to enforce sacrificing performance of sessions for persistence.
Looking at these scheduling modules, I wonder to myself why saving a .json file wouldn't be more simple. Filesystem cache, available to all workers on the system and no dependencies required. I mean, if you're worried about cluster workers file reading being slower than a db connection, the json store could be write-only most of the time and only read on app startup while schedules are synced over cluster messaging.
In my mind there are a few reasons, but indeed it could definitely be implemented with a flat file. Sometimes you aren't guaranteed write-access to a file on the system, especially if you're using a PAAS like Heroku. That also complicates things if you want to build something to view/edit the data in an isolated instance. These are just the reasons that come to the top of my head, but in reality you're right, this could be finessed to be done with just a flat file.
Looking at these scheduling modules, I wonder to myself why saving a .json file wouldn't be more simple. Filesystem cache, available to all workers on the system and no dependencies required. I mean, if you're worried about cluster workers file reading being slower than a db connection, the json store could be write-only most of the time and only read on app startup while schedules are synced over cluster messaging.
In my mind there are a few reasons, but indeed it could definitely be implemented with a flat file. Sometimes you aren't guaranteed write-access to a file on the system, especially if you're using a PAAS like Heroku. That also complicates things if you want to build something to view/edit the data in an isolated instance. These are just the reasons that come to the top of my head, but in reality you're right, this co…
Good points. Perhaps structuring it in a way to allow for a flat file or redis/nosql/sql might push a particular schedule module into greater favor, at least for those of us who want our apps to consist of minimal different db methods.