Forem: CyberFriend

Project 3:Nintendo Division. Tetris Game

CyberFriend — Tue, 05 Nov 2024 20:38:04 +0000

Hi Everyone,

We’re getting closer and closer to the finish line of our course, and as usual, the cherry on top of our journey is the most challenging project yet—Project #3: Partitioning. At the start, our class was divided into two big teams: Atari and Nintendo. I'm part of the Nintendo division, and I’d love to share my experience with you.

The Project Phases:

1.Design and Partitioning Phase: For our project, we’re redesigning the classic Tetris game. We started with a base file filled with bugs and missing features, and our job is to bring it to perfection.

During this phase, we actively communicated with the entire division. We initially chose Microsoft Teams as our primary communication tool, but since some team members found Teams a bit heavy, we also set up a Discord server to keep things clear and organized. Before our first meeting, we had already selected a division team lead, along with local team leads for each subgroup. At our first meeting, Rachael, our division team lead, walked us through the agenda and introduced the project plan. Each team member semi-volunteered for responsibilities and contributed ideas.

I say "semi" because, as you’d expect, things didn’t always go as planned. During both phases, we all ended up working towards one main goal: completing the design project.

2.Implementation and Integration Phase: Once we had the design in place, the fun part began. Our team, Team TypeScript, was primarily responsible for coding, testing, and design (both visual and document design). Shout out to Myo, who did an amazing job with the coding! My role focused on testing and discovering bugs. However, the part I’m really proud of is designing the visuals for the game. Our division wanted to use an animated version of a professor’s face as the game background, and I got to bring that to life. After finishing my design, I merged my code into the main branch and completed a pull request.

Since this project involved so many people, each step required multiple reviews and approvals, which sometimes turned simple tasks into complex processes. To be honest, I prefer working with a smaller team, but I also recognize how essential it is to divide tasks when so many people are involved.

When designing the background, I thought it would be cool to take our game to the next level with laser eyes that glow every time the player clears a line. I shared my idea with the team, and together with Myo, we brought it to life in the game.

As more team members started contributing, we added even more features like game music, bug fixes, and a "how to play" guide. Overall, the experience I gained during this project was invaluable, as it gave us insight into what real workflow in a large corporate environment is like.

And just like that, this is my last blog post. What a ride! If I could go back to the beginning of the quarter, I’d tell myself that all the effort was worth it. It’s been an amazing experience filled with learning and growth.

Until next time,
Your CyberFriend

Design & Implementation: Project 2

CyberFriend — Tue, 22 Oct 2024 15:07:35 +0000

Hey everyone!

If you've been following my blog journey, you already know I write about my experiences in our Global Software Development class. For our next project, my team, TypeScript, was given a two-week task that was split into two parts.

Part A required us to write a design for a SearchList, which we would later pass on to another team for implementation. Just like everything else in this class, this was a pretty new experience, but after our first meeting, we laid out the cards on the table and quickly started working on a design that followed the specific rules provided by our professor.

Here’s the Project Description our team came up with:

The goal of the project was to design a highly efficient data structure called SearchList. SearchList is a structure that implements node addition, node removal, or node searching by either name or index. The goal was to support an ordered list with efficient insertions, removals, and searches. We aimed to keep the code simple without using complicated constructs like templates, containers, or other high-level libraries. Our design document provided a clear, easy-to-follow plan for the implementation team to work from.

In Part A, our objective was to provide as many details as possible, including skeleton code, a demo for insertion by name, UML diagrams, and design diagrams so the implementation team would have a clear vision of what we required.
Design Diagram:

UML:

Finally, we created implementation tasks and set some deadlines. Honestly, these deadlines were not met by the other team. They also didn’t reach out for clarification or ask any questions, which made us wonder if our design was just that good—or if the other team didn’t care! LOL

Part B switched things up. We were now responsible for implementing a design created by another team, and this is where the fun really began. We were given a design for a bucket-item data structure. The instructions stated: "The design should allow fast insertion, removal, and querying of both buckets and items."
Besides this, we were provided with a list of tasks and rules to follow.

