SE 371 – Project 3

Part 1: 
This project was pretty crazy in the sense that it involved 4 teams collectively working in one big division, ours was Division Atari, and we had around 32 students it it. I was selected as the Team Lead and I quickly organized the Division Discord, which we would use to communicate throughout the entire project. I organized roles, and channels, and helped schedule our first meetings as well.

This allowed the division to get into the swing of things relatively quickly.
The first part of Project 3 once again involved us creating a Design Doc, my team, team 3, was assigned to the Bricks package, and we quickly finished our section of the design document. Other than that there wasn’t much to do in the first part, so during team meetings, which I attended all of them as I was a primary part of the division as the server manager, and team 3 leader, we started planning for future work, and assigning repository managers.

After the last meeting for part 1, I created an event meeting for after part 2 began, and that was basically the jist of what happened for Project 3’s part 1

Part 2:

Part 2 is where coding actually began, and while I haven’t exactly stated it in Part 1, I can summarize what the code exactly consisted of here.
Project 3 involves our Division Atari receiving a buggy and unfinished Tetris game made in Java, and trying to identify the bugs and missing features and implementing them before the week is done. We did this through our use of GitHub issues, and the project board to track tasks and complete them.

At first Team 3 was assigned a few issues regarding the Bricks that fell in Tetris, that were quickly completed by other team members, but by the time Monday rolled around, we, as a division, realized that many vital issues with the code had not been resolved yet, so we decided to organize a ‘debugathon’ that would involve many authorities division members, sitting in #coding-lounge and working for several hours to iron out the many issues left with our code, with this I worked on a plethora of issues that are listed in our github project board.

Issue numbers:
#155 – Pressing any control causes blocks to fall down faster
this issue took the longest to fix, and involved the most classes and code spaghetti, very annoying

#158 – Bricks can repeat too often
Technically this could be considered a new feature, but what I essentially did was implement a 7-bag randomizer that is used by most modern forms of Tetris to help enhance the gameplay experience

#169 – Bricks rotation issues, Brick matrices are not 100% correct and don’t rotate correctly to the right
This one was funny, at some point someone added a fifth matrix to the L-Brick and that matrix turned it into a J-Brick if you rotated it enough, very bizarre, other than that this issue just required a lot of testing and retesting to try and get the rotations to feel good.

#153 – Ghost blocks
This one we never actually finished, although I got a really bugged version of it running on a separate branch, other than that this feature was a complete headache to even try and implement, and unfortunately it never made it in the end.

Other than that I worked on some miscellaneous OS and crash issues that I personally had here and there, and then we finished up the last pull request and completed the project.

SE 371 – Project 2

Part 1:
This project involved my team creating a design document with an implementation design and sending it to another team (Team 4) for them to use. Along with receiving a design document from Team 2. We had a meeting the Friday following the reveal of Project 2, where we thought we summarized the necessary elements for Project 3 relatively effectively. Unfortunately come class on Wednesday, we discover that there a lot of flaws within both our design document and wiki. The professor provided a plethora of critiques that we took to heart, and proceeded to immediately work on correcting after class, with a better understanding of the project dependencies we were able to organize things to a great extent after that first class.

Part 2:
Much of the focus during the team meetings in the first week were concerned with future proofing communications and organization for when we had to interact with the other teams. This focus on the communication with the other teams came in handy come the second week, where we had distinct roles assigned to all members of the team, so that people could focus on their assigned tasks without concerning themselves with miscellaneous elements. I was in charge of organizing our communication structure as well as roles, and managing the Team Discord server, which was extremely vital to the success of our team in Part 2. Furthermore, I was the primary communicator between Team 3 and Team 4, since we had the ability to dictate how Team 4 would communicate with us. This culminated in our successful project completion on Wednesday, where Team 4 (and Team 2) described communication with our team as ‘great’ which I can’t help but take some amount of credit for, as I was part of the primary planning process for our organization and scheduling. I was also able to answer questions, or at least acknowledge the questions from Team 4 within 5-10 minutes or even shorter. We had a little struggle in terms of certain people not successfully completing their task assignments at certain points, but we completed everything in the end, with time to spare to allow for any feedback for Team 4 to be given, though none was needed, since my answers allowed them to complete the design without much hassle.

SE 371 – Project 1 – Part 2

