First Evaluations Period and Start of Second Part
For the first evaluation, I was supposed to finish writing, testing and debugging my Environment class, which is responsible for producing data related to the fish tank environment and its inhabitants. I spent the majority of the week before evaluations testing and debugging that part of my simulation. I ended up moving everything related to changing Oxygen and CO2 levels into an inner class/thread of its own called Gases. I think that makes my code look more organized and readable.
One important change that I am proud of was having all threads (except main and clock) wait for the lock on the monitor object to be passed on, and having the Clock thread use notifyAll() to pass the lock to all the waiting threads. This made it so that all data is updated “hourly” (an “hour” has its own definition in every simulation). This change ensured that my simulation data is updated in an orderly fashion, which is how it is supposed to be.
The evaluations period itself was stressful. Students in the WhatsApp group that I am part of freaked out and worried about not passing their mentor’s evaluation and being kicked out of the program. I started worrying soon after the evaluation period started. Unfortunately, I spent more time worrying about the evaluation and preparing for the chat with my mentor than I did coding during that week. Thankfully, I did pass the evaluation, but with the condition that I will put more effort and time into my project.
I did write one important part of my simulation during the evaluations week. That was the integration of threads representing devices into the environment class. Unfortunately, I made a silly mistake with synchronization while doing this and did not run my tests before I committed and pushed the changed to my GitHub repository. The mistake made the Environment test stop too early. I found out about this mistake when I was calling my mentor and he told me that the simulation did not look right... That was awkward. My mentor drew the conclusion that this mistake meant that my Environment simulation was not working properly. I did fix the mistake within an hour of our call, though, and hoped that my mentor would look at it and see that the Environment did, in fact, work fine and that I met my goal for the first part of the project.
On to the topic of the current week. Recently, I asked my mentor how I should get initial inputs from the user. The answer was, a good ol’ configuration file. So, that is what I am working on this week. I already made the configuration file with default inputs in JSON format (also suggested by my mentor). Being a lazy programmer, I decided to use an Environment object and write its values to file using Gson instead of writing the file manually. This took some time because I got a StackOverflowError, and that was the first time I ever got that error! Thankfully, I managed to fix it. Thus, the original configuration file was successfully written to file. Now, I need to implement reading the file as a way of getting initial inputs for the Environment class. Then, I will work on the main class as much as I can so far.