CST 338

  For your learning journal for Week 05 I would like the following: Markov Work with your fellow classmates and go through your solutions to the Markov assignment. Who did you work with? I collaborated with Chanroop. What was your strategy for solving the Markov assignment? I started coding the Markov assignment   right away   due to poor time management. I wrote out the details on a whiteboard first. But I think I couldve paid more attention to the details. What was THEIR strategy for solving the Markov assignment Chanroop employed a methodical approach, planning extensively on paper first. She focused on breaking down the problem, designing efficient data structures (like  HashMap  for word relationships), and outlining the algorithm step-by-step before writing code. How would you change your strategy, having worked on the assignment? Moving forward, I will prioritize detailed planning over immediate coding. I'll dedicate time to outlining logic...

Work with some of your fellow classmates and go through your solution to project 1: LDPM You can work with up to three people (you MUST work with at least one other person) With whom did you work? I worked with Serena Ngo and Chanroop Randhawa. What was your strategy for solving the assignments? Did you start writing code right away? Did you plan it out on paper? I started as soon as I could. I always write code out on paper to visualize it. What was THEIR strategy for solving the assignments Chanroop -  Her project strategy involved thoroughly reviewing documents and then working file by file, finishing with Monster.java . She planned her code using rough UML diagrams on paper.  Serena - Her approach involved first outlining variables, methods, and classes from the document, then adding JavaDoc comments as guidance. She then went method by method, writing pseudocode and comments, followed by a rough code draft.  How would you change your strategy having worked on the ass...

Member 1: Erin Hurley Overall Impression: Erin's code demonstrates good practices, especially in the use of Javadoc and clear test setup/teardown in her test files. Key Strengths: When evaluating Erin's code, I noticed: Strong Javadoc Usage: Erin consistently applied Javadoc comments to classes, fields, and most public methods, which is a significant positive trend. This makes the code's purpose and functionality very clear. Clear Test Setup/Teardown: The use of @BeforeAll , @AfterAll , @BeforeEach , and @AfterEach in GameLoaderTest-2.java demonstrates a strong understanding of JUnit's lifecycle, which is a good practice for ensuring tests are isolated and reproducible. Self-Correction/Improvement Notes: Erin included comments like "Hangman Should NOT be a String. Make it an enum." in GameLoader-2.java . This indicates an awareness of potential future impr...

This week, I focused on core software development concepts from Lab 00 and Lab 01: unit tests , Git commands , and interfaces . Lab 00 introduced me to writing focused unit tests to verify code components, a practice I see as vital for reliable software. I also began learning essential Git commands like add , commit , and push , understanding their role in version control and collaboration. In Lab 01, I got an early look at interfaces . I learned they define a contract, outlining methods a class must implement. This concept, though new, already suggests how interfaces promote code abstraction, flexibility, and modularity. The biggest challenge was grasping the Git workflow , especially minor merge conflicts. However, the immediate positive feedback from passing unit tests was a great motivator. Moving forward, a strong understanding of Git is clearly crucial, and the initial exposure to interfaces has already begun shaping my approach to designing reusable and extensible code.

Tackling Coding Bat challenges has been a real journey for me, and I've definitely refined my approach along the way. My first step is always to really understand the problem. I don't just skim; I read the description several times and then spend a good chunk of time analyzing the examples. Walking through them manually helps me solidify exactly what's expected. Once I feel like I grasp the core idea, I move on to planning.  When it comes to  implementing the code , I take an incremental approach. I'll get the basic logic working first, then gradually layer in the solutions for those trickier edge cases. I also make a conscious effort to use clear, descriptive variable names. For testing and debugging, I rely heavily on print statements. If my code fails a test, I'll flood it with print statements to see the values of variables at different points and trace the execution. This, combined with carefully reading Coding Bat's error messages, usually points me right ...