CST338: wk04 Peer Review

Reviewed: Ariya Briscoe & Tyler Kenney

Ariya Kenney

Encapsulation

·         Field members in both the Card and Deck class files privately set, effectively promoting encapsulation so no members cannot be directly accessed.

• Appears to have all appropriate setters and getters that look to be necessary for the program with no getters or setters not being used.

Constructors

• Constructor passes in Rank and Suit object variables into the constructor to set the field members with those associated values, however, there are no validation checks. If an invalid suit or value were to be passed in at the time the object was created, it would just create a card with that assigned suit and value.
• There is no default constructor in the Card class file, but there is one in the Deck class file, The Card class file should remain without a default constructor as each card is defined by their rank and suit and would otherwise be set to NULL as their default value. While this could later be handled with setters and getters, for this case, we don’t “assign” cards their suits and values in real life. They already have those applied to them, so it’s better to construct the card as it would appear in the real world.

Readability and Style

·         Can easily follow along the logic throughout the program.

• Code follows the Google Java Style Guide in terms of spacing, braces, and naming.
• Did not use the checkstyle

Suprises

Ariya had progressed much further into project than I had made it to and found surprises while working on method implementations with the use of the helper methods. I agreed with this up to the Card and Deck files and found this to be the case for myself as well. However, we did encounter some minor hiccups we most certainly would have, if not already have, changed. For Ariya, this occurred during the test cases for Tableau that hinted at a needed different approach for a condition that would call removeCardsFrom() method. For me, the drawCards() method’s complication level was minimal, but in my tendency to over expand on otherwise simple logic, I found myself using an unnecessary while-loop and a redundant check for count being larger than card size. The real edge case I was missing was the empty list check, and by applying that change later, I was able to get the tests to run as expected.

 

Tyler Kenney

Encapsulation  

·         Instance variables are private for both the Card and Deck class files. This is important for encapsulation, and so variables cannot be directly called by the dot-operator, preventing accidental changes to core field members.

·         Getters and setters are available for the field members in both class files that seem appropriate and necessary.

Constructors

·         The constructor does not validate input on its own without having checks to handle passed in values at the time of instantiation. If someone were to pass in an invalid suit or value, the constructor would still construct a card with that assigned suit and value.

·         There is a default constructor for the Deck class and none for the card class, which is ideal as cards, in the real world, are not assigned or altered. This allows for the appropriate creation of a single card with the appropriate suits and values, that could only further in precision, if a check within the constructor constrained the parameters to meet the requirements of simulating a real-world card.

Readability and Style

·         Code logic is clean and easy to follow without having to run the program

·         The spacing within the file does appear to follow the Java Style Guide in terms of naming conventions, use of braces, and spacing.

Surprises

 While the implementation of the files were fairly straightforward, I found myself adding over complexity to the drawCards() method, adding unnecessary if-checks and while loops. Upon removal of these statements, I was pleasantly surprised at the simplicity of the logic.

 

 

 

Reflection

Before beginning the project, I first looked over the doc files to familiarize myself with the methods, UML, and implementation. This provided stability in which files to begin with and how they interact with one another. Following this, I constructed the layout of each file, following the UML before applying any implementation. This reduced time working with setup, so that the focus could be entirely on the implementation of the test files. For statements or logic, I was unclear about, I set a placeholder in the form of a comment where I felt the logic should be applied until I could see it more clearly.

In reviewing my classmate’s approach and following a discussion, I feel my approach was best for me, in that it provides me the resources and confidence before diving straight into code, which could have the opposite effect on an otherwise more fluid outcome. The implementation of the methods was friendly enough, for part1, to prevent any substantial differences in the code, apart from maybe comment cleanup and I did find myself with some hanging comments that could improve the readability of my code. My goal is to always improve, and while I don’t typically get offensive feedback, I’m welcome to any input that would promote stronger code structure.

toString() a method that can be overridden to display desired content specific to the file being accessed as opposed to using a staple default string for every file. This was once lost to me, as I couldn’t grasp the way the toString() could operate together / be combined.

Enum vs. constants are still a little lost on me, and in jumping between C and Java, it makes it that much messier. I thought of enums as being numerically auto generated variables, that are like constants, but with a default value beginning at 0. This doesn’t seem to be the case for java and there’s a little more that separates it from being a constant, yet somehow, it seems similar.

I most definitely celebrated after getting this assignment. Taking two courses and keeping up with the workload, on top of the fluidity of my implementations throughout the assignment recently increased my source of confidence and abilities. I took myself out to a movie for the first time in years, had a glass of wine, and enjoyed some very soothing Nordic music to ease the built-up tension of the week. 

---

 

CST338: wk03_peer-review

 

Reviewed: Brianna Tomasek

Review:

Clear, easy to follow naming conventions for variables keep the file readable and easy to follow. The logic is efficient with reduced number of statements within each function with clear formatting, including appropriate indexing, use of comments, and some Javadoc comments are included above methods.

