The first thing I did was sit down and spend about 5-10 minutes on brain storming, here’s what I came up with on Monday:
terry@dixie$ cat ~/Dropbox/todo-structure.outline
todo's contain
task short name
task notes (raw data)
location
assoicated url's
due date
time estimate
associated contacts?
reminder preferences
list
project (tag)
priority
Shebang! YAML would work WELL
terry@dixie$
I like to dive in when designing a program, try and get a good big picture understanding of it, and try to identify the lower level issues that might chop up. The latter gets easier with experience, particularly with your tools rather than the art/science. After writing that file, I took a few more minutes to focus on the implications of its contents.
The purpose of a task management program, is obviously to manage tasks. It is fairly obvious that it is a fairly data centric program; so it’s a good place to start by thinking about what is the data. In this case, I took a couple minutes to think about what represents a task: what data it reflects. The short name being provided, as a convenience for listing tasks.
We can’t know for sure what sort of tasks will have to be managed, so what data will need to be attached should be kept abstract: it could be anything from a simple cat > notefile like stream of text, or an uploaded doc or photo. The important thing, is not shooting off a foot by making it restrictive. Since *I* am the principal user, I know the content will be quite variable. Excessively so, the more I utilise it.
Tagging a task with data like a location, associated URLs and contact info would likely be a good thing. You can easily imagine that going somewhere, talking to someone, or referencing a file off the web are all things that might go hand in hand with reviewing and completing a task.
Another frequent issue is keeping track of when xyz needs to get done, how often it needs to be done, how long its expected to take, and being able to do per-task preferences about the “Nag me about it” problem. Come to think of it, a way to note the tasks progress is a good idea too. Changes like these, are one of the main reasons I want something custom, rather than continuing with my beloved RTM – more control over the tasking details.
Keeping a flexible outline of the project, helps you identify spots to grow and or change it ‘in flight’, just like that realisation about progress tacking. Of course that assumes you will have time to think about the project, not just write its code like a drone.
Next up to plate, is the issue of organising tasks. I’ve got so much shit piled into RTM, that I have to periodically triage my task lists, almost like sorting them into a Trove. Notions of lists, priorities, and “Projects” are useful: in order to more easily create ad-hoc hierarchial lists based on such criteria. This is somewhat analogous to what’s possible using the SQL SELECT and JOIN statements. Database normalisation can actually be a good thing to learn aboutlink.
SQL is not a general purpose programming language, rather it targets the narrower domain of querying and manipulating rows and tables in a database. Although less needed around non web applications, knowing about SQL it is worth it, much like the concept of relational algebra in general. Why I have mentioned Structured Query Language here, is because it’s a useful train of thought to explore. Take some time and ponder about the possible formats, and what the code to manipulate it might.
A serious portion of programming is about solving problems, that’s what we use our languages for. If changing the rules makes solving the problem easier, that’s what we do. Knowing about various tidbits like declarative languages are valuable tools, if you remember to program more like Captain Kirk instead of a dry text book. Don’t bend yourself to the language…. bend the language to your problem, or find a tool or architecture that can help fill the gap.
Data storage formats are potentiality a lengthy issue, so I’ll go into that later.