Today’s fun started around lunchtime. It wasn’t just getting to sit back and enjoy hamburgers without tomatoes; no, we had math games to keep us entertained. In fact, we were away from the office for more than three hours. I still have the bescribbled napkin to prove it.
Our application’s usefulness is to be heavily achieved through flexible, painless scheduling and integrating of numerous prayer requests. Today we brainstormed how to implement prayer lists.
While the initial release will probably involve only the individual aspect of the application, we intend to expand to a system of sharing and updating requests for prayer that is centered around churches. To share and organize each request entirely independent of any other is sure to become hairy once we start talking about signing up for church and missionary updates; therefore, we intend to implement lists.
Though it might change, the plan as of today is to schedule requests in lists by including two options.
The first is how often the list will cycle through. Say you create a list with twenty prayer requests and select ‘every week’ for this option. The application will schedule users of the list to pray for each of the twenty requests within each week. The second option is what days you actually want to pray for items on the list. For this example, imagine that the list cycles through once a month. Instead of praying for items almost every day, you chose to pray for that list every Tuesday. Now the application only sends you requests from that list on Tuesday, but still makes sure it sends all of them before the month is out.
Hopefully this sounds very simple from a user standpoint — that is our goal. From a coding standpoint, however, it presents some challenges. As we munched our french fries, Mr. Chandler considered and explained.
We wanted to minimize memory-expensive database queries, which ruled out setting flags on each prayer request in a list to indicate when it had been prayed for that period.
This left us with only a few variables available to the application at any given time: the number of days set for the list to cycle through (#D), the current day in that cycle (D#), and the number of prayer requests in the list (#R). From this data we needed to determine the information we wished to avoid storing in the database: which request in the list is next up for prayer (R#).
A modulus operator would make many schedules simple. A list of twenty-one requests to be prayed through weekly, on every day, would be simple — three requests per day. But what if there were, say, twenty-five requests? In this case, a modulus operator would select four requests the first four days, and three on the last three. For larger lists, prayed through over a period of several months, it would be strange to have the first portion of the period front-loaded with requests. It would be preferable to spread the remaining requests after a simple division of #R divided by #D. A more severe problem would arise if #R was less than #D. In this case, the modulus operator would select one request per day until it came to the end of the list, and then none for the remainder of the period! To distribute these evenly over the period would be easy enough for a human, but a modulus operator wouldn’t know where to begin.
We briefly (only for half an hour or so!) entertained the idea of using a periodic function designed to reach maximum amplitude #R times in a #D period. In this case, we would actually calculate #D in seconds — no great task for Java! — in order to ensure that #D was a greater value than #R. This would solve the division problem, and once we coded to put the requests corresponding to the maxima in the day in which they occurred, it would also solve the front-loading problem.
A bit more thought on the modulus method, however, led to a simpler solution than using a sine squared function!
By including the second user setting described at the beginning of the post — how often to pray for requests — we essentially left the option to lower #D (so that a user prayer for items on a particular list only every Thursday, four times a month, instead of every day that month). This allows some flexibility to reduce front-loading, and ought to entirely eliminate situations where #R is less than #D.
Before all this, Mr. Chandler and I worked for a few hours getting our maven dependencies working right, and that provides the subject matter for todays Note to Dense Summer Interns: adding a dependency to your maven project in Eclipse doesn’t help unless you enable dependency manager or run ‘mvn eclipse:eclipse’!
Finally, our song for the day, “I Saw Elvis in a UFO.” (be warned, however, I cannot vouch for the artist’s other songs.)
Filed under: Jobber's Log | Tagged: Java, Mathematics, Maven, Scheduling