Unit tests:
       I encountered some compile errors when opening the project, which appear to be related to JUnit imports and  a test method placed within the Rectangle class rather than the test file. After isolating these, the unit tests were able to run. One function appears to be incomplete, so not all functionality could be verified. 

Trends:
     I find the test files can most certainly take as much time as creating the file itself and had to remind myself to structure the test file almost as if I were constructing the file itself by constructing test objects and test field members to compare with.

Feedback:

     My tests, for Triangle passed with Polygon test file unavailable for validation. The overall format and clarity of the logic and structure of my code was said to have provided good readability with no unused imports or warnings.

Improvements: 

    I would likely make a function that would calculate the angle to reduce the redundancy of having to implement the formula for each angle method

General and test related struggles: 

    The hardest to pass for me occurred when testing the angles as I kept dismissing the thought that I would have to carry over the formula to obtain an expected angle value to compare with.

    Missing the Polygon test which would have further strengthened validation of how polygons are represented.

CST338: Software Design - wk2

Git commands:

·         git pull origin main                       // pull changes from the remote into your local main

·         git checkout branchName             // switch to an existing branch

·         git checkout -b branchName        // create and switch to a new branch

·         git add .                                        // add changes made on the working branch

·         git commit -m “commit msg”     // commit changes with a meaningful comment

·         git push origin branchName       // push changes from working branch (PR)

Interfaces:

            For lab01 we created an interface class to represent a generic Shape that has public access modifiers and abstract methods that will serve as a method blueprint to be overridden within the files that implement the Shape class file.  

Format à public interface Shape {…}

Unit tests:

            Created unit tests for both lab00 and lab01 to test the setters and getters, ensuring the data is set and returned as expected, with the use of asserts and Junit testing. The asserts passes according to the condition’s return value. For instance, assertNotNull(variable) passes if the value within returns True, indicating that there is data stored within that variable, and it is not empty.

Challenges:

Cloning the repository into IntelliJ. IntelliJ and I have a history of conflicting with one another, though the experience I gained from using git commands allowed me to do a workaround by cloning the repository directly via the terminal with

git clone …

Additionally, adjusting to the unit test file was a touch of a learning curve, in that it was necessary to spend time with how the @BeforeAll and @AfterAll sandwich the individual tests. I can see the future benefits of these annotations for more complex testing that require a build and or tear down to prevent redundant code.

What went well:

Working with codingbat exercises. Code is always the most intimidating and being able to practice smaller challenges not only refreshes my syntax knowledge, but built much more confidence is working with strings, arrays, and logic.

Operating Systems - Wk1

Topics

• Docker
• Debug/GBD
• Math Addendum
• C-Language

Docker  - à Docker container connects to a temporary instance terminator that will show as EXITED containers if -–rm is not included in the docker run.
Debug/GDB - Isolating failed tests and debugging a little at a time. Working with debugging applications like GDB for larger debug handling, such as stack overflow (crashes)

Math - Converted binary to hex and hex to binary. Determine how big address spaces (areas we have for individual processes) are or f.or all of our memory to be used to how big they are. 

C-Programming - a low-level memory access language that does exactly as you tell it to, and no more.  

Challenges

Getting familiar with GBD and getting started with debugging.

Adjusting to c-programming syntax and operations

The most challenging for me was getting the workflow and conditions for when to debug versus using GBD, as well as readjusting to c-programming language, which is fairly new to me. The syntax and reintroduction to pointers had me reviewing the behavior before I could even process the rest of the code.

Most Comfortable

I really have a much better grasp of identifying overflow and the stack, which had been a little loss in details for me over the years. Same with strcpy vs strlcpy, which I do believe I can now comfortably wrap my head around enough to explain it at its base.

• How do programs go from code, to the operating system, to a point in memory that can be later accessed (create an app that saves onto your pc)?

• How do applications connect to other’s operating systems?

• How are some users able to gain access to other operating systems to “hand over control” as tech-support may do? What would the tech even see on their end?

• How does everything I’ve learned from this point connect as a whole – from hardware, to the memory within that hardware, to the many virtual memories per process, to the program itself, to the running application that can be accessed and shared to other users?

Make the connection

From my previous courses in the program, we worked with Java, DBMS, unit testing, IDE, and Docker. Working from unit tests and multiple files, including creating an Android application that introduced the concept of databases prepared me for DBMS and the consistent use of git commands prepared me for this course. DBMS introduced us to docker, also relevant to this course.

Wk07/08

Hangman Reflection

Now that I've continued through the course, I feel much more confident in my earlier reflection on how I would approach the HW01 - Hangman assignment. I would read the prompt at least twice - once for familiarity and once to take down any notes and starting points. This will likely become much more apparent when I open the test file, reviewing it at least twice - once for familiarity, once for comparison and note taking. Furthering this, I would continue to read through the unit tests, ensuring to consider what methods are being called in the test functions, as they likely reveal which methods should be solidified in order to make the test for that method run as intended. In addition, I would likely begin focus on methods that don't require a call to another method in order to be run (this helps with set up, as these methods are likely the ones to be called within other methods). Along with pseudo-coding out each method, drawing a visual that would help me make connections, and practicing Lists, I would develop more comfort in implementing and operating Generics. After each method, I would create my own tests to ensure each method is working as intended before moving on to the next. 