Part 2 of Project 1…
This is where we actually made the test cases for our chosen methods, I will say that as I was working I discovered a very poor choice of methods on my part. I had to test the main() method(s) of some of the classes, and this required me to figure out how to check and test System.out.println statements, which took me way longer than I’d like to admit. However, once those were done, everything else was generally pretty easy, and my groupmates came in clutch in terms of helping with some git stuff. Jacob and Jonathan especially were very helpful.

SE 371 – Project 1 – Part 1

Okay, so for this assignment or Project the first part involved me and the rest of my team organizing our git workspace and scheduling what exactly needed to be done and when. Every available group member chose five different methods to create JUnit tests for. This process wasn’t terribly difficult and with the work done by some other group members the rest of the GitHub repository was set up successfully.

SE 371 – Assignment 2 – Learning Git

Alright, for this assignment there is quite a lot of tasks to go through, so I’m going to go over the assignment task-by-task.

Task 1: Easy enough, no real coding to be done here, just initializing certain git elements. I have also found that my IDE, IntelliJ, has quite a bit of git functionality built in, which is very convenient. Of course, I’m also going to go through the manual git commands and such, to learn, but afterwards I’m going to see about learning how to use git with my IDE as a way to speed some things up.

Task 2: Task 2 simply involves creating another class, this one being a ‘Player’ class and giving it some data, and then testing that data in Main. This was also very simple and was quickly pushed onto git.

Task 3: Task 3 had us create a very simply linklist class, that allowed you to chain a bunch of nodes together to hold some kind of data. This was very simple to do, and I used a while loop and another method to test the linked list in main.

Task 4: This task literally just required me to copy and paste a big chunk of code from the assignment page into my own project, so it was very simple. The hardest part was trying to figure out what I’m supposed to use all the data in the PlayerData class for.

Task 5: Alright Task 5 asks me to delete Player.java, so I did.

Task 6: Well that was a huge pain, for some reason trying to revert completely borked my project, and I had to troubleshoot for like 10 minutes to get back on track, but I’ve done it, the Player.java file is back, and through a git revert nonetheless.

Task 7: Task 7 was easy enough, although I will say that I was kind of annoyed at the vagueness behind some of the tasks here. Like I wasn’t exactly sure what the point of the playerData was exactly, and I’m just kind of using it for what I think it is.

Task 8: This task had us add an ‘initializeList()’ method to Player.java, which was pretty simply, it just involved having a while loop and using the addPlayer() until it filled out the list.

Task 9: This task wanted us to create a ‘findMaxWeight()’ method, which required a runner to run through the linked list, in order to access all of the data.

Task 10: This is where we initialized a new branch in git, that being ‘doubleLink’ where we can push changes without affecting main

Task 11: This task wanted me to refactor SeLinkList in my branch to act as a doubly link-list, this was relatively simple, but I’m pretty sure I have a very janky indexing situation going on

Task 12: This asked me to add a removeNode method, to Player.java, this was probably the most complicated method so far in this assignment, but it still wasn’t too bad, I had to make a helper method to help with indexing.

Task 13: This made me go back to main, and add a findMinWeight method to Player.java, along with refactoring findMaxWeight a little bit, so that it does something slightly different.

Task 14: This task required me to create a findMinMaxWeight method, which used basically the same idea from the first two weight methods, but in this case you had to do both tasks in one walk of the list, which was easy enough

Task 15: Now we merge back onto main, I accidently merged main onto my branch first, so whoops, but either way it was fine, since resolving the conflicts and then merging my branch onto main worked fine.

Task 16: This just required me to Demo the final code, which required a little finagling since I forgot to initialize the list, honestly to make the code a bit better I’d make initializing the list as a part of the constructor, since in this case we’re not using any other data except the data we received as a part of the assignment.

DONE: With that, the assignment is complete, it was pretty interesting and learning git was very helpful, IntelliJ is also pretty good for simplifying some git procedures. Other than that I can’t really think of anything very impactful that I experienced during this assignment.

 

SE 371 – Assignment 1 – Fibonacci Program

This was a pretty doable assignment, the only difficulties was refamiliarizing myself with basic recursion and Java syntax again. Which after a few minutes was done.

This course seems to be slightly more indicative of the real world in terms of what work we’re going to be doing, which for people wanting to get a job seems exceptionally valuable to learn. Learning the Github stuff was cool, as well as figuring out how to use vim, but other than that it seemed pretty chill.