Also, I had new evidence that the system was in fact designed by a nimwit -- I got to see the underlying data structure and, friends, it is scary. (details in lj-cut below)
So, until moments ago, I was thinking that this year marked a net victory in the battle of me against insanity.
But then, just a moment ago, the filemaker-program-from-hell decided to segfault on me, which led to me discovering a new WTF: this fine little application, which uses a file-based DB, apparently only commits changes to the database (i.e. to the file) when you quit. Meaning that all the work I'd done today was erased when the application segfaulted (well -- that was my experience; it would be more accurate to say none of the work I had done today was ever saved -- nor could I have saved it, as there is no "save" button since I'm supposed to be imagining I'm interacting with a database rather than writing-to-a-file anyway).
Of course, you can't blame them, can you? I mean, every programmer knows that if you write your program well enough, it can't possibly segfault (bugs? what's a bug? power failures? we can't be blamed for power failures...), so it's perfectly safe to count on saving all your data when the user quits at the end of a session.
So I'll be typing the rest of my comments into another program and then copying them into filemaker, now that I've learned my lesson.
1. Here's an example of the ingenius data-base design:
We have slots to write in four different assessments in Spanish -- for each slot we can record the assessment title, skills addressed, and how the student did on the assessment.
Now, I understand from the user interface that the typically "sane" way to design this is out of the question. In a sane system, there would be an assessments-description table in which I could create as many assessments as I wanted, and then a separate assessments table in which I store an assessment-ID, a student-ID and an assessment. Of course, this adds complexity to the programming and the interface, so I understand we won't do that -- we have one very large flat database table and we had to predetermine the number of assessments that could possibly show up on a single progress report (in this case, 4).
So I'd assume from the UI that there would be, you know, 12 columns in the table to deal with this particular chunk of info (3 fields per assessment * 4 assessments), with names like assessment-description-1, assessment-description-2, and so on.
But no -- this is precious -- there is instead one column for each chunk of text (description, skills, assessment). But, you ask, how could their be a mere one column if there are 4 different assessments? Why, that's easy: we use newlines to store the different fields. Yes, friends, newlines.
So, the database actually looks like this:
|Assessment Name||Skills Addressed||Assessment|
|Listening to a Dialog^KReading a newspaper^KSpeaking with the Teacher||Listening^KReading^KSpeaking||A/M^KM^KA|
Now that's beauty.