Focus on places
Jun 11, 2024 0:46:50 GMT -8
Post by Uncle Buddy on Jun 11, 2024 0:46:50 GMT -8
"I'm not doing this over, it was too hard the first time."
Wrong. Do it over till it's easy.
This is not work ethics or ideology. It's a practical matter. Code that's too hard to understand is code that can't be fixed or improved. The first time a feature is written, I barely know what a few main goals are. The first time I rewrite the feature, I have better goals, more good ones and less bad ones. The code rarely turns out better than the goals that guide its creation.
The third and fourth time a feature is rewritten, there's some chance that it might turn out pretty good. It can take that long to burn the wanna-be clever out of a smarty-pants wanna-be.
I'm starting the rewrite of the New and Duplicate Places Dialog as I'd planned to do a few months ago. It really does need fixing. Partly because it doesn't work anymore. Partly because it could do simply what it used to do in a complex way. It no longer does anything since I changed something and it broke. A sign of good code is that you can change it easily without breaking it, because it's easy to understand what it does and how it does it.
My number one working principle is that broken code makes a lousy foundation for new code. It's better to start over than to spend days or weeks patching up what should be discarded in favor of the fresh inspiration and better judgment that comes with more experience. You're smarter today than you were six months ago, whether your spouse realizes it or not.
The new and duplicate places dialog helps in the creation of nested places like Paris, Lamar County, Texas, USA. Treebard's complex places feature was inspired by a bad experience I had with some genieware I used to use. I had input lots of events to Paris, Texas. But Paris, France was pre-loaded into the app for some reason. Eventually I learned that most of my Paris, Texas events had gone to Paris, France without saying goodbye. This experience is one of the things that got me interested in writing my own genieware. Treebard will make it impossible to place the Eiffel Tower out by the WalMart, know what I mean?
In Treebard, every nest in the nested place has a single place ID and a separate place_name_id for each of its names. Complex place names are typed once and autofill from then on. Each of these complex autofill strings has an ID in a database row that contains a collection of its included single place IDs. One place_name_id is chosen as the display name for that place, for example you can enter USA and United States and United States of America and tell Treebard which one to use, but while the names all have different name IDs, they all have the same place ID.
Another goal with both Treebard and UNIGEDS has been to represent the real-world fact that a place has any number of enclosing places. A big city might spread through numerous counties. Even a small town can be split down the middle by a county line. Historically, county names and boundaries didn't change a little, they changed a lot. If you're looking at a document that says someone was from Richland County, Ohio, you have to find an old map and do some research to figure out what area that references on a modern map. These things don't matter till you hit a brick wall and can't find someone. The time invested in looking in the wrong place needs to be minimized by pinpointing on the world what an old place name actually meant at the time the document was created.
It took a long time to get the database schema right for all this. That hasn't changed much in a long time. The GUI for the new and duplicate places dialog is a different story. When a place name is used in a different nesting than what Treebard knows about, Treebard needs user input. The challenge is to hide the complexity behind a simple user interface. I've finally got this licked except for one thing. The previous version was opening a separate dialog for each nest in a nested place, when a dupes check had to be done. This happened by accident and I decided to keep it because it looks nice to not see a bunch of questions for a bunch of places, all at once. But the code for opening and closing a series of dialogs for a single topic gets too weird, it has proven to be hard to maintain and extend the code.
So I'm starting over again, and instead of the previous versions, a single nest will be shown at once, but the succession of nests will be handled on a single dialog. It will be easier to collect data in one dialog about a series of single places, than it was to collect data on a series of dialogs that no longer exist.
Enough procrastinating. Time to write some code.
Wrong. Do it over till it's easy.
This is not work ethics or ideology. It's a practical matter. Code that's too hard to understand is code that can't be fixed or improved. The first time a feature is written, I barely know what a few main goals are. The first time I rewrite the feature, I have better goals, more good ones and less bad ones. The code rarely turns out better than the goals that guide its creation.
The third and fourth time a feature is rewritten, there's some chance that it might turn out pretty good. It can take that long to burn the wanna-be clever out of a smarty-pants wanna-be.
I'm starting the rewrite of the New and Duplicate Places Dialog as I'd planned to do a few months ago. It really does need fixing. Partly because it doesn't work anymore. Partly because it could do simply what it used to do in a complex way. It no longer does anything since I changed something and it broke. A sign of good code is that you can change it easily without breaking it, because it's easy to understand what it does and how it does it.
My number one working principle is that broken code makes a lousy foundation for new code. It's better to start over than to spend days or weeks patching up what should be discarded in favor of the fresh inspiration and better judgment that comes with more experience. You're smarter today than you were six months ago, whether your spouse realizes it or not.
The new and duplicate places dialog helps in the creation of nested places like Paris, Lamar County, Texas, USA. Treebard's complex places feature was inspired by a bad experience I had with some genieware I used to use. I had input lots of events to Paris, Texas. But Paris, France was pre-loaded into the app for some reason. Eventually I learned that most of my Paris, Texas events had gone to Paris, France without saying goodbye. This experience is one of the things that got me interested in writing my own genieware. Treebard will make it impossible to place the Eiffel Tower out by the WalMart, know what I mean?
In Treebard, every nest in the nested place has a single place ID and a separate place_name_id for each of its names. Complex place names are typed once and autofill from then on. Each of these complex autofill strings has an ID in a database row that contains a collection of its included single place IDs. One place_name_id is chosen as the display name for that place, for example you can enter USA and United States and United States of America and tell Treebard which one to use, but while the names all have different name IDs, they all have the same place ID.
Another goal with both Treebard and UNIGEDS has been to represent the real-world fact that a place has any number of enclosing places. A big city might spread through numerous counties. Even a small town can be split down the middle by a county line. Historically, county names and boundaries didn't change a little, they changed a lot. If you're looking at a document that says someone was from Richland County, Ohio, you have to find an old map and do some research to figure out what area that references on a modern map. These things don't matter till you hit a brick wall and can't find someone. The time invested in looking in the wrong place needs to be minimized by pinpointing on the world what an old place name actually meant at the time the document was created.
It took a long time to get the database schema right for all this. That hasn't changed much in a long time. The GUI for the new and duplicate places dialog is a different story. When a place name is used in a different nesting than what Treebard knows about, Treebard needs user input. The challenge is to hide the complexity behind a simple user interface. I've finally got this licked except for one thing. The previous version was opening a separate dialog for each nest in a nested place, when a dupes check had to be done. This happened by accident and I decided to keep it because it looks nice to not see a bunch of questions for a bunch of places, all at once. But the code for opening and closing a series of dialogs for a single topic gets too weird, it has proven to be hard to maintain and extend the code.
So I'm starting over again, and instead of the previous versions, a single nest will be shown at once, but the succession of nests will be handled on a single dialog. It will be easier to collect data in one dialog about a series of single places, than it was to collect data on a series of dialogs that no longer exist.
Enough procrastinating. Time to write some code.