Treebard's Real Purpose
Feb 28, 2021 18:45:29 GMT -8
Post by Uncle Buddy on Feb 28, 2021 18:45:29 GMT -8
Treebard GPS is supposed to be the genealogy software made by and for genealogists. The main reason this project exists is to show genealogists that they can write their own application even if they are not programmers, which I am not. I like doing it and it takes a lot of time to do it well.
It's not my goal to write professional-level code and I don't know what that is. I've never seen any that I could understand. Python is popular with hobbyists like myself because there's a sort of "pythonic" ethic wherein the "pythonista" is supposed to write human-readable code that any other pythonista could work on. But there are skill-levels among pythonistas. Advanced pythonistas don't always write code that I could read or write. So my goal is to focus on the functionality of the GUI--where the user interfaces with the data--not to mimic a professional programmer's code.
I've been working on this version of my project for about three years and during those three years I've started over several times, rewriting large portions of the code as I learned more and more from my mistakes. For example, when I finally started using classes after hating them for quite some time as a religious writer of (bad) procedural code, I went whole hog on classes and rewrote almost everything as a class. This was an educational experience which I'm now undoing. I love classes but they should be used where they make the code easier to read, write, extend and maintain. Not compulsorily for everything.
I don't claim to write great code but I'm certain that the code I'm writing is better and better. A large part of this is that I don't mind starting over. One of my cardinal rules for myself is that starting over from scratch on something always gets better results, and faster, than trying to fix bad code. Bad code that I wrote a long time ago doesn't make a suitable foundation for good code. But my accumulating experience and improving intuition about structuring the app is a good foundation for starting over, so when I start over I do a lot of basic stuff without even looking at the old code. This keeps the bad parts from sneaking back in and re-establishing themselves. So when I do re-use portions of my own code, there's always some tweaking to do because it has to be made to work in an improved setting.
Recently I started over on the date validation procedure in dates.py. This code interfaces heavily with the events table on the person page so I ended up rewriting the events table code too because it was way easier than trying to figure out what that silly old code was doing and how it was doing it. Some old ideas have been thrown out which saved me a lot of work and chopped out large sections of spaghetti code without a second glance. The result is much shorter and simpler, and more sensible, than the bad code which I was so proud of a year or two ago. If I'm still doing this in two years, I'm sure today's code will want to be rewritten then. So it's a slow process. It reminds me of when I tried to write a screenplay. The first draft would have made a disjointed 6-hour-long movie about many unrelated things. Many re-writings later, the final result is a readable script for a 2-hour-long movie.
The code that's already posted here at this point is going to be replaced soon by much better organized, more straightforward, more intuitive code. When I rewrote the code for the events table and the dates validation I couldn't believe how many convoluted strategies didn't have to be repeated in the new version. Desperate measures I'd taken in the old version because I couldn't find any other solution at the time. Because when I start over, I start over. The new version will be posted within the next week or so, and some of the key portions will not resemble the versions that are online today.
I have a goal to reach before I try again to put the app on a Github page. The core of the GUI is the person page which is basically a framework for the current person's events table. There are nine columns on the table: event type, date, place, particulars, age, kin, roles, notes, and sources. When all nine of these things can be created and edited, and gotten in and out of the database, then I'll create a Github page for the whole app.
If I was younger I might wait even longer than that before posting it on Github, but I want the project to be available to others in case something suddenly goes wrong and I have to stop. Imagine the outlandishness of a 60-something amateur genealogist trying to single-handedly solve the problem that all existing genieware is unsuitable for use, most of it is unfinished, and most of it was made to sell, not to use. Not my problem, right?
Right. It's my hobby. I'm doing it, often over 100 hours a week, because it's my hobby. It's more fulfilling to me than doing genealogy, but like doing genealogy, once I start I can't stop.
It's not my goal to write professional-level code and I don't know what that is. I've never seen any that I could understand. Python is popular with hobbyists like myself because there's a sort of "pythonic" ethic wherein the "pythonista" is supposed to write human-readable code that any other pythonista could work on. But there are skill-levels among pythonistas. Advanced pythonistas don't always write code that I could read or write. So my goal is to focus on the functionality of the GUI--where the user interfaces with the data--not to mimic a professional programmer's code.
I've been working on this version of my project for about three years and during those three years I've started over several times, rewriting large portions of the code as I learned more and more from my mistakes. For example, when I finally started using classes after hating them for quite some time as a religious writer of (bad) procedural code, I went whole hog on classes and rewrote almost everything as a class. This was an educational experience which I'm now undoing. I love classes but they should be used where they make the code easier to read, write, extend and maintain. Not compulsorily for everything.
I don't claim to write great code but I'm certain that the code I'm writing is better and better. A large part of this is that I don't mind starting over. One of my cardinal rules for myself is that starting over from scratch on something always gets better results, and faster, than trying to fix bad code. Bad code that I wrote a long time ago doesn't make a suitable foundation for good code. But my accumulating experience and improving intuition about structuring the app is a good foundation for starting over, so when I start over I do a lot of basic stuff without even looking at the old code. This keeps the bad parts from sneaking back in and re-establishing themselves. So when I do re-use portions of my own code, there's always some tweaking to do because it has to be made to work in an improved setting.
Recently I started over on the date validation procedure in dates.py. This code interfaces heavily with the events table on the person page so I ended up rewriting the events table code too because it was way easier than trying to figure out what that silly old code was doing and how it was doing it. Some old ideas have been thrown out which saved me a lot of work and chopped out large sections of spaghetti code without a second glance. The result is much shorter and simpler, and more sensible, than the bad code which I was so proud of a year or two ago. If I'm still doing this in two years, I'm sure today's code will want to be rewritten then. So it's a slow process. It reminds me of when I tried to write a screenplay. The first draft would have made a disjointed 6-hour-long movie about many unrelated things. Many re-writings later, the final result is a readable script for a 2-hour-long movie.
The code that's already posted here at this point is going to be replaced soon by much better organized, more straightforward, more intuitive code. When I rewrote the code for the events table and the dates validation I couldn't believe how many convoluted strategies didn't have to be repeated in the new version. Desperate measures I'd taken in the old version because I couldn't find any other solution at the time. Because when I start over, I start over. The new version will be posted within the next week or so, and some of the key portions will not resemble the versions that are online today.
I have a goal to reach before I try again to put the app on a Github page. The core of the GUI is the person page which is basically a framework for the current person's events table. There are nine columns on the table: event type, date, place, particulars, age, kin, roles, notes, and sources. When all nine of these things can be created and edited, and gotten in and out of the database, then I'll create a Github page for the whole app.
If I was younger I might wait even longer than that before posting it on Github, but I want the project to be available to others in case something suddenly goes wrong and I have to stop. Imagine the outlandishness of a 60-something amateur genealogist trying to single-handedly solve the problem that all existing genieware is unsuitable for use, most of it is unfinished, and most of it was made to sell, not to use. Not my problem, right?
Right. It's my hobby. I'm doing it, often over 100 hours a week, because it's my hobby. It's more fulfilling to me than doing genealogy, but like doing genealogy, once I start I can't stop.