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.