Here's the current screen to show a song, with a song displayed. Sort of.
I got results pretty quickly. But then I put the song and the opinion about what signature the song is into two different tables, so that people who disagree about a song's time signature can each make their case, and when I try to extend the page to include not just the song but the opinions, I get stuck. After much googling and Stack Overflow, I'm pretty sure that the data I need has been passed along from the database to snake through a series of Django convolutions not entirely unlike the workings of a digestive system, but now my data is stuck in the rectum of the page rendering system. I can see it up near the top of the Template context:
But. I don't understand Python or Django well enough to know how to flush that data out the last little bite. I had a bit of the same experience with OpenACS and TCL, where data structures like
set x [list a [list b] c]
seem to make sense but when you try to use them, you end up making the same mistakes over and over until you really grok them. Here's a glimpse at the steepness of the learning curve to my Python data enema:
So it's like knitting. There's a point in the process of learning a new pattern where nothing makes sense and you feel stupid. In knitting, the path forward seems to be to find some kind of mechanical instruction on how to proceed and to do so automatically, without understanding, and then after you've done it, right or wrong, you have a skeleton of facts to go back and hang the flesh of your mental model on. I think that approach doesn't quite work with programming, but the meta-pattern of getting stuck, feeling stupid, finding a way—any way—to proceed, and then rebuilding your mental model one bit closer to reality, still holds. At some point the following sentence will not only make perfect sense, but will be confirms your hard-won knowledge.
Because Django’s URL resolver expects to send the request and associated arguments to a callable function, not a class, class-based views have an as_view() class method which serves as the callable entry point to your class.But that point won't be day one.
Anyway. Going back to task breakdown. Here's what I have broken out for this mini-project:
Here's where this work breakdown fails:
First, I have to manually transcribe hours from Toggl to Redmine, I only do it when I finish a task, so Redmine doesn't know that I've put 9+ hours into Task 55, and therefore 10+ hours into the overall task, not 1.17.
Second, I probably should have broken up task 55, since I tend to work on this project 1-2 hours at a time, and a 9-hour task that's less than half done is too big to helpfully project or plan around. Here's the task detail I wrote up for it:
Model: DONE Song: DONE - Song DONE - artist DONE - Album DONE - uniqueness? DONE song_opinion DONE - PK to song DONE - PK to user DONE - origin DONE - time signature DONE - link to song DONE - notes DONE Testing - Model testing ? - View testing DONE - interface testing ? - fix object name for admin Interface: - LCRUD for Song and Song_Opinion - LIST - basic list DONE - Song, Artist, signature - pagination DONE - filter - sort by column head - CREATE - basic DONE - add Song_Opinion - READ - basic DONE - add Song_Opinion - UPDATE - basic - add Song_Opinion - DELETE - basic - cascade to Opinion - delete Song_Opinion only - Navigation - breadcrumb - Bring tests current again
Third, when I came up for air from task 55, I realized I had already done Task #92 and part of task #93. So should I bother to move a few hours back from 55 to those tasks? Or just close them out as done with 0 hours each, which would mess up a hypothetical report on average time per task? More things to ponder for the ultimate task management system.