We kicked off the implementation phase with a team meeting where we carefully reviewed the design requirements and reached out to the design team for clarification. Honestly, it seemed like the team that handed us the design had big ambitions but didn’t fully consider the short timeline. Also, their design included things like a proxy (supposedly for security) that felt overcomplicated for this project.

Despite these challenges, we began by implementing the skeleton code and pushing it to our GitHub so the entire team could track the progress. Afterward, we divided the methods among us and started coding. After several attempts and meetings, we were finally able to implement the design, meeting all the requirements. During our final team meeting, we tested the code via Zoom, did some final touches, and then pushed the project to our GitHub repository.

The last step was sending the project back to the design team. We shared a zip file along with the compiled files and instructions on how to run it. Overall, this was a great experience. It challenged us to collaborate, maintain strong communication, and deal with GitHub and coding challenges.

After merging the final version of the project, it looks like this on GitHub:

It doesn't include any .class files, so anyone who wants to test our project will need to compile the files using javac *.java and run the BucketControllerTest.
See below for the testing results:

See you next time,
Your CyberFriend!

The Second Week of Project 1: Unit Testing

CyberFriend — Tue, 08 Oct 2024 19:06:45 +0000

As the second week of Project 1 rolled in, our task to build the unit tests we had each chosen began. To recap, me and seven other classmates were grouped into a team to practice unit tests, with a focus on working via GitHub. This project was designed to throw us into the reality of software engineering. Working in teams isn’t always as smooth as it should be, and remote work especially demands flawless communication, which not everyone is used to.

For this project, I took on the role of team lead. Honestly, I did everything I could to ensure our final tests were 100% successful (and maybe even went beyond my assigned role to make that happen!).

Below, you can see the methods I selected for my testing:

