User:Paul Clark/Whiteboard

Latest revision as of 21:26, 29 September 2010

Questions

• How to handle administration? When a task is created admins are assigned. The creator by default, then a (auto-completing) drop down of other users in the network, maybe with recently selected users at the top.
• What about tasks which never get completed? Even with the points getting deducted from the assigned users (i.e. the amount of points //total// divided by the amount of assigned user taken off from everyone, or divided by the amount of people in a group if not assigned to anyone).

Whiteboard (for further developing Planned Ideas)

Two different ideas for structuring these classes. Obviously not finalised yet, I am leaning toward "Try No. Two" because when tasks are assigned, they need to be assigned to a network and a person, but the tasks shouldn't know to whom they have been assigned (IMO). So the class which assigns the tasks needs to know that a network is different from a person. (See also the next point below.)

Network as a composite

Now I am having issues deciding how to structure the three classes above. My issue with the composite design is that since the Network class has to hold at least all the un-assigned/claimed tasks, the assigner needs to know which Doer is a network (or does it, if the assigner just assigned the task to 'home, paul, josh', that would work.), and something would need to know which Doer was the network to find out which tasks were unclaimed too. So I am pretty sure the Composite pattern is out for this case.

Network as a ???

Here the Network gets passed a task list and assignee list. It adds the task to it's list of tasks, and list of unclaimed tasks if the assignee list is empty (eerrghh). It also assigns the task to the relevant people which are also contained within the Network. This is the easiest implementation (right now) and so the one I will start with, it may ot be the best though.

Network as a Chain

This also suffers from hiding the interface of Network.

Issues with this implementation include: 1) The Doers have to pass themselves to the Request as parameters, again as I have designated that the network should contain at least the unclaimed tasks, then 2) if a GUI say were to display a list of unclaimed tasks It would have to go through the chain casting or calling lots of no-ops until it found all the Networks, 3) else it would have to do some kind of call back request, which would have to know about the implementation of both Network and the class it was to call back too.

Task

Okay, the syntax for my task scheduler is incomplete and unwieldy. I have been looking at work by Martin Fowler on patterns for dates and recurring events (Range (of time) arbitrary precision time points recurring events for calendars). These look interesting and like they could be used, albiet with a little work, especially his recurring event language. I also found an implementation of the ideas discussed in Fowler's 'Recurring Events for Calendars' PLoS submission. This doesn't extend the functionality discussed in the paper though, so still some work needed.

yyyyMMddTHH:mm +d(mon,tue,thur-sun) +w(2,5) +m +y -d(sun,sat) -m(jun-oct) -y(2020,2025)

Is probably the next option. the first field is the start dateTime, the +x expressions are when to repeat the event, the -x expressions are when not to. The expression in brackets express: mon,tue = repeat every mon and tuesday; (2,5) = repeat every second and every fifth d/w/m/y; and, jun-oct = june to october inclusive.

To be Cleaned Up

whoop, got the syntax for my task scheduler thingee downish. Put a little too much work into it implementing it the BAD way, but at least I have unit test for when I refactor.

Syntax for my scheduler. The string is stored in the task and a list of Dates at which the task occurs over some time period is requested. The Dates are then generated from the stored string and the resulting list is returned. – Yes it has to be in dd/mm format, and the + is a '+', and the n means "occurs every n timeframes

• Q)All tasks must be kept somewhere – even when they are not assigned to anyone – where? A) Maybe users should be part of a network, but a network should be more than a just an aggregate of people. This way if a user creates a task but doesn't assign it to anyone, it would still be a member of the network object and will be found when the group is queried for un-assigned tasks. A) Maybe a network should just be a type of doer, but when executing a task it just puts it into the unclaimed tasks list? But then how does the task get assigned to someone? Maybe the class which gives the task to the network searches through the user list looking for the user who the task was assigned to. But since the user list is stored in the network then the assigning class needs to know that there is a difference between a network and a person, and which doer is a network and not a person. So there is no point using composite at all because the points always need to go to an individual person.
• Q) More than one person can have a task, what does this mean for the Person.execute() method? – A) When the task is created (and/or later, maybe by a group op) it should be created as a x person task with y points per person (or as a task worth x payouts of y, this would be analogous to a multistage task, harking back to the %done field of traditional PIM apps ). Each person has to execute it or maybe it should be executed x times, no matter who by. The second option is probably more correct because a task shouldn't know who it has been assigned to.
• The task must have some way of recording who executed it.
• A reg-exp-y based scheduler e.g.

This event occurs at 10/03/2010 0700 hrs + i*7 days (so it repeats at the same time every week). Java's calender class should be able to handle months with weird numbers of days &c.

• Maybe a Task object could have a getSchedule method which returns a list of all the dates at which the task occurs over the specified amount of time, or a year by default.
• Also need a setWorth method set the number of points the task is worth.

• Tasks whose points increase or decrease over time e.g.

This task is worth 120 + 50*(%theDeadline%-(today + 1 day)) points. i.e. you get 170 points if you complete the task tomorrow, 120 if you complete it on the deadline, and the points rewarded decreases linearly with time, maybe you would even get less than 120 if you completed it after the deadline. Although when it got down into negative territory it would never get completed, so maybe there would have to be a automatically applied penalty to whomever the task was assigned to after the deadline has passed.

User Stories

Joe is a user of the Abstracted Motivation application. His kitchen is a mess. He needs to do the dishes, mop the floor, and empty the rubbish. After he has finished his chores he plans on having a beer (or several). He also enjoys listening to The Grateful Dead while doing his chores (much to the chagrin of his flatmates).

• User:Paul Clark/US-001-Add Task
• User:Paul Clark/US-002-Claim an Open Task
• User:Paul Clark/US-003-Execute Task

Paul Clark US-004-View Unassigned Tasks

Paul Clark US-005-Edit Task Schedule