CST 338 Final Learning Journal

    It feels like this semester just started, yet looking back now, I can clearly see how far I’ve come since HW1. Revisiting my Hangman assignment, I notice that my approach would be much more confident and structured today. Back then, I was still getting used to Java syntax, object oriented design, and version control. Now, I feel equipped to tackle similar assignments with a clearer plan and a stronger understanding of best practices.

Victories:

1. One major victory was my ability to break down the Hangman game into multiple methods rather than writing a single monolithic method. I now truly appreciate how modular design makes code easier to read, test, and debug.

2. Another victory was passing all the unit tests while maintaining clean, readable code. At the start of the semester, I was often unsure if my code would even compile, let alone pass every test. This accomplishment feels like a significant milestone.

Skills I’ve Improved:

• I now have a solid understanding of access modifiers and when to use private, public, or final. This has helped me design classes that are more robust and maintainable.

• I am comfortable creating and extending classes, which gives me more flexibility when building larger projects.

• I also feel confident working with Java collections, like List<>, and applying their methods effectively in real projects.

Reflecting on this assignment makes me proud of how far I’ve progressed. Beyond the technical skills, I also recognize my growth in project planning and execution. I spearheaded my current project, creating Figma mockups that successfully guided the final product. That combination of coding and design thinking feels like a true culmination of what I’ve learned this semester.

Overall, looking back at HW1, I feel more confident, capable, and prepared for future challenges. It’s rewarding to see tangible proof of my growth and know that my hard work has paid off.

CST338 WK05

Week 05 Learning Journal – Markov Project

This week, I worked on the Markov assignment and collaborated with Jessica. We reviewed our solutions together and compared our approaches to the project.

Before writing any code, I spent time reading through the Project Details document, especially the UML diagrams. The diagrams helped me understand the overall structure of the system and how each class was supposed to interact. From there, I started by creating stubs for all the classes and setting up their relationships based on the diagrams. Once the structure felt clear, I implemented all the constructors.

My main goal early on was to get the test file to run. At first, it threw a lot of errors because none of the methods were fully implemented. To fix this, I created a skeleton for all the required methods so the tests could at least execute. Once the file finally ran, I studied each test carefully—looking at the setup, teardown, and what each test was supposed to validate. I like beginning with constructor tests since the constructors need to be correct before anything else will work. From there, I moved on to setter tests and then getter tests.

My overall workflow was very methodical: I would focus on one test at a time, implement just enough logic to make it pass, and then move to the next. I continued that pattern until all tests passed and the full logic of each method was complete.

I didn’t start coding right away; instead, I made sure to understand the project’s requirements before touching the keyboard. Jessica had a similar strategy, but she followed the order of the Project Details document more closely, whereas I jumped around a bit depending on what made sense to tackle next.

Reflecting on the assignment, I think next time I might try to follow the project document in order, the way Jessica did. It might help me stay more organized and prevent me from bouncing between sections.

According to my classmate, my code generally follows the Google Java Style Guide well. I learned that there are even tools that can automatically apply some of the style rules, something I’d like to explore for future projects.

CST 338 WK04

LDPM Project 1 Reflection

With whom did you work?

I worked with Cris.

What was your strategy for solving the assignments?
In terms of my strategy for working on LDMP, I first reviewed the Project Details document, focusing on the UML diagrams. The diagrams provide a high-level view of the system and what needs to be implemented. I began by creating stubs for all the classes and establishing their relationships according to the diagrams. Once the class structure was in place, I worked on implementing the constructors.

My next goal was to get the test file to run. The test file initially had many issues because the methods had not yet been implemented. I gradually created a "skeleton" for the methods across all classes until the test file could run without errors.

Once the test file was runnable, I carefully examined the tests to understand their setup, teardown, and what each test was validating. I prefer to start with constructor tests, since constructors need to be correctly implemented before other methods. I then focused on the setter tests, followed by the getters.

My approach was methodical: I took one test at a time, implemented the corresponding method to pass the test, and then moved on to the next. I continued this process until all tests were passing and the required logic was fully implemented.

How would you change your strategy having worked on the assignment?
I would pay closer attention to the Project Details document, as it contained key information on how to set up variables and methods (static, void, etc.). I also want to spend more time familiarizing myself with the color coding and symbols on the UML diagrams to make class relationships and dependencies clearer from the start.

