some people are not programmers
Jan. 6th, 2011 11:55 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
astroaztecand sometimes more English words are worse than fewer.
Starting with the next semester the telescope schedule makes a major shift toward the paradigm that large national and international observatories have been using for some years. Instead of awarding time by whole nights, many nights are split between several observers. In the few previous instances of this the director's assistant had simply typed a lot of extra words into the database entries with the expectation that humans would make sense of them.
For this semester several other changes came into effect. The director has a new assistant. All proposals are now fully electronic instead of on 8 separate paper copies received from USPS into a stack of paper 3 feet high. That last means that the published schedule deserves to be a web page with links to the details needed by various staff. Altogether this means that the existing database extraction code was useless for the new semester.
The existing database entry code for the schedule was a point/click/type/click/point/type interface with little error checking, no easy way to see the intermediate results, and a week or so worth of tedium. I created a new entry scheme based on iCalendar and the online proposal information. It cross-checks everything in the iCalendar file and points out what needs to be fixed before it takes any action.
Alas, for some non-programmers even an e-mail which states "no you don't have to do anything, I do" is too much if it has 4 paragraphs explaining what is and is not happening.
If you give an incredibly powerful button to someone who is not a programmer then, no matter what you say, they may just keep pressing that button over and over again. So for that button
Starting with the next semester the telescope schedule makes a major shift toward the paradigm that large national and international observatories have been using for some years. Instead of awarding time by whole nights, many nights are split between several observers. In the few previous instances of this the director's assistant had simply typed a lot of extra words into the database entries with the expectation that humans would make sense of them.
For this semester several other changes came into effect. The director has a new assistant. All proposals are now fully electronic instead of on 8 separate paper copies received from USPS into a stack of paper 3 feet high. That last means that the published schedule deserves to be a web page with links to the details needed by various staff. Altogether this means that the existing database extraction code was useless for the new semester.
The existing database entry code for the schedule was a point/click/type/click/point/type interface with little error checking, no easy way to see the intermediate results, and a week or so worth of tedium. I created a new entry scheme based on iCalendar and the online proposal information. It cross-checks everything in the iCalendar file and points out what needs to be fixed before it takes any action.
Alas, for some non-programmers even an e-mail which states "no you don't have to do anything, I do" is too much if it has 4 paragraphs explaining what is and is not happening.
If you give an incredibly powerful button to someone who is not a programmer then, no matter what you say, they may just keep pressing that button over and over again. So for that button
- make sure it checks everything it does before doing it, and doesn't do it if it was already done
- make sure it leaves a full log of what it did and did not do
