Monday, July 7, 2014

Getting context variables to display in the template, or, How Programming is like Knitting

Despite some interruptions, I've made much progress rebuilding my database of songs not in 4/4 time.  In about 10 hours (dating back over a month), I've built the new data model, gotten all of the old data (almost 700 songs, submitted by almost 100 different people) extracted from the old aufrecht.org and loaded into the new one, and gotten a few pieces of the new interface working.  Since the new interface is barely more sophisticated than the tutorial, I kind of wished I were further, but part of mastering a new system is accepting the time-suck of the learning curve.  More on that in a minute; let's look at where I'm stuck now.

Here's the current screen to show a song, with a song displayed.  Sort of.

I know what data I want to display, and how I want to display it, and where the data is in the database.  And when I used Django's shortcut (Generic Class-Based Views) for displaying this, 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.
 

No comments :

Post a Comment