According to your classmate(s): how well does your code follow the Google Java Style Guide?
Overall, my code follows the guide well. I did have some in-line annotations that I need to avoid; moving these comments above the relevant code would make it more consistent with the style guide.

Did you know you can automate applying some of the style guide rules?
I did not know that. It seems like a useful way to save time and maintain consistency, so I want to explore that in the future.

What was the most challenging part?
The most challenging part was setting up the class relationships correctly according to the UML diagrams. Ensuring that the interactions between classes were accurate required careful attention.

What was the most interesting part?
The most interesting part was seeing the tests run successfully once the skeleton methods were implemented. It was satisfying to see the structure I built come together and pass the tests one by one.

What are you the most proud of?
I’m most proud of my systematic approach to tackling the project by breaking it down into stubs, skeleton methods, and then full implementations. This allowed me to stay organized and eventually pass all the tests.

How did you celebrate completing the assignment? If you didn’t, how will you celebrate?
I celebrated by taking 2 days off from looking at assignments. This helped me feel more refreshed and ready to tackle the next set of assignements. 

CST 338 Week03

 

Jessica’s Code Review

Variable Naming

• The variable randIndex could be more clearly named randomIndex. Adding the extra letters improves readability without increasing complexity.
  
  

• Similarly, the Scanner variable scnr would be clearer as scanner. Using full, descriptive names helps make the code easier to follow.

Logic and Test Failures

• Two unit tests are failing. The getHint test fails because the loop does not break after decrementing numberOfHints. I recommend using the debugger or adding temporary print statements to trace the loop’s behavior—specifically, printing the value of i at each iteration and tracking how many times numberOfHints decreases.
  
  

• The second failing test is harder to diagnose. Since I’m less familiar with do-while loops and find them less intuitive, it might help to rewrite that logic using a standard for loop. Doing so could make the flow clearer and potentially resolve the issue.

Comments and Documentation

• The code contains a large number of comments—almost one on every line. While Javadoc above each method is helpful and appropriate, many inline comments explain logic that is already self-explanatory (e.g., if (numberOfHints <= 0)). Removing unnecessary comments will make the code cleaner and easier to read.

Cris’ Code Review

Tests and Functionality

• All tests pass, which is excellent.

Readability and Naming

• Variable names are clear and descriptive, making the code easy to understand.
  
  

Comments and Documentation

• The comments are generally helpful, but there are more than necessary in some places. For example, commenting on what break; does isn’t needed. Your code is already very readable and doesn’t require that level of explanation. Reducing unnecessary comments will make the file even cleaner.

Reviews I Received 

 My peers felt that my variable names were clear, meaningful, and made it easy to understand what each variable was used for. They didn’t find any logic that needed to be made more efficient; the code seemed concise, with no unnecessary branching or extra variables. There were no unused imports or errors, and the only minor warning came from IntelliJ making assumptions about my debug flag.

They said my formatting was clean and easy to read, with good spacing between code blocks. The only small note was that in my chooseWord() method, the lines weren’t separated the same way as in the rest of the file, but this was more of a nitpick than a real issue.

Regarding comments, they liked that all of my methods were well-documented. Their main suggestion was to include more inline comments within the methods themselves so it’s easier to understand each chunk of logic at a glance later on.

Answers to Questions 

What improvements would you make to your code / what was suggested?

After reviewing my Hangman implementation, there are a few improvements I would make.

• chooseWord():
  My method loops through every word and picks the first unguessed one. It should instead stop after choosing one word or use an actual random selection. Also, the for loop currently doesn’t break, so it unnecessarily continues scanning. I need to break the loop once a word is chosen or rewrite the logic using a proper random index.
  
  

• Upper/lowercase consistency in makeGuess():
  I converted letters to lowercase but my secret words are uppercase from the file. This works, but it’s inconsistent. I might standardize everything to one case.

Which unit tests were the hardest to pass?

The hardest tests to pass were:

• hintTest():
  This test came up with edge cases when hints should not trigger a win and whether the hint system respects the count exactly.
  
  

• testDisplayGameState():
  Comparing exact output formatting forced me to match every newline, spacing, and list formatting exactly.

How do the existing tests function, and could they be improved?

They build a temporary file, load words, and simulate real Hangman gameplay by guessing letters until win/lose conditions are met. The tests also verify individual helper methods (reading files, picking words, scoring, hints, tracking guesses).

