@pawaitemadisoncollege
Takeaway: I got so frustrated with trying to find the DAO bugs that I started over with CRUD methods in The Fortress, and got it working in three days. Then I simply compared what wasn't working in the Indie with what was working in The Fortress and solved the bugs! Strange workaround, but the first word there is WORK.
Challenge: Trying to find a fast and consistent way to solve bugs. What I just mentioned worked this time - and I'm only a week behind now - but I don't think I could solve a bug that way twice.
Problems: maybe it's panic when I can't make progress right away. It's not being lazy or not wanting to commit time to a problem, although it may look that way. It's security thinking, where the difference between success and outright catastrophe can be measured in billionths of a second. The human brain doesn't function that fast, but a computer processor does. (Trivia - just to get an idea how fast computers are, light can reach the moon from Earth in about 2 seconds, but in the duration of a single processor cycle, light doesn't even go from the monitor to your eye.) Malware functions at the speed of the processor, so defensive software has to react insanely fast. Getting off topic, I know, I'm here to learn Java, and Java is slow because the JVM uses up clock cycles, so I can't really write the kind of defensive software I know is possible until I'm advanced enough to write in Assembler, which isn't even covered at MATC. Let's get back to Java.
Larger Issue: Learning to code one step at a time. Focusing on goals that are several years away is not productive at this time!
[x] As you address the open issues on your repository, please check off the individual items and close the issue when all items are addressed. There are still some things open from earlier this semester.
[x] Project plan and time log appear out of date - no changes in the last 20 days?!
[x] Missing screenshots showing all unit tests passing.
[x] Missing ERD showing the database has been created and the relationships.
[x] I do not see an ERD (Entity Relationship Diagram) here at all for the database. It should show all tables, columns and the relationships between them. Can you point me to it?
In terms of best placement, I think the Documents directory or a Design Documents directory.
[ ] Can you also point me to when the user sign up and log in functionality will be added (I didn't see this in the project plan).
@pawaitemadisoncollege Takeaway: I got so frustrated with trying to find the DAO bugs that I started over with CRUD methods in The Fortress, and got it working in three days. Then I simply compared what wasn't working in the Indie with what was working in The Fortress and solved the bugs! Strange workaround, but the first word there is WORK. Challenge: Trying to find a fast and consistent way to solve bugs. What I just mentioned worked this time - and I'm only a week behind now - but I don't think I could solve a bug that way twice. Problems: maybe it's panic when I can't make progress right away. It's not being lazy or not wanting to commit time to a problem, although it may look that way. It's security thinking, where the difference between success and outright catastrophe can be measured in billionths of a second. The human brain doesn't function that fast, but a computer processor does. (Trivia - just to get an idea how fast computers are, light can reach the moon from Earth in about 2 seconds, but in the duration of a single processor cycle, light doesn't even go from the monitor to your eye.) Malware functions at the speed of the processor, so defensive software has to react insanely fast. Getting off topic, I know, I'm here to learn Java, and Java is slow because the JVM uses up clock cycles, so I can't really write the kind of defensive software I know is possible until I'm advanced enough to write in Assembler, which isn't even covered at MATC. Let's get back to Java. Larger Issue: Learning to code one step at a time. Focusing on goals that are several years away is not productive at this time!