Victories

• I feel much more comfortable working with IDEs and, while there is still a learning curve, can see myself comfortably continuing to utilize them. 
• I understand how to read a UML pretty comfortably 
• I have a much better understanding of Activites in Android Studio in that they require an xml, a java class file as the remote, and that it needs to be added to the manifest in order to be viewed. 
• I have more familiarity with databases, specifically Room, enough to (roughly) develop my own in Android Studio
• I understand how to extend classes and when
• I'm more familiar with interfaces and abstracts

Wk05 - Markov Evaluation

Who did you work with? Emmanuel Garcia

What was your strategy for solving the Markov assignment? 

    When I began Markov, I started by reviewing the prompt and reading it fully through. From here, I followed the UML and began the initial setup as soon as possible. While reading the prompt, I noted most of the methods called upon other methods. This directed my attention to the methods that are called, but don't call one themselves such as endsWithPunctuation(). To prepare for the rest of the methods, I reviewed JUnit testing, reading test files, and reviewed certain concepts I was weaker on. Unfortunately, some prior system issues held me back from sitting with the lectures as long as I would have liked, though the little review I've done, as well as having worked on the LDPM and Midterm, supported my progression. I did write out the methods and drew out my if statements so I could get a stronger, visual representation of what the method was doing. 

My biggest struggle was working with the HashMap in conjunction with the array. Rather, I couldn't make a mental connection as to how we would fill the array and store it within the HashMap. My second biggest struggle was the toString() method as I didn't fully grasp when to use the StringBuilder until further example and explanation during the evaluation. 

 

What strategy did your classmates use?
    Emmanuel first began by reviewing the test file, reading all the way through so he could see what the tests were looking for within their associated method. Some of the other function calls within the test file gave him a better direction on which methods needed to be completed first, such as getWord() within the addFromFile test method. This suggested that the addFromFile() method needed to be functional in order for getWord() to run as expected. He drew out everything and had a better understanding on how to visually detail what the HashMap would be doing 

 
How would you change your strategy having worked on the assignment? 

    I plan on coding every day for an hour to keep myself exercised on syntax and to learn how to draw out more complicated concepts such as a HashMap. While I did begin it the day it was assigned, I didn't spend every day on it, which may just need to be a necessary thing for me to do. I'm a very visual learner, so watching videos or seeing how the code operates behind the text allows me to work out the issue without looking too long at code. I also intend to utilize Emmanuel's approach by not only reading the test file, but taking note of any method calls that may be required for the test to run. After reading the prompt, if there are topics I'm foggy on, before opening the program, I may write a few practice examples in my terminal for retention purposes, if other practice sources just aren't enough. Small unit testing and seeing immediate output validates my steps enough for me to continue, but admittedly, working with a test file has been an adjustment. Perhaps creating my own test file, one method at a time, might help be better understand test files created by others.  

According to your classmate(s): how well does your code follow the Google Java Style GuideLinks to an external site.?

    My code followed the study guide pretty well and was in alignment with their own understanding, however, my program was incomplete, passing 6/10 tests initially. 

Week 3

Whose code did you review? Cristian Perez

 Review

• Variable names, are they meaningful and clear? 
• Good variable naming conventions, pretty clear and generally easy to follow along. 'str' for String and 'dp' for 'defensePoints' are easy to follow, though I know it might be preferred to fully spell out the variable name for a cleaner read, the variables are pretty straight forward.
•  Logic that could be more efficient 
• Logic is pristine and follows the prompts well, showing a good understanding working with abstract classes! 
• Unused imports or warnings. 
• No unused imports, though in Electric Rat, there are some suggestions 
• Clear formatting o Very clean structure and formatting 
• Are there comments? 
• Not too many traditional // comments but there are javadoc comments above the methods and a few additional helpful comments within the methods 
• Which unit tests pass? 
• All 12 Unit tests pass!

 

Summary

    I didn't get to sit with the LDPM project nearly as long as I had hoped. I accepted, with great difficulty, that it would be an inevitable hard hit, as the past couple weeks were spent trouble shooting and fighting with gradle than I was able to sit with the lecture and material. This was a heavy blow and not one that deserved much celebrating, however, turing what I had, even minimally, was enough of an accomplishment for the time being. Small and miniscule as the win may be, it still states my current position and shows me where I can improve, revisions that need to be made, and highlighted some of my inherent understanding from previous courses. This didn't quite save me, but has allowed me to prevail and face the rest of the course with a much more stubborn approach. 

    Unforunately, the prompts were very challenging for me, as I had barely gotten to review, in full detail, how to work with abstracts and interfaces. I do believe, now that I'm working on Markov, that the assignments are getting easier to follow as I have much more time to sit with the lectures rather than fighting with the IDEs and this is promising for me. I'm not out yet.