How they could be improved:

• chooseWord(): Should test that the method only selects unguessed words and actually uses randomness. I did not use a Random object, but I still passed the tests.
  
  

• testDisplayGameState(): Testing the returned string only would be cleaner.
  
  

• checkPlay(): It could assert that the game eventually ends.

Do the existing unit tests cover the full range of the subclasses?

There aren’t any sub classes in my implementation.

How would you change the unit tests?

• Add assertions in checkPlay().
  
  

• Add a test for case-insensitive guessing (guessing lowercase words when the file includes uppercase words).

What did you struggle with?

I struggled with getting the hint system to behave exactly as the tests expected. Making sure guessedWord updated the correct characters without accidentally replacing others. Understanding how strict the comparison was for displayGameState.

What did one of your teammates struggle with?

One of the teammates struggled with getting getNumberOfHints tests to pass. I found a small bug in their code. They needed to break out of their loop after decrementing hints. 

Was any part of writing the code easy for YOU?

Implementing the simple getters was very straightforward. hasWon(), hasLost(), and getScore() were easy once the main logic worked. readFile() was also easy since this was done in labs before. 

What was your biggest HW1 victory?

My biggest victory was getting the entire suite of unit tests to pass without modifying the tests themselves. Some of the tests (especially hintTest and checkLose) revealed subtle bugs in my logic, and fixing those felt like a major win.

CST 338 Week02

 During Week 1, I worked on Lab 00 and Lab 01, which focused on getting familiar with IntelliJ, Git, GitHub, and writing basic Java code. I was already very comfortable with Git and GitHub, so that part of the assignment came easily to me. I understood how to clone the repository, make commits, and push changes without any issues. In fact, I was able to help some of my teammates debug their labs and fix problems with their repositories. It felt good to use what I already knew to help others and make sure everyone’s projects were running smoothly.

One thing I did learn more about was the build.gradle file. At first, mine wasn’t working correctly, so I had to troubleshoot and learn what parts of the file were responsible for managing dependencies and building the project. Fixing it helped me better understand how Gradle works behind the scenes with IntelliJ.

The labs also introduced unit tests, which were useful for checking if the code was working as expected. Writing and running the tests helped reinforce how important testing is for catching errors early. We also started looking at interfaces, which I understand act as a kind of contract that defines methods a class must implement. Even though we haven’t gone too deep into that topic yet, it seems like a really powerful concept for keeping code flexible and organized.

Overall, Week 1 went smoothly. I felt confident using the tools and was able to apply my knowledge to help others, while also learning something new about Gradle and testing. These experiences will definitely make future labs easier to manage and debug.

CST 338 Week01

 Learning Journal – Coding Bat Challenges

Working through the Coding Bat challenges was a smooth experience for me, largely because of my prior experience with JavaScript and LeetCode. Since JavaScript and Java share very similar syntax, the transition to Java was fairly intuitive. The main difference I noticed was the need to explicitly define types in Java, which was a small adjustment compared to my usual JavaScript coding habits.

When approaching the challenges, I generally took a structured approach rather than just throwing code at the problem. I read each prompt carefully, thought through the logic, and then translated it into Java. Because I’ve done many algorithmic problems on LeetCode, the style and patterns of the Coding Bat questions felt very familiar.

One thing I did have to look up was the specific Java syntax for accessing arrays, maps, and string methods, since they differ slightly from JavaScript. Once I reviewed those, it was straightforward to implement the solutions correctly. Most of my solutions worked on the first or second try, with the main issues being minor syntax adjustments or type declarations. Overall, I felt comfortable completing the homework, and it reinforced that problem-solving patterns learned in one language can translate well to another with only minor syntax differences.

Week 8

 Final Video Project Reviews

The topic is well covered and suitable for a general audience. The presentation is clear, concise, and to the point. The content provides just the right amount of information for viewers to understand the basics without feeling overwhelmed.

The video production quality is good, and I especially liked the clips that helped visualize what the narrator was describing. However, I found the AI-generated voiceover a bit distracting. I think a human narrator would have made the presentation feel more engaging and personal.

Since most people are already familiar with what drones are, I didn’t find the topic particularly interesting. The presentation could have been improved by including more unique or surprising facts about drones to better capture the audience’s attention.