In Part B of the project, I worked with IntelliJ using the Gradle tool. Our team agreed to maintain a consistent commenting style across all tests so our code would look cohesive as one unified project. For example, here’s part of my test for HSetTest:
`@DisplayName("Yurii - HSetTest")
class HSetTest {
HSet hSet;

@BeforeEach
@DisplayName("Setting up the test environment")
void setUp() { 
    hSet = new HSet<>(); 
}

@AfterEach
@DisplayName("Tearing down the test environment")
void tearDown() { 
    hSet.clear(); 
}

@Test
@DisplayName("HSet size should return 0 after creation")
void size() {
    assertEquals(0, hSet.size(), "The size of a newly created HSet should be 0");
}

}

Since I had never done Unit Testing before, this project was not exactly a walk in the park. However, with some effort, I managed to complete all my tests and even helped other team members who ran into issues. One of the key lessons from this project was learning to work with GitHub’s pull requests. The whole process of reviewing and merging files was new to me but quite interesting to navigate as part of a team.

I believe one of the most important aspects of this project was setting rules for the main branch. Since many of us were new to working with pull requests, some initial mistakes could have seriously harmed the entire project. Luckily, we reviewed each pull request carefully, which saved us from potential disaster.

After missing our internal deadline (we are still on the project time tho), we finally managed to run all the tests successfully and achieved a 100% pass rate.

Introducing Teamwork and Unit Testing Project#1

CyberFriend — Mon, 30 Sep 2024 14:37:13 +0000

Week 4 began with forming teams and kicking off our first team project. Our team, TypeScript, consists of 9 members; however, despite it being the 4th week of class, one person still hasn't responded to us. So, it looks like we'll end up with a Fantastic 8—which, honestly, might just be our new team name.

This first project is all about Unit Testing and breaking the ice in terms of teamwork. Our initial meeting was held over Zoom, where we discussed:

Team Roles and selecting a team lead for Project #1.
Choosing the methods that each of us would use for Unit Testing (still in progress).
Discussing the tools and communication platforms that will help us move forward (Microsoft Teams, Google Docs, Excel Sheets, OneNote Class Notebook).
Planning future work.

One of the challenges during our first meeting was defining and splitting roles between each member. Since the roles weren’t clearly defined, we tried a trick: we prompted the project requirements and the number of team members into an AI assistant, which helped us brainstorm some ideas. This helped a lot! Another thing is, as usual in team projects, people tend to stay away from extra responsibilities—so, naturally, nobody wanted to be the team lead. I decided to be proactive and took up the responsibility of team lead. This isn’t new to me; I manage my team at work daily, so I’m confident about keeping this project on the right track.

After the meeting, one of the team members created the repository, allowing each of us to clone it to our local machines. I then created a branch for each team member and set restrictions on pull requests. Setting up these restrictions involved creating a CODEOWNERS file at the root of our project, listing the people authorized to approve any pull requests to the main branch. This should help us avoid unnecessary problems down the line. Moreover, I also created a .gitignore file to ensure that unnecessary files and directories are excluded from our project.

This was the first part of Project #1. My main concern is working with people! Everyone has their own responsibilities, personal life, work/school obligations, and life outside of this project—which is completely normal. My part in all of this is to keep us together and stay on track towards our main goal.

I think I covered most of what happened during the first week of Project #1.

I'll keep you posted.

Your CyberFriend!

Diving into the GitHub World

CyberFriend — Mon, 23 Sep 2024 14:35:57 +0000

For the past two weeks, our focus shifted to Git and GitHub. Despite hearing about it through blogs and from software engineers who always preach its importance, I hadn’t really used it much. Most DePaul classes either didn't mention GitHub or barely touched on it. As a sophomore student, I feel like this is a huge gap between what school teaches us and what the real world actually demands. But finally, here we are—learning something that will genuinely be useful down the road.

I rolled up my sleeves and dived into the world of repositories. Not gonna lie, it looked complicated at first, but things are always hard before they get easier. After some research, I managed to set up my GitHub and figure out all the commands I needed for this project.

This week was all about getting a taste of how software engineers manage their day-to-day work: creating a repository, connecting it to my local machine, sending updates, and working with different branches like the main and doubleLink branches. I learned how to push updates and add meaningful comments for each step. Merging branches, though—that was the trickiest part. Specifically, understanding how to deal with merge conflicts. Seeing those weird markers like <<<<<<, ======, and >>>>>> threw me off at first. But after some back-and-forth comparing files and reading through the comments, I was able to resolve them, keeping the most important updates. Then came the usual ritual: compile, check, and "Add! Commit! Push."

And just like that, several hours later, I completed all 16 tasks. Honestly, even though it took a lot of time, I enjoyed learning about Git and GitHub. As long as there’s real value in it for my future, I don't mind putting in the effort to learn.

Catch you next time,
Your CyberFriend

The Beginning of CyberFriend

CyberFriend — Mon, 09 Sep 2024 13:52:34 +0000

Let's kick off with a little intro about myself. Like many of you reading this, I'm a sophomore CS student at DePaul University. In the middle of my software engineering journey, I discovered my love for data science, so I added it as a minor to my major. Now, why is my blog called CyberFriend? Well, on the picture, you can see my best friend—my pet, Tokyo. Most of the time, Tokyo sits right next to me while we're trying to solve yet another complex coding problem, or he just listens to me complain when I get fed up about it. LOL.

The first day of class was fun. Like most classes, it seemed easy at first. The lecture material was as simple as "1 + 1 = 2." But then, when it was time to do the homework, boom: "Write a Fibonacci program." At this point, I shouldn't be surprised, but somehow it always gets me. So, I opened my VS Code and started revising my knowledge of Fibonacci, along with JAVA.

While working on the problem, I remembered I had already solved a small Fibonacci problem in Python, which made my life much easier. Now, I just had to rewrite it in JAVA. What’s funny is that three other courses this semester have also reviewed Fibonacci. Isn't it amazing how these courses are designed to overlap and reinforce the material? I love it! Anyway, the program is done, and it successfully compiles.

While testing it, I noticed that it would be helpful to add some exceptions, like "Only numbers allowed, no letters or words." This would make the program more explicit about only accepting integers. I thought about adding an exception for non-negative integers, but since the program returns zero for negative inputs, it felt redundant. Keeping my code clean and straightforward is important to me.

So, the changes are complete, Tokyo and I are happy with the final product, and now it's time to tackle the next problem.

See you next time,
Your Cyber Friend