It’s not entirely clear how the teamwork was divided in this project, though I assume multiple people contributed. Overall, the video is appropriate for a general audience but could benefit from a few more engaging or lesser-known details about drones.

The topic of drone delivery is well covered and provides a good overview for viewers. However, the presentation could have been more specific in its focus. For instance, a title such as “The History of Drone Delivery,” “Why Drones Are Becoming More Popular,” or “How Drones Work” would help narrow the scope and make the content more engaging.

The research appears thorough and includes many relevant facts that support the topic. The quality of the video production is good. The b-roll effectively illustrates and reinforces what the narrator is explaining.

To make the video more engaging, the team could consider using a more attention-grabbing or descriptive title, as “Drone Delivery” feels a bit too broad.

The teamwork is evident throughout the presentation, as all members are featured narrating. It also seems that each teammate contributed to writing the script and assembling the final video.

Overall, the presentation is appropriate for a technology professional audience and provides a solid understanding of the topic.

The topic of autonomous weapons is far too complex to cover effectively in a short two-minute video. Narrowing the focus would have made it more accessible for a general audience. For example, using the time to simply explain what an autonomous weapon is and provide a few examples would have been sufficient and more effective.

The presentation itself is not very clear. By the end, I was still unsure what an autonomous weapon actually is, who uses them, or when they have been used. The research appears somewhat surface-level and could benefit from more depth or specific examples to help the audience understand the topic.

Some of the video elements also felt mismatched. The background music did not fit the serious nature of the subject and distracted from the message. Overall, the video failed to fully engage me as a viewer and left me feeling a bit lost.

Teamwork does seem evident, though it’s unclear how many people contributed to the final product.

To improve, the video could focus on clearly explaining what an autonomous weapon is and why it matters, ensuring that the presentation aligns better with the tone and expectations of a general audience.

The topic is well covered and provides a solid overview of autonomous weapons. The presentation is clear and well organized, especially with the inclusion of a roadmap that outlines what the video will cover. It gives a clear definition and strong examples of what an autonomous weapon is—much clearer than the version intended for a general audience.

The research appears thorough and well-supported by relevant information. The video production quality is good and appropriate for the presentation. The visuals and pacing complement the content effectively.

The video is engaging and thought-provoking, particularly because it raises interesting ethical questions about autonomous weapons. Teamwork also seems evident, as it feels like multiple members contributed to both the narration and the creation of the project.

Overall, the video is appropriate for a technology professional audience and presents the topic with the right level of depth and clarity.

The video could have used a clearer and more specific title. It’s not entirely clear what aspect of digital detox the team is focusing on or what the overall purpose of the video is. However, I really liked the team’s use of a group discussion as a form of research. It felt personal, authentic, and engaging. The video editing flows smoothly, and the quality is good, which helps keep the viewer’s attention. Each team member is clearly visible and actively participating in the discussion, showing strong collaboration. Overall, the video is appropriate for a general audience, as the conversational format makes the topic approachable and easy to understand.

The title is engaging, specific, and feels relevant to a technology professional audience. The presentation is clear and effectively focuses on the topic of digital detox. The quality of the research is good, with supporting statistics that strengthen the team’s claims.

The animated illustrations are well done and help tell the story in a visually appealing way. They make the video engaging, though the topic itself could have been explored in a more interesting direction. For instance, since the team mentioned that Gen Z is “digital detoxing,” it would have been compelling to dive deeper into how the younger generation is approaching this trend.

Overall, the video shows evidence of strong teamwork, as it clearly feels like multiple people contributed to its creation.

Weekly Reflection 

For our video project, my team created a presentation titled “Can AI Replace Tutors and Teachers?” This project helped me gain a deeper understanding of how artificial intelligence is influencing education and the ways it might support, rather than replace, human teachers. I learned how to evaluate information from different sources and present it clearly for an audience that may not be familiar with the topic. Creating the video also helped me develop skills in organizing research, writing a script, and communicating ideas visually.

Our team communicated and collaborated mainly through online messages and shared documents. We divided the work evenly, allowing each member to contribute to the research, narration, and editing process. Everyone shared their perspectives and ideas, which made the final project stronger and more balanced.

To make our collaboration more effective next time, I think we could schedule more regular check-ins earlier in the project timeline. This would help us stay aligned on our progress, clarify expectations, and allow extra time for feedback and final revisions. Overall, I’m proud of how our team worked together and what we accomplished.